00:02 Введение
01:43 Механизация
07:34 За пределами парадокса
12:14 История до сих пор
14:32 Сегодняшние субмодули
16:24 Требования (основной поток 1/5)
20:12 Проектирование (основной поток 2/5)
25:37 Конструкция (основной поток 3/5)
30:29 Тестирование (основной поток 4/5)
34:09 Обслуживание (основной поток 5/5)
41:12 Идентичность (траншеи 1/8)
46:35 Резюме (траншеи 2/8)
51:43 Практики (траншеи 3/8)
56:47 Бастионы (траншеи 4/8)
01:02:00 Писатели кода (траншеи 5/8)
01:06:23 Порог боли (траншеи 6/8)
01:14:55 Производительность (траншеи 7/8)
01:21:37 Неизвестное (траншеи 8/8)
01:27:00 Заключение
01:29:55 4.6 Инженерия программного обеспечения для цепей поставок - Вопросы?
Описание
Приручение сложности и хаоса является основой инженерии программного обеспечения. Учитывая, что цепи поставок являются сложными и хаотичными, неудивительно, что большинство проблем предприятий, связанных с программным обеспечением, сводятся к плохой инженерии программного обеспечения. Численные методы, используемые для оптимизации цепей поставок, являются программными и, следовательно, подвержены той же проблеме. Эти проблемы возрастают вместе с уровнем сложности численных методов. Правильная инженерия программного обеспечения для цепей поставок подобна асептике в больницах: сама по себе она ничего не делает, подобно лечению пациентов, но без нее все разваливается.
Полный текст
Добро пожаловать на эту серию лекций о цепях поставок. Я - Жоанн Верморель, и сегодня я буду рассказывать о “Инженерии программного обеспечения для цепей поставок”. Программное обеспечение является основой современной практики управления цепями поставок, однако большинство учебников по управлению цепями поставок сильно недооценивают роль программного обеспечения в цепи поставок. Программное обеспечение для цепей поставок - это не просто требование, подобно доступу к средствам транспорта; это гораздо больше. С точки зрения практиков в области цепей поставок, большая часть работы определяется программным обеспечением, вызвана ошибками программного обеспечения или ограничениями программного обеспечения и связана с проблемами, связанными с программным обеспечением.
Инженерия программного обеспечения - это дисциплина, которая призвана помочь людям создавать лучшее программное обеспечение, получать больше от программного обеспечения, создавать это программное обеспечение быстрее и тратить меньше для достижения большего. Цель этой лекции - понять, в чем суть инженерии программного обеспечения и понять ее основное значение для цепочки поставок. Цель этой лекции также состоит в том, чтобы понять, что вы, как практикующий в области цепочки поставок, можете сделать, чтобы избежать парализации вашей цепочки поставок, будь то действия или бездействие, которые, к сожалению, привели к враждебности в отношении ваших программных предприятий.
XX век стал веком механизации рабочей силы. Большие компании и большие цепочки поставок, как мы их знаем, возникли в XX веке, и прогресс, достигнутый благодаря механизации рабочей силы, был невероятным. За последний век производительность почти каждой трудоемкой задачи, которая имеет отношение к цепочке поставок, такой как производство или распределение, увеличилась в сто раз.
Напротив, я считаю, что XXI век является и будет веком механизации интеллектуального труда, и этот переход очень сложно понять. То, что мы понимаем, когда мы переходим от механизации физической рабочей силы, совсем не применимо к механизации интеллектуального труда. Я не говорю, что переход менее драматичен, но реальность заключается в том, что на данный момент переход к устранению рабочей силы, занимающейся очень трудоемкими задачами, уже позади нас.
Во Франции в 2020 году было 27 миллионов людей с офисными работами, в то время как осталось менее миллиона людей, работающих на фабриках. Соотношение составляет 27 к 1. Когда мы начинаем рассматривать, что включает в себя механизация интеллектуальной работы, это очень удивительно и также связано с парадоксом Моравека.
Ханс Моравек, компьютерный ученый, заметил в 1980 году, что в отношении вычислений задачи, которые кажутся самыми сложными для человеческого разума, например, стать шахматным гроссмейстером, на самом деле являются типами задач, которые легче всего решить с помощью компьютеров. Напротив, если мы рассмотрим задачи, которые кажутся чрезвычайно простыми для людей, например, стоять на двух ногах, эти задачи оказываются невероятно сложными для компьютеров. Вот суть парадокса Моравека: наша интуиция о том, что сложно достичь в терминах интеллектуальных задач с помощью компьютеров, очень обманчива.
Одно из того, что усложняет проблему дальше, заключается в том, что внезапно, когда речь идет об автоматизации офисных работников, это делается самими офисными работниками. Это не было так в случае рабочих на фабриках; они не были теми, кто решал, что фабрику следует дальше механизировать и что их рабочие места будут устранены. Однако это происходит с офисными работами. Таким образом, у нас есть проблема, когда процесс механизации не только глубоко контринтуитивен из-за парадокса Моравека, но и управление людьми, ответственными за внедрение этой механизации, а именно инженерами программного обеспечения, само по себе является очень контринтуитивным. Это, вероятно, одна из самых больших проблем для цепочки поставок: управление людьми, которые будут отвечать, одним или другим образом, за работу с этой механизацией.
Здесь я не могу не заметить, что многие цепочки поставок и связанные с ними компании все еще твердо укоренены в мышлении XX века, где вы подходите к корпоративному миру, как будто у вас есть офисные работники, занимающиеся интеллектуальной работой, и затем они приходят с решением или планом, который передается рабочим на фабрике для выполнения. Однако с соотношением 27 человек к одному, когда речь идет о офисных работах по сравнению с фабричными работами во Франции, и, вероятно, схожими статистиками в большинстве развитых стран, это уже не так происходит. Это буквально о том, чтобы автоматизировать свою собственную работу, и это означает, что в этом мире XXI века самые лучшие офисные работники - это те, которые постоянно умудряются автоматизировать себя, сделать себя устаревшими, а затем перейти к чему-то другому. Это очень сложно для многих компаний, которые все еще очень сильно укоренены в мышлении XX века.
Мнения о самой идее инженерии программного обеспечения сильно расходятся. Одно из самых сильных критических замечаний поступило от Эдсгера Дейкстры, одного из основателей компьютерных наук. По его мнению, инженерия программного обеспечения даже невозможна как дисциплина или область исследований, и он сказал, что это сводится к “как программировать, если вы не можете”, своего рода рецепту. Критика Дейкстры, которая очень интересна, заключается в том, что инженерия программного обеспечения превращается в своего рода самопомощь, которая не может привести к успеху. Действительно, если мы предположим, что целью инженерии программного обеспечения является обеспечение успеха создания полезного, превосходного программного обеспечения, то инженерия программного обеспечения в основном обречена на провал. Успех в программном обеспечении чрезвычайно сложен; это так же сложно, как успех в науке. Для этого требуется искра гениальности, немало удачи, и здесь нет рецепта. Более того, каждый отдельный успех обычно поглощает саму возможность, которая потребовалась для достижения этого успеха, и таким образом все это становится нерепродуцируемым.
Однако я не согласен с видением, что инженерия программного обеспечения обречена на провал. Я считаю, что основная проблема заключается в определении амбиций инженерии программного обеспечения. Если мы решим, что амбициями инженерии программного обеспечения является успех в создании программного обеспечения, то, действительно, она обречена на провал. Однако, если мы решим подойти к инженерии программного обеспечения как к узкой подотрасли экспериментальной психологии, я считаю, что мы можем собрать, через этот угол зрения, очень ценные и действенные идеи, и это то, что я буду использовать сегодня в этой лекции. Таким образом, инженерия программного обеспечения связана с самими программистами и их взаимодействием. Фокус на программистах - это хорошая отправная точка, потому что человеческая природа стабильна со временем, в отличие от технологии программного обеспечения, которая постоянно меняется. Природа людей, которые борются с этой технологией, нет; человеческая природа остается очень стабильной на протяжении очень долгого времени.
Если мы посмотрим на другие области, такие как наука, мы увидим, что подход к области через призму изучения того, что делают ее практики, может быть очень плодотворным. Например, в науке теперь широко установлено, что конфликт интересов приводит к плохой науке и коррупции знаний. Этот вопрос ранее рассматривался в лекции под названием “Адверсарная маркетинговая исследования для корпоративного программного обеспечения”. С этой точки зрения мы видим, что возможно собрать идеи широкой применимости и актуальности, если мы сосредоточимся на самих практиках. Таким образом, инженерия программного обеспечения связана с людьми, которые имеют дело с программной технологией, их проблемами и процессами, а не так сильно с самой технологией.
Сегодняшняя лекция является шестой лекцией из четырех глав. Эта глава посвящена вспомогательным наукам цепочки поставок. Эти вспомогательные науки представляют собой элементы, которые, по моему мнению, имеют фундаментальное значение для современной практики цепочки поставок, но они не являются строго говоря элементами цепочки поставок. Они больше похожи на поддерживающие элементы для вашей практики цепочки поставок.
До сих пор, в этой четвертой главе, мы начали с физики вычислений, занимаясь современными компьютерами, а затем двигались вверх по лестнице абстракций. Мы перешли от компьютеров к алгоритмам, которые представляют собой самые маленькие, наиболее интересные части программного обеспечения. Затем мы перешли к математической оптимизации, которая интересна для цепочки поставок, но также для множества других соответствующих программных проектов, таких как машинное обучение. Мы видели, что математическая оптимизация непосредственно интересна для цепочки поставок, но она также непосредственно интересна для машинного обучения, которое, в свою очередь, также интересно для цепочки поставок.
Что касается математической оптимизации и машинного обучения, большинство интересных концепций и парадигм в настоящее время имеют программный характер. Это не просто простые алгоритмы; это что-то невероятно выразительное и требует рассмотрения через призму языков программирования. Поэтому последняя лекция была о языках и компиляторах.
Сегодня мы все еще движемся вверх по этой лестнице абстракций и фокусируемся на людях, а не на том, что они делают. Мы собираемся сосредоточиться на самих программистах, и в этом заключается вся суть анализа инженерии программного обеспечения.
Сегодня я буду представлять два набора взглядов на программную инженерию. Сначала я представлю основное мнение, которое, по моему мнению, доминирует в этой области. К сожалению, это основное мнение вызывает критику, как уже упоминалось ранее, с тем, что люди предлагают подходы самопомощи, которые некоторые, включая меня самого, имеют причины отвергать, потому что они не представляют реалистичных амбиций для дисциплины программной инженерии. Тем не менее, я рассмотрю это основное мнение, хотя бы потому, что некоторые ошибочные представления все еще пользуются невероятной популярностью. Знакомство с этими ошибочными концепциями крайне важно, хотя бы для выявления некомпетентных людей, которые могут подвергнуть опасности вашу поставочную цепочку своей некомпетентностью.
Затем я перейду к взгляду из траншей, который представляет собой совокупность элементов, основанных на моем личном опыте в качестве генерального директора компании по разработке программного обеспечения, которая занимается именно разработкой программного обеспечения для предприятий в сфере поставочной цепи. Как мы увидим, эти идеи очень сильно связаны с людьми, а не с технологией самой по себе.
Основное мнение о программной инженерии утверждает, что программная инициатива начинается с сбора требований к интересующему нас программному обеспечению. Большинство программных инициатив в крупных компаниях принимают эту точку зрения через процесс, который обычно начинается с запроса на предложение (RFP), запроса на котировку (RFQ) или запроса на информацию (RFI). Этот подход унаследован от практик 20-го века, которые были очень успешны в механической инженерии и строительных работах. Однако я считаю, что в отношении программного обеспечения эти подходы к сбору требований являются глубоко ошибочными.
В программном обеспечении вы не знаете, чего хотите; вы просто не знаете. Знание того, чего вы хотите, всегда является самой сложной частью программного обеспечения. Например, если мы рассмотрим простую проблему, такую как учет запасов, формулировка проблемы крайне проста: в любой момент времени я хочу знать количество, которое я должен пополнять или заказывать для каждого отдельного SKU. Сама проблема проста, но определение того, что является хорошим количеством, становится чертовски сложным и трудным. Как правило, уточнение требований гораздо сложнее, чем написание самого программного обеспечения.
Только столкнувшись с вашей интуицией и обратной связью, полученной от реального мира, вы можете постепенно выявить требования. Требования не падают с неба; их можно получить только через достаточно экспериментальный процесс, и вам нужно иметь это взаимодействие с реальным миром. Однако единственный способ иметь это взаимодействие - иметь программный продукт, так как сбор требований в основном является очень эмпирическим и развивающимся процессом. Проблема в том, что к моменту, когда вы закончите с требованиями, иметь требования становится бессмысленным, потому что, если у вас есть требования, это означает, что у вас уже есть соответствующий продукт, реализующий эти требования. Так что, к моменту, когда у вас есть доступ к правильным требованиям, у вас уже есть продукт в производстве, работающий, и то, что у вас есть эти требования, не имеет особого значения.
Таким образом, суть в том, что начинать процесс через призму требований, по моему мнению, является безумием. Требования, вероятно, должны быть последними в качестве документации на поздних стадиях, где вы документируете все основные причины, которые привели вас к реализации продукта таким образом, а не наоборот.
После того, как требования определены, классический подход предполагает переход к фазе проектирования. Я согласен с тем, что в какой-то момент может произойти проектирование. Однако, подобное мышление, которое происходит на этой фазе проектирования, часто является ошибочным. Проблема заключается в том, чтобы контролировать стоимость изменений. Классическое представление о стоимости изменений вне программной сферы заключается в том, что стоимость увеличивается экспоненциально со временем. Например, если вы измените дизайн автомобиля на очень ранней стадии, когда у вас есть только чертеж, стоимость изменений будет минимальной. В отличие от этого, если вы подождете, пока миллионы этих автомобилей окажутся на дорогах, стоимость изменений будет невероятно высокой, потому что это подразумевает отзыв, что может быть невероятно дорогостоящим.
Однако, в отличие от физического мира, в программной сфере стоимость изменений не увеличивается естественным образом экспоненциально. Увеличение стоимости не может быть полностью устранено; однако, в значительной степени увеличение стоимости может быть управляемым. Действительно, стоимость изменений увеличивается со временем, в основном потому, что кодовые базы обычно растут со временем. Я никогда не видел, чтобы кодовая база предприятий значительно уменьшалась с одного года на другой; они обычно продолжают расти. Тем не менее, стоимость изменений можно управлять в определенной степени.
В настоящее время этот аспект становится все более широко признанным, даже в программных кругах. Кстати, это суть гибкой методологии. Вы, возможно, видели эти термины, когда люди говорят: “О, у нас есть эта гибкая методология разработки программного обеспечения”. Одна из основных целей гибкой методологии - установить контроль над стоимостью изменений. Сегодня я не буду вдаваться в детали гибкой методологии, но, можно сказать, что я считаю этот подход немного ошибочным, когда речь идет о том, как именно контролировать стоимость изменений.
Я заметил, что стоимость изменений в основном происходит из принимаемых решений о программном обеспечении и, более конкретно, из того факта, что очень сложно устоять перед желанием принимать решения. Представьте, что вы смотрите на потенциальный будущий программный продукт, и перед вами стоит множество решений. Первоначальная попытка состоит в том, чтобы принять эти решения, чтобы прояснить, что у вас перед глазами. Напротив, очень хорошая фаза проектирования, а не хороший дизайн, заключается в возможности отложить все решения, которые не являются абсолютно необходимыми, когда продукту не требуются эти решения прямо сейчас. Действительно, если вы не принимаете решение, пока решение не принято, и вы не установили, что вам нужно выбрать этот конкретный подход к дизайну или технологии, оно все еще витает в воздухе, готовое быть измененным, потому что ничего еще не решено.
Один из аспектов, чтобы контролировать стоимость изменений, - научиться откладывать все решения настолько, насколько это практически возможно. С точки зрения цепочки поставок это выглядит очень странно, потому что это означает, что для всех людей в программной команде и всех людей, наблюдающих за продуктом и программной командой, кажется, что они находятся в темноте. Это даже хуже, потому что они находятся в темноте намеренно, что очень сбивает с толку. Однако именно это должно произойти, и это должно быть сделано намеренно. Поэтому это, мягко говоря, сбивает с толку.
Теперь, если преждевременные проектные решения обусловлены иногда ошибочной потребностью в контроле, проблемы, связанные с этой потребностью в контроле, не ограничиваются только этим. После завершения фазы проектирования основное представление о программной инженерии гласит, что мы должны продолжить с созданием программного обеспечения, также часто называемым фазой реализации. Обычно это делается путем представления некоторого вида водопадной проекции, также называемой диаграммами Ганта. Это то, что вы видите на экране. Я считаю, что этот подход, диаграммы Ганта и водопады, является чрезвычайно токсичным, и токсичность этого подхода не должна быть недооценена в отношении программного обеспечения. Подходить к проблеме таким образом - значит буквально предрекать неудачу вашей цепочке поставок, по крайней мере, что касается программных инициатив.
Гораздо лучше понять проблему и подход к созданию программного обеспечения - это рассматривать его как процесс обучения. Создание программного обеспечения - это обучение всему, что необходимо для создания хорошего продукта. Это процесс обучения, и все эти изученные части являются побочным продуктом взаимодействия мира с программным обеспечением, которое возникает в процессе создания. Основная проблема с прогнозированием по методу “водопад” заключается в том, что вы прогнозируете то, что собираетесь открыть. Это просто невозможно по определению. То, что вы собираетесь открыть, было неизвестно до тех пор, пока вы не откроете эти элементы. Вы не можете прогнозировать свои открытия. Вы можете ожидать их, но вы не можете спланировать детали того, что вы собираетесь открыть. У вас могут быть предчувствия, но это лучшее, что вы можете получить. Идея, что вы можете превратить эти неопределенные интуиции в точный прогноз по методу “водопад”, снова является полной безумицей.
Кстати, этот небольшой видимый парадокс о создании программного обеспечения как процессе обучения также объясняет, почему иногда репликация программного продукта может быть либо невероятно простой, либо невероятно сложной. Если команда пытается воспроизвести программный продукт, который уже есть на рынке, и у этой команды есть доступ к пониманию или урокам, которые привели к созданию программного обеспечения, которое они пытаются скопировать, то, как правило, воспроизведение программного продукта - его повторная реализация или перекодирование - может быть выполнено с помощью лишь небольшой части времени и бюджета, которые были необходимы для создания программного обеспечения в первую очередь. Напротив, если у команды нет доступа к этим высокоуровневым идеям, и, например, единственное, к чему они имеют доступ, - это исходный код, команда очень часто получает продукт очень низкого качества, потому что, по сути, все обучающие части или знания были потеряны. Вы просто скопировали внешний вид продукта.
С точки зрения цепочки поставок, самая большая проблема здесь - это сознательно отказаться и укротить свою потребность в контроле. Процесс “водопада” - это выражение компании, которая хочет контролировать процесс. Например, если я говорю: “давайте взять этот проект под контроль”, это будет воспринято как что-то очень разумное. Почему бы не сделать наоборот? Почему бы, например, не заявить: “давайте полностью потеряем контроль над этим проектом?” Но реальность заключается в том, что этот уровень контроля - это полная иллюзия, что касается программного обеспечения, и это полностью вредит вашей способности предоставить продукт высокого качества в конечном итоге. Укррощение вашего желания контролировать - это, с точки зрения цепочки поставок, вероятно, самая большая проблема, когда дело доходит до создания программного обеспечения.
С момента появления компьютерных программ они были заполнены ошибками и дефектами. Чтобы решить эти очевидные проблемы, основное мнение состоит в том, что необходимо проводить тестирование. Тестирование принимает множество форм. Что касается необходимости тестирования, я согласен, хотя это пока очень неопределенно. Некоторые инструменты подчеркивают, что тестирование должно проводиться после создания, некоторые подчеркивают, что тестирование должно проводиться во время создания, а другие указывают, что тестирование должно проводиться до создания. Некоторые подходы утверждают, что тестирование должно проводиться до, во время и после создания программного обеспечения.
Мое общее мнение по этой проблеме заключается в том, что вы должны делать все возможное, чтобы сократить обратную связь до минимума. Мы обсудили этот момент в предыдущей лекции: сокращение обратной связи до минимума имеет решающее значение для того, чтобы действительно получить то, что работает в реальном мире. Таким образом, я обычно рекомендую обращать внимание на то, сокращает ли то, что вы делаете в терминах тестирования, эту обратную связь или нет. Например, для большинства ситуаций я не рекомендовал бы естественно использовать разработку через тестирование (методология, которая говорит, что тестирование идет первым), просто потому, что для большинства ситуаций тестирование первым просто задерживает время получения обратной связи о вашем программном продукте от всего мира.
Однако моя самая большая озабоченность в отношении тестирования - это неизвестное ограничение, что-то, что, кажется, обычно игнорируется. Тестирование в конечном итоге может оценивать только соответствие тем самым правилам, которые вы установили сами. Проблема в том, что в программном обеспечении нет жестких ограничений. Нет химического способа подхода к адекватности вашего продукта с учетом проблемы, которую вы пытаетесь решить. Это совсем не похоже на физическую сферу. Например, в механической инженерии есть канонический критерий: размерный допуск детали. Что бы вы ни проектировали в терминах механической инженерии, размерный допуск будет иметь первостепенное значение. Это очевидный и естественный кандидат. Однако в программном обеспечении нет такого естественного и очевидного кандидата.
Проблема здесь заключается в адекватности. Если мы хотим привести пример цепочки поставок, такой как резервные запасы, то совершенно очевидно разработать автоматизированный набор тестов для проверки расчетов резервных запасов. Очень просто реализовать такую логику тестирования. Однако это не скажет вам, что резервные запасы - это плохая идея в первую очередь. Вы тестируете только то, что знаете.
Когда мы имеем дело с физической машиной, мы ожидаем износа и, следовательно, ожидаем какого-то вида обслуживания для поддержания работы машины. Однако почему программному обеспечению нужно какое-либо обслуживание для продолжения работы? Конечно, нам иногда приходится заменять компьютеры, так как они со временем выходят из строя. Однако этот аспект является очень незначительным, и в корпоративном программном обеспечении физические поломки машин даже не составляют 10% от фактических затрат на обслуживание. Это существует, но влияние такого рода обслуживания крайне незначительно.
Однако обслуживание в корпоративном программном обеспечении является первостепенной важностью. Затраты на обслуживание огромны. Для многих поставщиков корпоративного программного обеспечения обслуживание составляет буквально 80% или более от затрат на разработку. Оказывается, факторы, порождающие необходимость в обслуживании, имеют очень мало общего с физикой. Первый фактор - это готовность платить самих клиентов. Если поставщик может получить ежегодную плату за обслуживание в размере 20% от того, что было заплачено за настройку программного обеспечения в первый год, то поставщик программного обеспечения будет брать эту плату. По сути, с точки зрения затрат, стоимость обслуживания определяется готовностью клиентов-предприятий платить.
Второй фактор - это вид обслуживания, который необходимо выполнять, чтобы поддерживать работу программного обеспечения. Действительно, с каждым прошедшим днем окружающая среда, окружающая интересующий нас продукт, отклоняется от продукта. Операционная система продолжает развиваться, система баз данных продолжает развиваться, и то же самое можно сказать о всех сторонних библиотеках, используемых программным обеспечением. Ни один программный продукт не является изолированным. Каждый программный продукт зависит от множества других программных продуктов, и эти другие продукты развиваются самостоятельно. Люди, разрабатывающие эти программные продукты, продолжают работать над ними, и по мере работы над этими продуктами они продолжают их изменять. Таким образом, наступает момент, когда ваш продукт просто перестает работать из-за несовместимости. Вы ничего не делали, кроме как не следили за остальным рынком. Второй фактор - это все обслуживание, которое необходимо проводить, чтобы поддерживать работу программного обеспечения и сделать его совместимым с остальным рынком.
Третий фактор - это количество работы, необходимое для поддержания полезности продукта. Действительно, программное обеспечение было разработано и создано в определенный момент времени, и с каждым прошедшим днем мир отклоняется от того, что было видно во время создания продукта. Таким образом, даже если ничего не ломается в терминах совместимости с оборудованием, оказывается, что по мере изменения мира полезность продукта уменьшается, потому что мир просто отклоняется от ожиданий, заложенных в продукт. Если вы хотите, чтобы программное обеспечение оставалось полезным, вам необходимо постоянно поддерживать его.
С точки зрения цепочки поставок обслуживание является большой проблемой, и мы коснулись этого аспекта в предыдущей лекции, которая была посвящена поставке, ориентированной на продукт, для цепочки поставок. Стоимость обслуживания существенно влияет на капиталистические выгоды, которые вы можете получить от вашего программного проекта. Идеально, вы хотите, чтобы ваш программный проект имел очень высокую прибыльность, но для этого вам нужно убедиться, что у вас нет огромных затрат на обслуживание. Эти затраты полностью уничтожат капиталистическую прибыль и доход, которые вы можете получить от вашего программного инвестиционного проекта.
Самая большая проблема здесь, снова с точки зрения цепочки поставок, заключается в том, что самый простой способ минимизировать затраты на обслуживание - сосредоточиться на том, что не меняется. Как я уже упоминал ранее, большая часть затрат связана с теми вещами, которые случайно меняются, либо в экосистеме программного обеспечения, либо в мире в целом. Однако, если вы сосредоточитесь на том, что не меняется, то получите в основном основную часть вашего программного обеспечения, которая будет медленно устаревать, потому что, именно, большая часть того, с чем ваше программное обеспечение справляется, - это то, что не меняется.
Проблема заключается в том, что сосредоточиться на том, что не меняется, гораздо сложнее, чем сказать, потому что у вас есть очень человеческая сила, которая противодействует этому намерению: страх пропустить что-то важное. Когда вы смотрите на прессу, СМИ, ваших коллег и т. д., будет постоянный поток новинок, модных слов и каждое модное слово имеет эту потребность, из-за страха пропустить что-то важное, просто сделать это и не оставаться позади. Например, все эти модные слова могут быть ИИ, блокчейн, интернет вещей и все эти вещи, которые очень актуальны. Я считаю, что в цепочке поставок эти модные слова действительно отвлекают и значительно способствуют проблемам с обслуживанием, потому что они отвлекают от того, что не меняется. Напротив, когда вы начинаете обращать внимание на эти модные слова, вы едете на волне и занимаетесь именно теми вещами, которые очень вероятно будут меняться со временем, тем самым увеличивая ваши затраты на обслуживание со временем.
Теперь, когда мы закончили с основным взглядом на программную инженерию, давайте углубимся в ряд личных сокровищ, которые, надеюсь, окажутся полезными для осуществления программных инициатив с учетом цепочки поставок. Одна из самых частых проблем при работе с программными специалистами - это неправильное представление о собственной идентичности, и я позаимствую эту идею у предпринимателя по имени Пол Грэм. Инженер, например, скажет: “Я - инженер Python”. Хотя это может быть не так крайне, очень часто программные инженеры воспринимают свою собственную идентичность через набор технологий, которыми они владеют и которые составляют их набор навыков. Это путаница между их идентичностью и их текущим набором навыков обычно усиливается практиками найма, которые преобладают в IT- и программном мире в целом. С точки зрения найма, есть много компаний, которые заявляют в своих объявлениях о вакансиях: “Мне нужен программист Python”. Таким образом, внезапно правильная идентичность - это не только вопрос восприятия; к этому прикреплены финансовые вознаграждения за наличие правильной идентичности, правильной метки, правильного тега, который вы можете прикрепить к себе, делая вас более привлекательным на рынке.
Однако такое восприятие, связанное с идентичностью, где технологии становятся прикрепленными к программисту, приводит к многочисленным проблемам, которые затрагивают практически каждый программный проект, а особенно проекты программного обеспечения для цепочки поставок. Когда вы взаимодействуете с человеком, обычно программным инженером, у которого идентичность тесно связана с технологией, используемой в вашей компании, проблема заключается в том, что каждая критика технологии склонна восприниматься с личной стороны. Если вы говорите, что я - программист Python, и критикуете мое программное обеспечение, я воспринимаю это лично. Проблема заключается в том, что как только люди воспринимают критику технологии как личную критику, становится очень сложно рассуждать о проблемах. Эти программные инженеры, к сожалению, будут склонны отклонять все отзывы, просто потому, что они частично видят это как личную критику.
Напротив, если компания случайно использует технологию, которая не является технологией, воспринимаемой программным инженером как основную идентичность, например, ваша компания имеет некоторые системы, реализованные на Java, и у вас есть программный инженер, который говорит: “Я - программист Python”, то все проблемы будут восприниматься через призму того, что эта технология ниже уровнем. Опять же, это еще одна проблема, когда критика и отзывы будут отклоняться как отношение “не моя проблема; это просто из-за этой очень плохой технологии, которая случайно была использована здесь и сейчас в этой компании”. В обоих ситуациях, когда у программного инженера есть идентичность, связанная с технологией, которую вы используете, или идентичность, связанная с технологией, которую вы не используете, возникает целый ряд проблем, и обратная связь отклоняется вместо использования ее для улучшения технологии.
Теперь, с точки зрения цепочки поставок, мы должны помнить, что окружающая среда цепочки поставок невероятно хаотична, и поэтому проблемы будут возникать постоянно. Именно из-за этого окружающего хаоса очень важно иметь команды программных инженеров, которые могут прямо смотреть в глаза этим проблемам и что-то с ними делать, а не просто отклонять обратную связь, когда она возникает. Крайне важно собирать команды, которые не способствуют драме поверх хаоса цепочки поставок из-за своего восприятия своей идентичности.
Эта идея распространяется и на программных инженеров, которые часто выбирают технологии, соответствующие их личности или личности, которую они хотят приобрести. Они выбирают технологию, чтобы приобрести навыки, чтобы добавить еще одно ключевое слово в свое резюме. Однако такой подход приводит к выбору технологий по причинам, не связанным с решением проблем, с которыми сталкивается компания. Это неправильная перспектива для принятия решения о том, является ли технология соответствующей или адекватной для решения конкретных проблем, с которыми сталкивается организация.
Создание резюме может быть мощным мотиватором для программных инженеров, так как существуют реальные финансовые выгоды, связанные с наличием списка ключевых слов в нем. Лучшие компании по разработке программного обеспечения часто относятся недоброжелательно к резюме с длинным списком ключевых слов. Как генеральный директор Lokad, если я вижу резюме с половиной страницы ключевых слов, оно сразу же отклоняется. Однако многие компании, особенно среднего уровня, активно ищут людей с большим количеством ключевых слов, полагая, что эти люди будут невероятно универсальными и гибкими внутри организации. Из моего опыта это часто наоборот.
Продолжая тему личности и создания резюме, важно обратить внимание на то, что архитекторы программного обеспечения не должны слишком привязываться к какой-либо конкретной технологии. Уже сложно найти программных инженеров, поэтому иногда приходится идти на компромиссы. Однако, когда речь идет о архитекторах программного обеспечения, компромисс в виде выбора людей с эмоциональной привязанностью к определенной технологии может быть катастрофическим. Эти люди окажут значительное влияние на вашу компанию.
Эта проблема предвзятости в создании резюме не ограничивается программными инженерами или специалистами по программному обеспечению. Она также возникает среди ИТ-персонала. Например, я встречал нескольких директоров ИТ в крупных компаниях, которые хотели перейти на SAP, в то время как их существующая устаревшая ERP была вполне пригодной. Огромные затраты, связанные с переходом на SAP, никогда не окупятся ожидаемыми преимуществами более современного ERP. В этих случаях играл иррациональное поведение, когда личный интерес директора ИТ в развертывании SAP в его резюме превосходил интерес самой компании.
С точки зрения управления цепями поставок, важно обратить внимание на эти конфликты интересов. Для обнаружения конфликтов интересов не требуется особого программного обеспечения или компетенции. В других областях, таких как медицинская наука, даже врачи могут назначать неправильные лекарства из-за конфликтов интересов, даже когда на кону стоят жизни. Это демонстрирует, что конфликты интересов являются чрезвычайно токсичными. Представьте себе, как эти проблемы разворачиваются в управлении цепями поставок, где на кону не стоят жизни, а главной заботой является деньги. В этом контексте еще меньше сопротивления развертыванию конфликтов интересов.
В отличие от физического мира, программный мир предлагает очень мало ограничений в отношении того, как приступать к программным инициативам и подходить к работе. Человеческая природа не любит пустоту, и люди могут быть неуверенными из-за отсутствия структуры. В результате появилось множество практик, которые появляются с каждой новой практикой приходит понятие ортодоксии. Некоторые примеры этих практик включают экстремальное программирование, доменно-ориентированный дизайн, тестирование на основе дизайна, микросервисы, Scrum и гибкое программирование. Существует множество практик, и каждый год появляются новые.
С каждой практикой приходит понятие ортодоксии. Как только люди начинают следовать практике, они могут задаваться вопросом, придерживаются ли они основных принципов. Программные инженеры - это просто люди, и люди любят ритуалы и племена. Практика дает ощущение принадлежности к племени с общими убеждениями. Вот почему вы также найдете встречи, связанные с этими практиками, удовлетворяющие очень человеческой потребности.
Бывает сложно и даже депрессивно смотреть на проблему, не зная ничего наверняка и имея почти никого, с кем можно связаться, чтобы решить эту проблему. Интересно то, что, хотя практика может быть сомнительной или слегка иррациональной, преимущества могут быть реальными. Реклама практики внутри и вне вашей компании может повысить мораль и помочь привлечь потенциальных соискателей.
На собеседовании, когда люди спрашивают о том, как вы работаете, не очень убедительно говорить, что вы импровизируете и не имеете правил. Эффективнее вдохновить уверенность, представив практику так, будто она решит проблемы внутри компании. Главный момент в том, что в краткосрочной перспективе эти практики не все плохи, даже если они в основном иррациональны. Создание чувства принадлежности может быть полезным. Однако это становится ядовитым, если практики принимаются слишком серьезно или слишком долго. Практика может быть интересной только потому, что она заставляет вас посмотреть на проблему с другого ракурса. Но как только вы посмотрели на проблему с другого ракурса, вам следует попытаться найти еще один ракурс. Вы не должны придерживаться одного ракурса слишком долго. С точки зрения цепочки поставок, это иллюстрирует радикальную странность программной сферы.
На производственном участке превосходство означает всегда делать одно и то же. В программном мире это совершенно противоположно. Если вы делаете одно и то же, то это рецепт для застоя и неудачи со временем.
Программное обеспечение сложно, а корпоративное программное обеспечение еще более сложно. Часто несколько инженеров работают над определенной инициативой, что приводит к естественной тенденции к специализации. Когда инженер работает над определенной частью кодовой базы, естественно склоняться к тому, чтобы назначить того же человека, когда новые задачи требуют изменения этой же части кодовой базы. Преимущества реальны, поскольку этот человек уже знаком с кодом и может быть более продуктивным.
Основная проблема со специализацией заключается в том, что она может привести к ощущению владения определенными частями кодовой базы, создавая различные проблемы. Существуют два класса проблем, связанных с этим владением: “фактор грузовика” и игры власти. Фактор грузовика относится к риску потери сотрудника, обладающего уникальными знаниями или навыками. Это может быть связано с уходом сотрудника в другую компанию или невозможностью работать по какой-либо другой причине. Игры власти могут возникать, если сотрудник понимает, что его вклад важен для компании, и использует это преимущество, чтобы требовать более высокую зарплату или другие льготы.
По моему опыту, программисты обычно не склонны к играм власти, но эти проблемы могут становиться все более частыми в крупных компаниях. Существует множество практик программной инженерии, которые пытаются решить эту проблему напрямую, такие как парное программирование. Однако главное понимание заключается в том, что слишком много хорошего может быть ядовитым для компании. Лучшее, что можно сделать, это осознавать этот класс проблем, а не просто придерживаться одной конкретной практики, которая предположительно решает проблему. Это потому, что такие практики могут создавать другие проблемы, отвлекать вас или ограничивать вашу способность обращать внимание на другие вещи, которые вы еще не видели. С программной точки зрения главный урок здесь заключается в том, что культура является противоядием для этого класса проблем, а не процессом.
У нас возникает ситуация, когда у нас есть очень тонкий компромисс между повышением производительности, достигаемым за счет специализации людей в частях кода, и рисками, связанными с тем, что эти люди владеют этими частями кода. Вам нужно создать ситуацию, в которой всегда есть некоторая степень избыточности в знаниях о кодовой базе от всей команды, чтобы каждый инженер имел некоторое перекрытие компетенций. Это очень тонкий компромисс, который вам нужно достичь, если вы хотите сохранить хоть какую-то производительность. Единственный способ сделать это на практике - это через хорошо понятную культуру программной инженерии. Нет процесса, который может гарантировать, что люди будут интересоваться работой своих коллег. Нельзя иметь процесс любопытства; это должно быть частью культуры.
Оценка навыков и компетенции программных инженеров сложна, и этот вопрос является ключевым, потому что, хотя программное обеспечение явно является командным делом, и команда больше, чем сумма ее участников, базовый уровень участников команды имеет большое влияние на результативность команды в целом.
Один аспект, который, по моим наблюдениям, часто недооценивается людьми вне программной индустрии, а иногда и внутри нее, - это важность навыков письма. Если вы создаете программное обеспечение, вы обслуживаете две разные аудитории. С одной стороны, у вас есть аудитория машины - ваш компилятор. Вы пишете код, и ваш компилятор примет его или отклонит. Это легкая часть. Ваш компилятор - ваш неутомимый спутник, который скажет вам, правильный ли ваш код или нет. Компилятор полностью предсказуем и обладает бесконечным терпением.
С другой стороны, у вас есть аудитория ваших коллег, которая, вероятно, будет включать в себя вас самого через полгода. Вы пишете код и в конечном итоге забываете его. Через полгода вы посмотрите на написанный вами код и подумаете, что он написан кем-то другим, потому что он кажется таким незнакомым. Когда вы пишете код для своих коллег, преимущество в том, что в отличие от компиляторов, ваши коллеги будут пытаться понять, что вы пытаетесь достичь. Компилятор не пытается понять ваши намерения; он механически применяет набор правил.
Ваши коллеги будут пытаться понять, но, к сожалению, они не такие, как компиляторы. У них нет бесконечного терпения, и их легко запутать и ввести в заблуждение вашим кодом. Вот почему, например, выбор запоминающихся, проницательных и подходящих имен имеет первостепенное значение. Хорошая программа - это не только то, что правильно; даже выбор имен переменных, функций и модулей имеет критическое значение, если вы хотите иметь код, который будет хорошо работать с вашими коллегами, и снова, ваши коллеги включают в себя вас самого через полгода. С точки зрения цепочки поставок, главный вывод заключается в том, что навыки письма имеют первостепенное значение, и я бы пошел дальше и сказал, что навыки письма часто важнее чисто технических навыков. Хорошие навыки письма - это главный навык, который вам понадобится для управления сложностью в вашей цепочке поставок. Управление сложностью вашего прикладного ландшафта - это не большая техническая проблема; это проблема организации идей и элементов и наличия последовательной истории во всем. Это в значительной степени навыки письма, и мы затронули этот аспект в предыдущей лекции под названием “Письмо для цепочки поставок”.
Если навык письма является первостепенно важным для того, чтобы быть хорошим программным инженером, то есть еще один навык, который является первостепенно важным для того, чтобы быть программным инженером вообще: терпение к боли. Я считаю, что это главный навык в смысле того, что требуется, чтобы на самом деле быть программным инженером, не великим, а просто быть им. Более конкретно, когда я говорю о боли, я имею в виду устойчивость к скуке и разочарованию, которые сопровождают процесс разработки программного обеспечения при работе с системами, которые чрезвычайно хрупки, плохо спроектированы и заминированы всевозможными способами, иногда людьми, которых уже давно нет. Когда вы имеете дело с программным обеспечением, у вас под ногами четыре десятилетия накопленных проблем, и вы все время боретесь с этим. Это может быть чрезвычайно раздражающим занятием иногда.
Чтобы дать вам иллюстрацию, как программному инженеру, вам потребуется терпение, чтобы потратить четыре часа на просмотр случайных, полу-мусорных разговоров на веб-форуме, упоминающих код ошибки, похожий на тот, с которым вы сталкиваетесь. Вам придется часами заниматься этой ерундой, чтобы разобраться в сути проблемы, и иногда требуется недели, чтобы исправить кажущуюся тривиальную ошибку. Таким образом, следствием этого является то, что у нас во всей программной индустрии действует очень интенсивный процесс негативного отбора, который отбирает людей, у которых высокая терпимость к боли. Этот процесс отбора имеет два основных последствия.
Сначала, люди, которые остаются программистами, обычно обладают невероятной терпимостью к боли. Когда я говорю о терпимости к боли, я имею в виду устойчивость к разочарованию от постоянных проблем с программным обеспечением. Поскольку вы отбираете людей с невероятной терпимостью к боли, они могут даже не замечать, когда их действия ухудшают ситуацию. Они могут добавлять дополнительные особенности в программные продукты, увеличивая уровень боли при взаимодействии с программным обеспечением для всех, включая себя. Однако, если они обладают невероятной терпимостью к боли, они не обращают внимания. Этот процесс неблагоприятного отбора исключает обычных людей, которые бы обратили внимание, но не стали программистами из-за невозможности переносить боль. Эта проблема особенно остро влияет на программное обеспечение для цепочки поставок, поскольку в нем есть много не очень интересных частей. Некоторые аспекты могут быть необходимыми, но скучными, что означает, что люди с высокой терпимостью к боли, работающие в этой области, могут ухудшить ситуацию из-за изобилия потенциально скучных задач.
Второй аспект этого неблагоприятного отбора заключается в том, что когда люди могут позволить себе роскошь получать меньшую зарплату, чтобы избежать проблем, вызывающих интенсивную боль, они это делают. Если кто-то уже получает хорошую зарплату, он может решить пойти на работу, которая не так хорошо оплачивается, но сопровождается преимуществом в виде меньшей интенсивности боли. Большинство людей, вероятно, поступили бы так, и на практике многие так и делают. Это означает, что люди, которые остаются в этой отрасли, где очень высокая интенсивность окружающей боли, часто те, кто не может позволить себе отказаться от возможности получить более высокую зарплату. Это объясняет, в значительной степени, почему в отрасли программной инженерии много специалистов из Индии и Северной Африки. В этих странах есть довольно хорошие системы образования, которые выпускают хорошо образованных людей, но страны все же относительно бедны. Люди в таком положении не могут позволить себе отказаться от высокооплачиваемых работ в области программной инженерии из-за высокого спроса и более высоких зарплат по сравнению с их базовыми зарплатами. У них нет возможности выбрать что-то другое, и поэтому они становятся очень распространенными в этой отрасли.
Нет ничего плохого в этих странах; это просто механическое применение рыночных сил. Это не суждение, а просто наблюдение. Вот дело в том, что терпимость к боли - это не все, что нужно, чтобы быть отличным программистом. Это всего лишь условие, но если у вас его нет, то вы вообще не программист. Однако, если терпимость к боли - это единственное, что у вас есть, то вы будете довольно плохим программистом. С точки зрения цепочки поставок, урок здесь заключается в том, чтобы обратить внимание на команды, которые собирает ваша компания, как внутренние, так и через поставщиков программного обеспечения. Убедитесь, что собираемые инженеры не обладают только терпимостью к боли в качестве своего единственного навыка, потому что это означает, что у вас будет очень плохой результат в терминах качества программного обеспечения и добавленной стоимости от программного обеспечения. Опять же, терпимость к боли необходима, но это просто недостаточно.
В 1975 году Фредерик Брукс уже указывал на то, что “человеко-месяцы” не являются представительными для создаваемой ценности программного обеспечения и создаваемой ценности программных инженеров в целом. Почти пять десятилетий спустя IT-компании являются одними из крупнейших работодателей в мире. В 2020 году в США в IT-отрасли работало 3 миллиона человек, в то время как в автомобильной промышленности - менее 1 миллиона человек. В IT-отрасли теперь работает как минимум в три раза больше людей, чем в автомобильной промышленности. Большинство этих IT-компаний, некоторые из которых абсолютно гигантские с несколькими сотнями или тысячами сотрудников, больше не выставляют счет по “человеко-месяцам”. Это было в 70-х годах. Теперь мы выставляем счет по “килодням”, что в основном означает тысячу дней труда. Ситуация, вероятно, стала намного хуже по сравнению с проблемой, которую Фредерик Брукс описывал почти пять десятилетий назад, в основном из-за невероятного увеличения масштаба и величины проблемы. Однако большинство ранних уроков по-прежнему актуальны. “Мифический месяц” остается очень интересной книгой о программной инженерии.
В программировании производительность варьирует в огромных пределах. С одной стороны, у вас нет людей с низкой производительностью; у вас есть люди с отрицательной производительностью. Это означает, что когда они начинают работать над программным продуктом, они только ухудшают его. Вы уже не можете даже установить соотношение между производительностью людей. Это гораздо хуже; у вас есть люди, которые будут активно ухудшать ваш продукт. Это огромная проблема. С другой стороны, у вас есть так называемые инженеры 10x, люди, у которых производительность в десять раз выше, чем у среднего инженера, который, надеюсь, имеет положительную производительность. Такие инженеры 10x существуют, но их огромная производительность крайне зависит от контекста. Вы не можете просто перевести инженера программного обеспечения 10x из одной компании в другую или даже из одной должности в другую и ожидать, что он сохранит свою невероятную производительность. Обычно это сочетание уникальных навыков и определенной ситуации, которые порождают такую производительность. Тем не менее, важно помнить, что небольшое количество людей может создать основную часть создаваемой программным продуктом ценности. Иногда все сводится к одному человеку, который создает основную часть всех умных элементов программного обеспечения и истинной добавленной стоимости, в то время как остальные занимаются вещами, которые имеют сомнительную добавленную стоимость, в лучшем случае. Главный урок здесь, выявленный пятьдесят лет назад, заключается в том, что когда у вас есть срок в поставке, единственный разумный вариант - сократить объем программной инициативы. Все остальные варианты хуже.
Добавление людей только ухудшает ситуацию, как часто говорят, что добавление людей в отставшем программном проекте делает его еще более отстающим. Это утверждение Брукса было верным пятьдесят лет назад и по-прежнему актуально. Другие варианты также не работают. Если начать заставлять людей работать сверхурочно, это обернется против вас, потому что люди будут уставшими и будут делать больше ошибок, задерживая продукт еще больше. Если вы попытаетесь снизить качество, вы получите что-то, что больше не будет работать. Эти вещи выйдут из-под контроля и взорвутся в ваших руках, поэтому нельзя идти на компромисс в отношении качества.
С точки зрения поставщика, главный урок здесь заключается в том, что если вы беретесь за любую инициативу, которая, кажется, требует более десяти полноценных программистов, следует поступать с максимальной осторожностью. Обычно это является признаком того, что проблема очень плохо поставлена. Для того чтобы десять человек работали над одним и тем же продуктом одновременно, сохраняя производительность, требуется невероятная командная работа. В сфере поставок я наблюдаю, что люди часто слишком амбициозны в плане масштаба и количества участников. Я видел проекты по миграции ERP с участием 50, 100 или 200 человек, работающих над ними одновременно. Это абсолютно бессмысленно. Для достижения хоть какой-то степени сотрудничества требуются невероятно способные командные игроки, чтобы избежать потери всего из-за трения. Если у вас возникают трудности, сосредоточьтесь на своей программной инициативе, делайте ее короткой и узкой.
Мое последнее наблюдение касается частого недопонимания относительно крупных компаний. Большинство людей скажут, что крупные компании боятся риска, но это не мой опыт. Мой опыт говорит о том, что крупные компании боятся неопределенности, а не риска, хотя с далека эти два понятия могут путаться. С далека рациональное объяснение состоит в том, что крупные компании боятся риска, но на самом деле я наблюдал снова и снова, что крупные компании, столкнувшись с выбором между определенным провалом и неопределенным успехом, всегда предпочтут определенный провал неопределенному успеху.
Крупные компании всегда предпочтут определенный провал неопределенному успеху, снова и снова. Это может показаться непонятным и иррациональным на первый взгляд, но это не так. Крупные компании - это не единое целое; они являются политическими образованиями, состоящими из множества людей. Политика и внешний вид имеют первостепенное значение, особенно в очень крупных структурах.
Поставьте себя на место того, кто отвечает за программную инициативу. С одной стороны, у вас есть инициатива, где результат известен - она провалится. Однако вы действуете по правилам, следуя правилам, и все знают, что она провалится. Никто не будет винить вас за то, что вы играете на безопасность и терпите неудачу, потому что это то, чего они ожидают. Напротив, неопределенный успех выглядит странно. Преследование этого пути означает делать необычные вещи и потенциально наносить ущерб карьере, гораздо больший, чем просто следование правилам.
С точки зрения цепочки поставок, урок здесь заключается в том, что в программном мире крайне важно не подводить себя к неудаче только ради того, чтобы следовать правилам, особенно когда эти правила являются абсолютно бессмысленными. Например, я видел, как компании терпели неудачу десятилетиями, используя методы, такие как ABC-анализ и запасы безопасности, методы, которые можно доказать неверными и гарантировать неудачу соответствующих инициатив. Эти методы неправильны по основным математическим и статистическим причинам, поэтому неудивительно, что они не приносят дополнительной ценности в цепочке поставок. Однако они были предпочтительными, потому что они не казались безумными, будучи материалом учебника.
Остерегайтесь комфорта, который можно получить, подводя себя к неудаче только для того, чтобы устранить неопределенность. Устранение неопределенности - не цель; цель состоит в том, чтобы максимизировать шанс на успех, а не сокращать неопределенность.
В заключение, программная инженерия слишком важна, чтобы оставлять ее только в руках программистов. Программное обеспечение повсюду в цепочке поставок и приводит к механизации интеллектуальной работы. Мы все еще находимся на ранней стадии процесса, но можно с уверенностью сказать, что компании, которые не останутся чрезвычайно конкурентоспособными на этом фронте, будут полностью исключены с рынка обычными рыночными силами. Для цепочки поставок самая большая проблема - это культурная проблема. Это не техническая проблема, а культурная проблема. Программная инженерия вызывает сомнения в том, как мы смотрим на проблемы и подходим к ним. Большинство интуитивных решений обычно оказываются неправильными, и это происходит впечатляющим образом.
В некотором смысле программная инженерия в цепочке поставок связана с приручением хаоса, приручением всей сложности и неопределенности, которая присутствует повсюду в цепочке поставок. Чтобы приручить этот хаос, что будет работой программистов, если сам процесс слишком отполирован или упорядочен, если сам процесс не имеет элемента хаоса в своей сущности, то не останется места для изменений, случайностей или креативности. То, что воспринимается как превосходство, быстро превращается в застой, а затем в неудачу. Для более традиционных компаний самая большая проблема с этим культурным подходом, помимо культурного шока, заключается в том, чтобы отказаться от иллюзии контроля. Ваш пятилетний план миграции ERP - это иллюзия; у вас нет контроля над таким масштабным проектом. Аналогично, ваше деловое предложение, в котором описаны ожидаемые прибыли от вашей текущей инициативы, также является иллюзией.
При решении задач механизации интеллектуальной работы самая большая опасность - это не делать вещи, которые вы не можете полностью обосновать. Самая большая опасность - делать вещи, которые являются полностью иррациональными под видом рациональности.
Давайте посмотрим на вопрос. Следующая лекция состоится в среду, 15 декабря, в то же время, в 15:00 по времени Парижа, и она будет посвящена кибербезопасности. Теперь я посмотрю на вопрос.
Вопрос: Как вы измеряете капиталистический доход от ваших инвестиций в программное обеспечение?
В основном, вы этого не делаете. Измерение является побочным продуктом самого предприятия. Это нечто загадочное, если вы хотите измерить доход от инвестиций. Это предполагает, что вы можете придумать измерение заранее, что обычно предполагается при такого рода вопросах. Это предполагает, что вы можете придумать это измерение перед созданием вашего делового случая сценариями, а затем вы можете принять решение и пройти или не пройти с инвестициями в программное обеспечение. Что я говорю, так это то, что это не работает так с программным обеспечением. Сначала вы делаете вещь, затем вы узнаете, что нужно узнать, и по пути вы даже узнаете, какие преимущества есть. Чтобы направлять ваше действие, вам нужно иметь общее представление. Урок заключается не в том, чтобы делать вещи случайно, но не делать вещи, которые глубоко иррациональны под видом рациональности. Общее понимание, если вы абсолютно уверены в чем-то и ваше чутье говорит вам, что это правильный путь, может быть гораздо более рациональным аргументом по сравнению с модными вычислениями, которые имеют только претензию на рациональность, но основаны на ненадежных числах. Реальность заключается в том, что по мере продвижения в вашем программном предприятии измерения станут более ясными, потому что вы начнете узнавать о том, что вы пытаетесь достичь, а затем вы узнаете, как измерить соответствие того, что вы делаете, тому, что вы должны делать. Измерение - это нечто, что придет как побочный продукт, если вы делаете это хорошо. Однако, в результате этого, это означает, что в отношении программного обеспечения гораздо лучше просто пробовать и быстро терпеть неудачу. Вы не хотите вовлекаться в какие-то массовые обязательства; лучше делать это постепенно, с меньшим количеством людей и высокой производительностью. Вы узнаете по ходу дела, как продолжать.
Но затем возникает другая проблема: как только вы начинаете делать это, руководство в компаниях должно уметь управлять множеством инициатив одновременно. Это очень смущает, особенно для более традиционных компаний, потому что руководство не ожидает, что будет так много инициатив, и все они будут двигаться в разных направлениях. Однако это именно то, что уже происходит в крупных компаниях по разработке программного обеспечения на протяжении десятилетий, и это одно из существенных выводов из инженерии программного обеспечения с человеческой точки зрения.
Вопрос: Не противоречит ли это тому, что у тех, у кого много ключевых слов, нет связи с конкретной технологией?
Я не говорю, что наличие множества ключевых слов защищает вас от связи с конкретной технологией. Это две разные проблемы. Одна из проблем заключается в том, что у человека есть сильная связь между его личной идентичностью, его воспринимаемой идентичностью и его набором навыков. Это проблема номер один. Проблема номер два заключается в том, что создание вашего резюме сопряжено с очень сильным скрытым конфликтом интересов. Мое сообщение заключается в том, с одной стороны, остерегайтесь этих политик идентичности; они чрезвычайно токсичны. Мое второе сообщение - остерегайтесь конфликтов интересов во всех их формах; они также чрезвычайно токсичны.
Теперь, если вы действительно сильно подчеркиваете одну конкретную технологию, вы можете удалить некоторые ключевые слова для технологий, которые вы не одобряете, в своем резюме. Однако обычно эти две проблемы раздельны, и вы даже можете иметь кого-то, кто говорит: “Моя идентичность - я программист Python”, как я показывал на слайде, а затем в вашем резюме указываете 20+ ключевых слов. Две вещи не исключают друг друга; они могут происходить одновременно. Также не недооценивайте тот факт, что иногда идентичность может быть связана с чем-то аспирационным, с чем-то, чего вы хотите достичь. Вы можете сказать: “До сих пор я программировал на Python, но я хочу стать программистом Rust, поэтому я считаю себя программистом Rust, хотя до сих пор я в основном работал с Python”. Возможны самые разные поведения.
Вопрос: Инженерия программного обеспечения считается вспомогательной науки для цепочки поставок. Какие будут вспомогательные науки для инженерии программного обеспечения?
Вероятно, психология, социология и этнология являются актуальными областями, когда речь идет об инженерии программного обеспечения. Если подойти к этому вопросу как к взаимодействию людей, то эти вспомогательные науки являются важными. Чтобы серьезно заниматься инженерией программного обеспечения, необходимо понимать не только технологию программного обеспечения, но и контекст, в котором оно используется, чтобы взаимодействие между людьми имело смысл. Вам не обязательно понимать, что входит в код, но вам нужно понимать такие понятия, как кодовая база или инструменты, которые существуют, и проблемы, которые они пытаются решить. Однако, для целей этой серии лекций о цепочке поставок, мне нужно провести границу и решить, что я включаю, а что не включаю, так как, очевидно, я не могу охватить каждую отдельную область исследований.
Вопрос: Попросите десять умных людей предложить решение, и они предложат более десяти способов. Согласование одного из пяти лучших и последовательное использование его лучше. Как вы сбалансируете эти два противоречащих подхода и преимущества?
Это очень широкий вопрос, но если я попытаюсь сформулировать его в конкретном случае инженерии программного обеспечения, у вас может быть много предложений, но не все из них должны рассматриваться с одинаковым весом. Существует такое умение, как долгосрочное видение программного обеспечения. Когда я говорю, что вам следует сосредоточиться на том, что не меняется, оказывается, что некоторые люди очень хороши в этой работе, а некоторые нет. Опыт играет роль, когда вы хотите определить, кто обладает навыками для этого долгосрочного взгляда и что не меняется. По моему скромному опыту, для того чтобы стать очень хорошим в этом, обычно требуется как минимум 35 лет, а самые лучшие люди старше 60. Чтобы увидеть движение и паттерны, требуется годы опыта.
Когда вы говорите, что у вас есть столько людей, одна иллюзия заключается в том, что все эти решения выглядят хорошо, но это только внешность. Вы не знаете, сколько усилий потребуется, чтобы испытать их. Можно ли просто создать прототип или испытать его? Среди этих десяти человек есть ли те, у которых есть уникальные навыки в определении решений, которые будут ядовиты в долгосрочной перспективе? Помните, что ваши затраты на обслуживание в основном определяются принятыми вами решениями. Есть ли важное решение, которое может навредить вам в долгосрочной перспективе?
Это сложный аспект, и, кстати, человек, который имеет долгосрочное видение, может объяснить, почему определенный вариант в долгосрочной перспективе вызовет все возможные проблемы. Это не просто предчувствие или интуиция. Они скажут вам: “Такое уже было, я это видел в других продуктах”. Есть поговорка: умный человек учится на своих ошибках, а мудрый человек учится на ошибках других. Это очень применимо к данному случаю.
Вопрос: Как предприятия измеряют повышение операционной эффективности за каждый вложенный доллар внедрения программного обеспечения для цепочек поставок?
Это невероятно сложный вопрос. Проблема заключается в непримиримости парадигм. Она исходит из эпистемологии; идея заключается в том, что когда вы переходите от одного способа работы к другому, и эти парадигмы радикально отличаются, большинство мер бессмысленны. Рассмотрим, например, телепродажи по сравнению с электронной коммерцией. Компании по почтовому заказу существуют с середины 19-го века. Если вы начнете смотреть на электронную коммерцию как на улучшение по сравнению с компаниями по почтовому заказу, вы можете попытаться измерить улучшение, но реальность заключается в том, что практически все компании по почтовому заказу обанкротились. Компании электронной коммерции, которые сейчас доминируют, в несколько раз больше, чем самая большая компания по почтовому заказу когда-либо была. Amazon, вероятно, в 100 раз больше самой большой исторической компании по почтовому заказу, и сравнение очень размытое.
Механизация интеллектуальной работы настолько непонятна и загадочна, потому что она не похожа на физическую сферу. В физическом производстве вы можете измерить эффективность с помощью канонических способов. Однако, когда вы начинаете механизировать свою интеллектуальную работу, что вообще означает эффективность? Для компании, например, Amazon, их весь цикл поставок полностью зависит от программного обеспечения. Если люди просто оставались дома и ничего не делали, я подозреваю, что весь цикл поставок продолжал бы работать нормально, даже если бы все эти инженеры ничего не делали в течение дня или двух. Так почему Amazon все равно держит этих инженеров? Потому что они инвестируют в свои улучшения.
Кстати, интересная вещь о Джеффе Безосе - его управленческий процесс, называемый “не соглашаться, но поддерживать”. Он говорит, что есть проекты, где его интуиция как генерального директора говорит ему, что это неправильно, и он не соглашается с проектом. Однако он обязуется поддерживать проект финансово, потому что он нанял и доверяет людям, работающим над ним. Это своего рода шизофренический подход - как генеральный директор, он должен быть высшей властью в компании, но он отказывается от этой власти и говорит: “Я не согласен, но вы можете получить бюджет и продолжать работу”.
Причина такого подхода заключается в том, что программные проекты обычно довольно дешевы. Если кто-то приходит с кажущейся безумной идеей, которая не очень дорогая и не разорит компанию, почему бы не попробовать? Если это сработает, это может быть блестящая идея. Это вызывает культурный шок при переходе от традиционных компаний снабжения, где руководство должно иметь видение и вести команды. В области программного обеспечения лидерство в основном заключается в решении проблем, возникающих среди программных инженеров.
В Lokad, при инвестировании в программное обеспечение, основное внимание не уделяется долларовым доходам. Вместо этого фокусируются на том, решает ли инвестиция фундаментальный аспект управления цепями поставок. Если это является основой для широкого спектра ситуаций в цепях поставок, то это стоит преследовать.
Например, в автомобильной отрасли первостепенной важности является решение проблемы механической совместимости. Вы не продаете автозапчасти, чтобы обслуживать людей; вы продаете запчасти, чтобы обслуживать автомобили. Одна деталь может быть совместима с несколькими автомобилями, и некоторые детали могут иметь механическое перекрытие. Эту проблему необходимо решить, она является основой бизнеса. Если вы не решите ее, кто-то другой сделает это, и вы в конечном итоге будете вытеснены с рынка.
Что касается инвестиций в программное обеспечение, важно рисковать и принимать инновации, пока они не угрожают финансовой стабильности компании.
Вопрос: Неправильно говорить, что большие команды проектов - это нелепо. В системах ERP команда из 10 человек может быть хорошей для разработки, но для крупных проектов требуется больше людей. Для постройки башни требуется больше людей, чем для постройки дома. Можете ли вы прояснить свои комментарии?
Я займу позицию, которая может вызвать антагонизм у многих людей. Средства к существованию миллионов людей зависят от крупных IT-компаний. В США в 2020 году IT-компании представляли три миллиона американских сотрудников. Поэтому, когда я говорю, что нет никакой причины иметь ERP, требующую так много людей, очевидно, все люди, зарабатывающие на продаже больших команд или являющиеся частью такой команды, будут категорически не соглашаться со мной.
Мой контраргумент заключается в следующем: ваше несогласие основано на основных научных причинах, объясняющих, почему работу нельзя выполнить с меньшим количеством людей, или это связано с вашим собственным финансовым интересом в поддержании статус-кво и иметь армию людей для выполнения работы? Если мы посмотрим на все инновации, которые произошли - на творческое разрушение, описанное экономистом Шумпетером - каждый раз, когда происходила важная экономическая инновация, обычно происходило массовое улучшение производительности. Но те, кто отстает от этих изменений, сражались яростно, чтобы предотвратить их осуществление.
ERP-системы - это не новое явление; они существуют уже примерно четыре десятилетия. Большинство ERP-систем, которые я вижу сейчас, не приносят много ценности по сравнению с теми, которые были у компаний один или два десятилетия назад. Я видел много старых ERP-систем, которые вполне нормальны, и новые ERP-системы часто не являются существенно лучше, особенно учитывая миллионы, вложенные в проекты по миграции ERP. В этих масштабных проектах я наблюдаю ужасную производительность со стороны IT-компаний.
Мой контраргумент заключается в том, чтобы посмотреть на компании, такие как JD.com, Amazon или Rakuten. Сколько людей нужно этим компаниям для выполнения подобных задач? Обычно вы получаете невероятные соотношения. Например, Zalando, крупная европейская компания электронной коммерции с штаб-квартирой в Берлине, Германия, создала свою собственную ERP-систему с командой, которая меньше, чем у большинства команд, которые я видел для компаний схожего размера, которым необходимо мигрировать свою ERP-систему. Таким образом, вы видите, что с одной стороны у вас есть компания, как Zalando, способная создать свою собственную ERP-систему, полностью адаптированную к их потребностям. Она отлично справляется с ролью подходящей ERP-системы для них, и стоимость и количество людей, вовлеченных в процесс, являются лишь частью того, что нужно другим компаниям схожего размера, чтобы просто выполнить обновление версии. Стоимость снова является только частью. Я сомневаюсь, что необходимо вовлекать так много людей, и в этом заключается проблема белых воротничковых работ в 21 веке. Чтобы быть очень хорошим сотрудником, вам нужно иметь смелость автоматизировать себя, сделать себя устаревшим.
Это нечто очень особенное. Когда рабочие синего воротничка становились ненужными, это делали другие. Но в настоящее время почти не осталось рабочих синего воротничка. Это требует другого мышления, и вот почему так трудно адаптироваться к этой новой парадигме, в основном из-за программной индустрии. Нет ничего плохого в том, чтобы сделать себя ненужным, потому что на самом деле вы не делаете себя ненужным; человеческому изобретательству нет предела. Вы просто автоматизируете некоторые задачи, освобождая себя для решения следующей задачи, которая еще интереснее предыдущей. Компании, такие как Amazon, не увольняют своих программистов, как только они решают проблему. Они вознаграждают их и продвигают их для решения следующей, более сложной проблемы.
В ответ на вопрос о том, что практики поставок застряли в аналитическом мышлении после Второй мировой войны, я согласен с тем, что для многих компаний, хотя и не для всех, программная инженерия продвинулась. Она определяет себя как процесс, связанный с людьми, или интерпретативный процесс. Я согласен. Программная индустрия - это не только о технологиях. Хотя некоторые должности требуют невероятных количественных технических навыков, большая часть программной индустрии воспринимает себя как имеющую подход, ориентированный на людей, с общей культурой.
В значительной степени я считаю, что доминирование США и Силиконовой долины в области программного обеспечения по всему миру связано с трудностью воспроизведения их культуры. Культура обычно является очень неосязаемой и трудной для документирования. Когда вы документируете ее, вы приручаете хаотический ингредиент, необходимый для инноваций. Если вы документируете культуру, организуете и обрабатываете ее, вы внезапно теряете этот аспект сырого, хаотического возникновения идей и инноваций.
Есть места, такие как Силиконовая долина, где эта культура распространена, и они опережают свое время в этом отношении. Чтобы закончить эту тему, я хотел бы процитировать Уильяма Гибсонаа, который сказал: “Будущее уже здесь, оно просто не равномерно распределено”. Я вижу, что эта культура теперь воспроизводится на гораздо меньших масштабах во многих других местах, и процесс будет продолжаться и расти со временем.
Вот и все на сегодня. Увидимся в следующий раз. В нашем следующем занятии мы будем обсуждать тему, которая может быть довольно угнетающей, но очень важной: кибербезопасность. Увидимся в следующий раз!
