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 к 1 между офисными и фабричными рабочими во Франции, и, вероятно, похожей статистике в большинстве развитых стран, это уже не соответствует современной действительности. Речь идет буквально об автоматизации собственной работы, и это означает, что в XXI веке лучшие офисные работники — это те, кто постоянно умеет автоматизировать сам себя, делать себя устаревшими, а затем переходить к чему-то новому. Это представляет собой серьезную проблему для многих компаний, которые до сих пор застряли в мышлении XX века.
Мнения по поводу самого понятия инженерии программного обеспечения расходятся. Одна из самых сильных критик была высказана Эдсгером Дейкстрой, одним из основателей информатики. По его мнению, инженерия программного обеспечения даже невозможна как дисциплина или область исследований, и он утверждал, что она сводится к некой рецептуре «как программировать, если не умеешь». Критика Дейкстры, которая весьма интересна, заключается в том, что инженерия программного обеспечения превращается в своего рода литературу самопомощи, которая обречена на провал. Действительно, если мы предполагаем, что цель инженерии программного обеспечения — обеспечить успех в создании полезного, превосходного программного обеспечения, тогда она в основном обречена. Достижение успеха в программном обеспечении невероятно трудно; оно так же сложно, как успех в науке. Для этого нужна искра гения, немалая доля удачи, и не существует никакого рецепта. Более того, каждый успех, как правило, поглощает ту возможность, которая была необходима для его достижения, и поэтому весь процесс становится нереплицируемым.
Однако я не согласен с мнением, что инженерия программного обеспечения обречена на провал. Я считаю, что главная проблема заключается в определении амбиций инженерии программного обеспечения. Если мы решим, что амбиция инженерии программного обеспечения — это успех в создании программного продукта, то, действительно, она обречена. Однако если мы подойдем к инженерии программного обеспечения как к узкой субдисциплине экспериментальной психологии, я уверен, что сможем получить, с этой точки зрения, очень ценные и применимые на практике выводы, и этот взгляд я и приму в данной лекции. Таким образом, инженерия программного обеспечения касается самих инженеров программного обеспечения и их взаимодействий. Фокус на инженерах программного обеспечения является хорошей отправной точкой, потому что человеческая природа стабильна со временем, в отличие от программных технологий, которые постоянно меняются. Характер людей, которые борются с этой технологией, остаётся неизменным; человеческая природа была крайне стабильной на протяжении очень долгого времени.
Если мы посмотрим на другие области, такие как наука, мы увидим, что подход к изучению сферы через призму того, чем занимаются её практики, может быть чрезвычайно плодотворным. Например, в науке уже широко признано, что конфликт интересов приводит к плохой науке и искажению знаний. Этот аспект уже был рассмотрен в лекции «Атакующие рыночные исследования для корпоративного программного обеспечения». С этой точки зрения становится ясно, что можно получить выводы, применимые в самых разных областях, если сосредоточиться на самих практиках. Таким образом, инженерия программного обеспечения касается людей, работающих с программными технологиями, их борьбы и процессов, а не столько самой технологии.
Сегодня проходит шестая лекция из четырех глав. Эта глава посвящена вспомогательным наукам цепочки поставок. Эти вспомогательные науки представляют собой элементы, которые, по моему мнению, имеют фундаментальное значение для современной практики управления цепочками поставок, но сами по себе не являются элементами цепочки поставок. Они скорее служат вспомогательными элементами для вашей практики в области цепочек поставок.
До сих пор, в этой четвертой главе, мы начали с физики вычислений, касающейся современных компьютеров, а затем поднялись по лестнице абстракций. Мы перешли от компьютеров к алгоритмам, которые представляют собой мельчайшие интересные элементы программного обеспечения. Затем мы перешли к математической оптимизации, которая представляет интерес для цепочек поставок, а также для множества других проектов, таких как машинное обучение. Мы видели, что математическая оптимизация напрямую интересна для цепочек поставок, но также напрямую актуальна для машинного обучения, которое, в свою очередь, также представляет интерес для цепочек поставок.
Что касается математической оптимизации и машинного обучения, то большинство интересных концепций и парадигм в наше время носят программный характер. Это не просто простые алгоритмы; это нечто невероятно выразительное, что требует рассмотрения через призму языков программирования. Именно поэтому последняя лекция была посвящена языкам и компиляторам.
Сегодня мы продолжаем подниматься по этой лестнице абстракций, и наше внимание сосредоточено на людях, а не на том, чем они занимаются. Мы будем концентрироваться на самих инженерах программного обеспечения, и в этом заключается суть данного анализа инженерии программного обеспечения.
Сегодня я представлю два набора взглядов на инженерию программного обеспечения. Сначала я изложу мейнстримное представление, которое, по моему мнению, доминирует в этой области. К сожалению, это мейнстримное представление вызвало критику, как уже упоминалось ранее, поскольку люди предлагают подходы самопомощи, с которыми, в том числе и я, имеем основания не соглашаться, так как они не отражают реалистичных амбиций для дисциплины инженерии программного обеспечения. Тем не менее, я рассмотрю это мейнстримное представление, хотя бы потому, что некоторые ошибочные взгляды до сих пор чрезвычайно популярны. Ознакомленность с этими заблуждениями имеет первостепенное значение, если только для того, чтобы выявить некомпетентных людей, которые могут поставить вашу цепочку поставок под угрозу своей некомпетентностью.
Затем я перейду к взгляду с передовой, представляющему собой совокупность элементов, основанных на моем личном опыте в качестве генерального директора компании по разработке программного обеспечения, работающей именно в области корпоративного программного обеспечения для цепочек поставок. Как мы увидим, эти выводы касаются в основном людей, а не самой технологии.
Мейнстримное представление об инженерии программного обеспечения утверждает, что инициатива по созданию программного обеспечения начинается со сбора требований для интересующего продукта. Большинство программных инициатив в крупных компаниях придерживаются этого подхода через процесс, который обычно начинается с запроса предложений (RFP), запроса котировок (RFQ) или запроса информации (RFI). Этот подход унаследован от практик XX века, оказавшихся чрезвычайно успешными в машиностроении и строительстве. Однако я считаю, что когда речь идёт о программном обеспечении, эти методы сбора требований глубоко ошибочны.
В программном обеспечении вы не знаете, чего хотите; просто не знаете. Определить, чего вы хотите, всегда является самой сложной частью. Например, если рассмотреть простую задачу, такую как пополнение запасов, условие задачи чрезвычайно просто: в любой момент времени я хочу знать, какое количество следует пополнить или заказать заново для каждого отдельного SKU. Сама задача проста, но определение оптимального количества становится чертовски сложным и трудным. Как правило, уточнение требований значительно сложнее, чем написание фрагмента программного обеспечения в чистом виде.
Только сталкивая свою интуиция с отзывами реального мира, вы можете постепенно позволить требованиям возникать. Требования не сваливаются с неба; их можно получить только через достаточно экспериментальный процесс, и вам необходимо взаимодействовать с реальным миром. Однако единственный способ установить это взаимодействие — иметь программный продукт, поскольку сбор требований по своей сути является весьма эмпирическим и развивающимся процессом. Проблема в том, что к моменту, когда вы завершите сбор требований, обладание ими становится бессмысленным: если у вас уже есть требования, это означает, что у вас уже есть соответствующий продукт, реализующий эти требования. Так что, когда вы наконец получаете доступ к истинным требованиям, у вас уже есть продукт в эксплуатации, функционирующий, и тот факт, что требования существуют, становится несколько несущественным.
Таким образом, суть в том, что начинать процесс через призму требований — это, как я считаю, безумие. Требования, вероятно, должны появиться в завершении проекта в виде поздней документации, где вы фиксируете все ключевые причины, побудившие вас реализовать продукт именно так, а не иначе.
Как только требования изложены, классический подход гласит, что необходимо перейти к фазе проектирования. Я согласен, что в какой-то момент может иметь место определённое проектирование. Однако вид мышления, присущий этой фазе, часто оказывается ошибочным. Проблема сводится к контролю стоимости изменений. Классическая, не связанная с программным обеспечением, точка зрения на стоимость изменений заключается в том, что она возрастает экспоненциально со временем. Например, если вы изменяете дизайн автомобиля на очень ранней стадии, когда работаете только с чертежом, стоимость изменений минимальна. В отличие от этого, если вы ждёте, пока миллионы таких автомобилей окажутся на дорогах, стоимость изменений становится невероятно высокой, поскольку это подразумевает отзыв, который может быть чрезвычайно дорогим.
Однако, в отличие от физической сферы, в области программного обеспечения стоимость изменений не растёт по своей природе экспоненциально. Увеличение стоимости не может быть полностью устранено; однако в значительной степени его можно контролировать. Действительно, стоимость изменений со временем растёт, в основном потому, что кодовые базы, как правило, увеличиваются с течением времени. Я никогда не видел, чтобы кодовая база корпоративного программного обеспечения существенно сокращалась с года в год; она, как правило, продолжает расти. Тем не менее, возможно в определенной мере контролировать стоимость изменений.
В настоящее время этот аспект становится все более признанным, даже в кругах разработчиков программного обеспечения. Кстати, в этом суть методологии Agile. Возможно, вы слышали, как люди говорят: «О, у нас есть эта Agile-методология разработки». Одна из главных целей методологии Agile — контролировать стоимость изменений. Я не собираюсь подробно останавливаться сегодня на мелких деталях Agile, но достаточно сказать, что я считаю этот подход несколько ошибочным, когда речь заходит о том, как именно контролировать стоимость изменений.
Я заметил, что стоимость изменений в основном возникает из решений, принимаемых относительно программного обеспечения и, более конкретно, из того факта, что очень трудно устоять перед искушением принимать решения. Представьте, что вы рассматриваете потенциальный будущий программный продукт, и предстоит принять множество решений. Первая попытка будет состоять в том, чтобы принять эти решения просто для того, чтобы прояснить, что у вас перед глазами. Напротив, очень хорошая фаза проектирования, а не просто хороший дизайн, заключается в способности откладывать все решения, которые не являются абсолютно необходимыми, где продукт не требует того, чтобы эти решения принимались прямо сейчас. Действительно, если вы не принимаете решение, пока его не придется принимать, и пока не установлено, что вам нужно выбрать именно этот подход к проектированию или технологический путь, оно остается открытым и готовым к изменению, поскольку ничего еще не решено.
Один из аспектов контроля стоимости изменений заключается в том, чтобы научиться откладывать все решения настолько, насколько это практически возможно. С точки зрения цепочки поставок это выглядит очень странно, поскольку это означает, что для всех членов команды разработки ПО и для всех, кто наблюдает за продуктом и командой, создается впечатление, будто их держат в неведении. И это еще хуже, потому что их сознательно оставляют в неведении, что весьма озадачивает. Тем не менее, именно так и должно быть, и это должно происходить преднамеренно. Вот почему это, мягко говоря, вызывает беспокойство.
Теперь, если преждевременные решения по проектированию вызваны иногда ошибочной потребностью в контроле, проблемы, связанные с этой потребностью, на этом не заканчиваются. Как только этап проектирования позади, общепринятый взгляд на разработку программного обеспечения гласит, что следует приступить к созданию программного обеспечения, также часто называемой фазой реализации. Обычно это делается посредством представления какой-либо водопадной модели, также именуемой диаграммами Ганта. Это то, что вы видите на экране. Я считаю, что этот подход — диаграммы Ганта и водопады — чрезвычайно токсичен, и токсичность данного подхода не следует недооценивать, когда речь идёт о программном обеспечении. Такой подход фактически настраивает вашу цепочку поставок на провал, по крайней мере, с точки зрения ее программных инициатив.
Гораздо лучший способ понять проблему и подойти к созданию программного обеспечения — рассматривать его как процесс обучения. Создание ПО заключается в том, чтобы изучить все, что необходимо для получения качественного продукта. Это процесс обучения, и все усвоенные элементы являются побочным продуктом того, что вы позволяете миру взаимодействовать с ПО, возникающим в процессе создания. Основная проблема водопадного прогноза заключается в том, что вы прогнозируете то, что собираетесь обнаружить. Это просто невозможно по определению. То, что вы собираетесь обнаружить, было неизвестно до тех пор, пока вы этого не узнали. Вы не можете предсказать свои открытия. Вы можете ожидать их, но не можете планировать мелкие детали того, что вам предстоит открыть. Вы можете иметь предчувствия, но это все, на что вы можете рассчитывать. Идея, что вы можете преобразовать эти расплывчатые интуиции в точный водопадный прогноз, снова является полным безумием.
Кстати, этот небольшой кажущийся парадокс относительно создания программного обеспечения как процесса обучения также объясняет, почему иногда копирование программного продукта может оказаться либо невероятно легким, либо чрезвычайно сложным. Если команда пытается скопировать программный продукт, который уже присутствует на рынке, и эта команда имеет доступ к пониманию или урокам, которые привели к созданию ПО, которое она пытается скопировать, то, как правило, копирование программного продукта — его повторная реализация или переписывание — может быть выполнено за лишь малую долю времени и бюджета, необходимых для первоначального создания ПО. Напротив, если у команды нет доступа к этим высокоуровневым инсайтам, и, например, единственное, к чему она имеет доступ, — это исходный код, то команда очень часто заканчивает с продуктом крайне низкого качества, потому что, по сути, вся обучающая информация или мелкие фрагменты знаний утрачены. Вы просто скопировали поверхностное представление продукта.
С точки зрения цепочки поставок, самая большая проблема заключается в том, чтобы сознательно отказаться и укротить ваше стремление к контролю. Процесс, напоминающий водопад, является выражением компании, которая хочет контролировать процесс. Например, если я скажу: «Давайте возьмем этот проект под контроль», это будет воспринято как нечто вполне разумное. Зачем же делать наоборот? Почему, например, вы заявите: «Давайте оставим этот проект полностью неконтролируемым?» Но реальность такова, что эта степень контроля — полное заблуждение, если говорить о программном обеспечении, и она полностью подрывает вашу способность в конечном итоге поставлять продукт высокого качества. Укрощение вашего стремления к контролю, с точки зрения цепочки поставок, вероятно, является самой большой проблемой в создании программного обеспечения.
С момента появления компьютерных программ они изобилуют ошибками и дефектами. Для устранения этих очевидных проблем общепринятая точка зрения такова, что тестирование должно проводиться. Тестирование бывает разных форм. Что касается необходимости тестирования, я согласен, хотя пока это представляется довольно расплывчатым. Некоторые инструменты подчеркивают, что тестирование должно проводиться после создания, некоторые — что тестирование должно проводиться во время создания, а другие утверждают, что тестирование должно проводиться до создания. Некоторые подходы предусматривают, что тестирование должно проводиться до, во время и после создания программного обеспечения.
Мой общий взгляд на проблему таков: вы должны делать всё необходимое, чтобы сократить цикл обратной связи до минимума. Мы обсуждали этот момент на предыдущей лекции: сокращение цикла обратной связи до минимума имеет критическое значение для того, чтобы получить что-то, что действительно работает в реальном мире. Таким образом, я обычно рекомендую обращать внимание на то, действительно ли ваши действия в области тестирования сокращают этот цикл обратной связи или нет. Например, в большинстве ситуаций я бы не рекомендовал разработку через тестирование (методологию, в которой тестирование выполняется в первую очередь), просто потому что в большинстве случаев тестирование в первую очередь лишь задержит получение обратной связи о вашем программном обеспечении от окружающего мира.
Однако моя самая большая озабоченность относительно тестирования заключается в нераскрытом ограничении, которое, кажется, обычно игнорируется. Тестирование в конечном итоге может оценить соответствие только тем правилам, которые вы сами установили. Проблема в том, что в программном обеспечении нет жестких ограничений. Нет каким-либо «химическим» способом подойти к определению адекватности вашего продукта в отношении проблемы, которую вы пытаетесь решить. Это сильно отличается от физической сферы. Например, в машиностроении существует канонический критерий: размерный допуск детали. Что бы вы ни проектировали в машиностроении, допуск размеров имеет первостепенное значение. Это очевидный и естественный кандидат. Однако в программном обеспечении нет ничего подобного — естественных и очевидных кандидатов.
Проблема здесь сводится к адекватности. Если взять пример из цепочки поставок, такой как safety stocks, то совершенно очевидно разработать автоматизированный набор тестов для проверки расчетов резервного запаса. Реализовать такую логику тестирования очень просто. Однако это не может доказать, что резервы — плохая идея с самого начала. Вы тестируете только то, что вам известно.
Когда мы имеем дело с физическим механизмом, мы ожидаем износа, и поэтому рассчитываем на какое-то обслуживание, чтобы поддерживать его работоспособность. Однако зачем программному обеспечению нужно какое-либо обслуживание, чтобы продолжать работу? Конечно, нам время от времени приходится заменять компьютеры, когда они ломаются. Однако этот аспект крайне незначителен, и в корпоративном программном обеспечении физические поломки машин не составляют даже 10% от реальных затрат на обслуживание. Такое обслуживание существует, но его влияние чрезвычайно невелико.
Тем не менее, обслуживание в корпоративном программном обеспечении имеет первостепенное значение. Затраты на обслуживание огромны. Для многих поставщиков корпоративного ПО обслуживание составляет буквально 80% и более от общих затрат на разработку. Оказывается, что факторы, вызывающие необходимость обслуживания, имеют очень мало общего с физикой. Первый фактор — это готовность платить самих клиентов. Если поставщик может обойтись ежегодной абонентской платой за обслуживание в размере 20% от того, что было заплачено за установку программного обеспечения в первый год, то он и возьмет такую плату. По сути, с точки зрения затрат, стоимость обслуживания определяется готовностью платить корпоративных клиентов.
Второй фактор — это то обслуживание, которое необходимо для поддержания работоспособности самого программного обеспечения. Действительно, с каждым днем окружающая среда продукта отходит от самого продукта. Операционная система продолжает эволюционировать, система баз данных непрестанно изменяется, и то же можно сказать обо всех сторонних библиотеках, используемых в ПО. Ни один программный продукт не является островом. Каждый продукт зависит от множества других программных продуктов, и эти другие продукты развиваются самостоятельно. Разработчики этих программ продолжают работать над ними, и по мере работы они постоянно их изменяют. Таким образом, наступает момент, когда ваш продукт перестает работать из-за несовместимости, потому что вы ничего не сделали, кроме как не пошли в ногу с остальным рынком. Второй фактор — это все обслуживание, которое необходимо для поддержания работы программного обеспечения и его совместимости с остальным рынком.
Третий фактор — это объем работы, необходимый для поддержания полезности продукта. Действительно, программное обеспечение было спроектировано и создано в определённый момент времени, и с каждым днем мир отходит от того, что было заложено при его разработке. Таким образом, даже если ничего по части аппаратной совместимости не ломается, оказывается, что с изменением мира полезность продукта неизбежно уменьшается, потому что мир просто отходит от тех ожиданий, которые были встроены в продукт. Если вы хотите, чтобы программное обеспечение оставалось полезным, его необходимо постоянно обслуживать.
С точки зрения цепочки поставок, обслуживание является большой проблемой, и мы коснулись этого вопроса в предыдущей лекции, посвященной поставке, ориентированной на продукт для цепочки поставок. Затраты на обслуживание существенно влияют на капиталистические выгоды, которые вы можете получить от вашей программной инициативы. В идеале вы хотите, чтобы ваша программная инициатива имела очень высокую отдачу от инвестиций, но для этого нужно позаботиться о том, чтобы не оказаться с огромными затратами на обслуживание, которые полностью нивелируют капиталистическую прибыль и отдачу от вашей инвестиции в программное обеспечение.
The biggest challenge here, again from a supply chain perspective, is that the simplest way to minimize maintenance cost is to focus on what does not change. As I mentioned earlier, most of the costs are related to the things that happen to be changing, either in the software ecosystem or in the world at large. However, if you focus on the things that do not change, then what you get is essentially the bulk of your software that will only decay slowly because, precisely, most of what your software tackles are the things that do not change.
The problem is that focusing on what does not change is easier said than done, because you have a very human force that antagonizes this intent: the fear of missing out. When you are looking at the press, the media, your colleagues, etc., there will be a constant stream of novelty, buzzwords, and every single buzzword has this urge, due to the fear of missing out, to just do the thing and not be left behind. For example, all those buzzwords would be AI, blockchain, IoT, and all those things that are very present. I believe that in supply chain, these buzzwords are really a distraction and they significantly contribute to maintenance problems because they are a distraction from what does not change. On the contrary, when you start looking at those buzzwords, you are riding a wave, and you’re riding exactly the sort of things that are very likely to be changing over time, thus inflating your maintenance cost over time.
Now that we are done with the mainstream view on software engineering, let’s delve into a series of personal nuggets that should hopefully prove useful to conduct software initiatives while keeping supply chain in mind. One of the most frequent problems when dealing with software people is a misconception about their own identity, and I’m stealing this idea from an entrepreneur named Paul Graham. An engineer will, for example, say, “I am a Python engineer.” While it may not be as extreme, it is very frequent that software engineers perceive their own identity through the sort of short series of technologies that they have mastered, which make up their skill set. This confusion between their identity and their current skill set tends to be reinforced by the hiring practices that are prevalent in the IT and software world at large. From a hiring viewpoint, there are many companies that state in their job advertisements, “I need a Python programmer.” So, there is someone on one side thinking, “I am a Python programmer,” and then there is a company that is going to post a job position where it’s basically written, “I need a Python programmer.” Thus, suddenly having the right identity is not just a matter of perception; there are financial rewards attached to having the right identity, the right label, the right tag that you can attach to yourself, making you more attractive in the market.
However, this identity-driven perception, where technologies become attached to oneself as a software engineer, leads to numerous issues that impact pretty much every single software project, and supply chain software projects in particular. When interacting with a person, typically a software engineer, who has their identity strongly attached to the tech that is in place in your company, the problem becomes that every criticism of the tech tends to be taken from a personal angle. If you say that I am a Python programmer and you critique my software, I take it personally. The problem is that as soon as people take criticism of the tech as personal criticism, it becomes very difficult to reason about those problems. These software engineers will, unfortunately, tend to deflect all the feedback, just because they partially see it as personal criticism.
Conversely, if the company happens to be using a technology that is not the technology perceived as core identity by the software engineer, for example, your company has some systems implemented in Java and you have a software engineer that says, “I am a Python programmer,” then all the problems will be perceived through the lens that this piece of technology is subpar. Again, that’s another problem where the criticism and feedback will be deflected as an attitude of “not my problem; this is just because of this very poor technology that happened to be used here and now in this company.” In both situations, whether the software engineer has an identity that is attached to the technology you’re using or has an identity attached to a technology you’re not using, it creates a whole series of problems, and the feedback gets deflected instead of being leveraged to improve the technology.
Now, from a supply chain perspective, we have to keep in mind that the supply chain environment is incredibly chaotic, and thus problems will happen all the time. Precisely due to this ambient chaos, it is very important to have teams of software engineers that can look straight into the eyes of these problems and do something about them, and not just deflect the feedback when it happens. It is crucial to assemble teams that do not foster drama on top of supply chain chaos due to their perception of their identity.
This idea extends to software engineers, who often choose technologies that fit their identity or the identity they want to acquire. They pick technology to acquire the skills, so they can add another keyword to their resume. However, this approach leads to choosing technologies for reasons unrelated to solving the problems faced by the company. This is the wrong perspective for deciding whether a technology is relevant or adequate for addressing the specific issues faced by the organization.
Building a resume can be a powerful motivator for software engineers, as there are real-world financial benefits associated with having a list of keywords on it. The very best software companies often look down on resumes with a long list of keywords. As the CEO of Lokad, if I see a resume with half a page of keywords, it is directly discarded. However, many companies, especially mediocre ones, actively seek people with many keywords, thinking that these individuals will be incredibly versatile and agile within the organization. From my experience, this is often the opposite.
Continuing with the topic of identity and resume building, it is vital to pay attention to the fact that software architects should not be too attached to any particular technology. It is already difficult to hire software engineers, so sometimes compromises have to be made. However, when it comes to software architects, compromising by selecting individuals with an emotional attachment to a certain technology can be disastrous. These individuals will have a large-scale impact on your company.
This problem of resume-building bias is not limited to software engineers or software professionals. It also occurs among IT personnel. For instance, I have met several IT directors in large companies who wanted to transition to SAP while their existing legacy ERP was perfectly fine. The massive costs associated with transitioning to SAP would never be offset by the expected benefits of a more modern ERP. In these cases, an irrational behavior was at play, where the personal interest of the IT director in deploying SAP on their resume was trumping the interest of the company itself.
From a supply chain perspective, it is essential to pay attention to these conflicts of interest. It doesn’t take much software skills or competence to detect conflicts of interest. In other fields, such as medical science, even physicians can prescribe the wrong drugs due to conflicts of interest, even when lives are at stake. This demonstrates that conflicts of interest are incredibly toxic. Just imagine how these issues play out in supply chain management, where there are no lives at stake and the main concern is money. There is even less reluctance to let conflicts of interest unfold in this context.
Unlike the physical realm, the software realm offers very few constraints on how to proceed with software initiatives and approach work. Human nature does not like a vacuum, and people can become unsettled by a lack of structure. As a result, numerous practices have appeared over the years and continue to emerge. With each practice comes a notion of orthodoxy. Some examples of these practices include extreme programming, domain-driven design, test-driven design, microservices, Scrum, and agile programming. There are many practices, and new ones emerge every year.
With every practice comes a notion of orthodoxy. As soon as people start following a practice, they may question whether they are adhering to the core principles. Software engineers are just people, and people love rituals and tribes. A practice provides a sense of belonging to a tribe with shared beliefs. This is why you will find meetups associated with these practices as well, fulfilling a very human need.
It can be difficult and even depressing to stare at a problem, unsure about everything, and having almost nobody to relate to when it comes to tackling the issue. The interesting thing is that while a practice can be questionable or slightly irrational, the benefits can be real. Advertising a practice inside and outside your company can boost morale and help hire prospective applicants.
In a job interview, when people ask about how you work, it is not exactly compelling to say that you improvise and have no rules. It is more efficient to inspire confidence by presenting a practice as if it will solve problems within the company. The key point is that, in the short term, these practices are not all bad, even if they are mostly irrational. Generating a sense of belonging can be beneficial. However, it becomes poisonous if practices are taken too seriously or for too long. A practice can be of interest just because it forces you to look at the problem from a different angle. But once you’ve looked at the problem from a different angle, you should try to find yet another angle. You should not stick with one angle for too long. From a supply chain perspective, this illustrates the radical oddity of the software realm.
On the factory floor, excellence means always doing exactly the same thing. In the software world, it’s the exact opposite. If you’re doing the same thing, then it’s a recipe for stagnation and failure over time.
Software is complex, and enterprise software even more so. Frequently, multiple engineers end up working on a given initiative, which leads to a natural tendency for specialization. When an engineer works on a certain portion of the codebase, there is a natural inclination to assign the same person when new tasks require touching that same portion of the codebase. The benefits are real, as this person is already familiar with the code and can be more productive.
The main issue with specialization is that it can lead to a sense of ownership over portions of the codebase, creating various problems. There are two classes of problems associated with this ownership: the “truck factor” and power games. The truck factor refers to the risk of losing an employee who possesses unique knowledge or skills. This could be due to the employee leaving for another company or being unable to work for any other reason. Power games can occur if an employee realizes their contribution is vital to the company and uses this leverage to demand a higher salary or other benefits.
In my experience, software engineers typically do not have a strong propensity for playing power games, but these problems can become increasingly frequent in larger companies. There are many software engineering practices that try to tackle this problem head-on, such as pair programming. However, the key insight is that too much of a good thing can be poisonous for the company. The best thing is to be aware of this class of problem, rather than just sticking to one particular practice that is supposed to address the problem. This is because such practices can create other problems, distract you, or restrict your capacity to pay attention to other things that you have not seen yet. From a software perspective, the key lesson here is that culture is the antidote to this class of problems, not process.
We face a situation where we have a very subtle trade-off between the productivity gains achieved by having people specialize in portions of the code and the risks associated with having those people owning those portions of the code. What you want is to cultivate a situation where there is always some degree of redundancy in terms of knowledge about the code base from the entire team, so that every single engineer has some kind of overlap of competency. This is a very subtle trade-off that you need to achieve if you want to maintain any degree of productivity. The only way to actually do that in the real world is through a well-understood culture about software engineering. There is no process that can guarantee people will be curious about the work of their colleagues. You can’t have a process about curiosity; it has to be part of the culture.
Assessing the skills and competence of software engineers is difficult, and this question is key because although software is clearly a team effort and the team is more than the sum of its members, the base level of the members of the team has a big impact on the performance of the team as a whole.
One aspect that I observed to be largely underestimated by people outside the software industry, and sometimes also by people inside the industry, is the importance of writing skills. If you are creating software, you are catering for two distinct audiences. On one side, you have the audience of the machine—your compiler. You write code, and your compiler will accept or reject it. This is the easy part. Your compiler is your indefatigable companion that will tell you if your code is correct or wrong. The compiler is completely predictable and has an infinite amount of patience.
С другой стороны, у вас есть аудитория ваших коллег, которая, скорее всего, будет включать вас самого через шесть месяцев. Вы пишете код и в конечном итоге забываете его. Через шесть месяцев, взглянув на написанное вами, вы подумаете, что его создал кто-то другой, потому что оно кажется вам таким незнакомым. Когда вы пишете код для своих коллег, выгода в том, что, в отличие от компиляторов, ваши коллеги постараются понять, чего вы пытаетесь достичь. Компилятор не пытается понять ваши намерения; он механически применяет набор правил.
Ваши коллеги будут стараться понять, но, к сожалению, они не похожи на компиляторы. У них нет бесконечного терпения, и их легко можно запутать и ввести в заблуждение вашим кодом. Именно поэтому, например, выбор запоминающихся, проницательных и подходящих имен имеет первостепенное значение. Хорошая программа заключается не только в том, чтобы всё было корректно; даже выбор имён переменных, функций и модулей имеет решающее значение, если вы хотите, чтобы ваш код хорошо воспринимался коллегами, а, повторюсь, коллегами вы являетесь и вы сами через шесть месяцев. С точки зрения цепочки поставок главный вывод таков: навыки написания текста имеют первостепенное значение, и я бы даже сказал, что навыки письма часто важнее, чем чисто технические умения. Хорошее умение писать – это главное, что понадобится, чтобы укротить сложность, присутствующую в вашей цепочке поставок. Усмирение сложности вашего прикладного ландшафта – это не столько технический вызов, сколько задача по организации идей и элементов, а также по созданию последовательного повествования. Это, по сути, писательские навыки, которые мы затрагивали в предыдущей лекции под названием “Письмо для цепочки поставок.”
Если навык написания текста имеет первостепенное значение для того, чтобы быть хорошим инженером-программистом, существует ещё один навык, необходимый для того, чтобы вообще быть инженером-программистом: устойчивость к боли. Я считаю, что это главный навык в том смысле, что для того, чтобы действительно стать инженером-программистом, а не просто выдающимся, нужно прежде всего уметь терпеть боль. Более конкретно, когда я говорю о боли, я имею в виду способность противостоять скуке и разочарованию, которые сопровождают процесс разработки программного обеспечения в условиях работы с системами, невероятно хрупкими, плохо спроектированными и засорёнными ловушками всевозможного рода, порой созданными людьми, которые уже даже не работают здесь. Когда вы имеете дело с программным обеспечением, под ногами у вас копятся десятилетия проблем, и вы постоянно с этим боретесь. Иногда это может быть невероятно разочаровывающим испытанием.
Чтобы проиллюстрировать, как инженер-программист, вам придётся обладать терпением, чтобы четыре часа рыться в случайных, наполовину мусорных обсуждениях на веб-форуме, где упоминается код ошибки, похожий на тот, с которым вы столкнулись. Вам придётся часами разбираться с этим бредом, чтобы докопаться до сути, а иногда на решение, казалось бы, тривиальной ошибки уходят недели. В итоге это приводит к тому, что во всей индустрии программного обеспечения действует очень интенсивный процесс неблагоприятного отбора, который выбирает людей с высокой устойчивостью к боли. Этот процесс отбора имеет два основных последствия.
Во-первых, люди, остающиеся инженерами-программистами, как правило, невероятно устойчивы к боли. Под устойчивостью к боли я подразумеваю способность противостоять разочарованию от постоянных проблем с программным обеспечением. Так как отбираются люди с поразительной устойчивостью к боли, они могут даже не осознавать, когда их действия усугубляют ситуацию. Они могут добавлять дополнительные причуды в программные продукты, увеличивая уровень дискомфорта при взаимодействии с ними для всех, включая самих себя. Тем не менее, если они чрезвычайно устойчивы к боли, они не замечают этого. Такой процесс неблагоприятного отбора исключает обычных людей, которые обратили бы внимание на проблему, но не стали бы инженерами-программистами, потому что не смогли бы вынести боль. Эта проблема особенно остра для ПО в цепочке поставок, поскольку многие его части не являются захватывающими. Некоторые аспекты могут быть необходимыми, но обыденными, что означает, что люди с высокой устойчивостью к боли, работающие в этой сфере, могут усугублять ситуацию из-за изобилия потенциально скучных задач.
Второй аспект этого процесса неблагоприятного отбора заключается в том, что когда люди могут позволить себе выбирать работу с более низкой зарплатой, чтобы избежать проблем, вызывающих сильную боль, они так и поступают. Если кто-то уже хорошо зарабатывает, он может решить пойти на работу, которая не так высокооплачиваема, но обещает меньше страданий. Большинство людей, вероятно, поступят так, и на практике многие действительно так делают. Это означает, что люди, остающиеся в этой индустрии, где присутствует чрезвычайно высокая интенсивность постоянно присутствующей боли, зачастую являются теми, кто не может позволить себе отказаться от возможности получить более высокую заработную плату. Это во многом объясняет, почему значительное число инженеров-программистов приходит из Индии и Северной Африки. Эти страны имеют достаточно хорошие системы образования, которые выпускают хорошо образованных специалистов, но сами страны остаются относительно бедными. Люди в таких условиях не могут позволить себе отказаться от высокооплачиваемых вакансий в программной инженерии из-за высокого спроса и более высоких зарплат по сравнению с их базовыми. Им не хватает роскоши выбирать что-то иное, и поэтому они становятся очень распространёнными в этой индустрии.
В этих странах ничего неправильного нет; это всего лишь механическое применение рыночных сил. Это не оценка, а всего лишь наблюдение. Дело в том, что устойчивость к боли – это не всё, что нужно, чтобы стать отличным инженером-программистом. Это просто условие, и если его нет, то вы вовсе не инженер-программист. Однако, если устойчивость к боли – это единственное, что у вас есть, вы окажетесь довольно посредственным инженером-программистом. С точки зрения цепочки поставок, урок здесь заключается в том, чтобы внимательно относиться к тем командам, которые формирует ваша компания, будь то внутренние сотрудники или специалисты со стороны через поставщиков программного обеспечения. Убедитесь, что инженеры, привлечённые в команду, не ограничиваются лишь устойчивостью к боли, потому что это приведёт к очень плохому результату с точки зрения качества ПО и добавленной ценности от него. Опять же, устойчивость к боли необходима, но её недостаточно.
В 1975 году Фредерик Брукс уже указывал, что человеко-месяцы не отражают ценности, создаваемой программным обеспечением, и той ценности, которую приносят инженеры-программисты в целом. Почти через пять десятилетий ИТ-компании становятся одними из крупнейших работодателей в мире. В 2020 году в США в ИТ-индустрии работало 3 миллиона сотрудников, в то время как во всей автомобильной отрасли их было меньше миллиона. Сейчас в ИТ-секторе как минимум в три раза больше людей, чем в автомобильной промышленности. Большинство этих ИТ-компаний, некоторые из которых абсолютно гигантские с несколькими сотнями или тысячами сотрудников, уже не рассчитывают стоимость работы по человеко-месяцам. Это были 70-е годы. Сейчас мы работаем по принципу “кило-дней”, то есть за тысячу рабочих дней. Ситуация, можно утверждать, стала намного хуже по сравнению с проблемой, которую описывал Фредерик Брукс почти пять десятилетий назад, прежде всего из-за невероятного увеличения масштабов и интенсивности проблемы. Однако большинство ранних уроков остаются актуальными. “Мифический человеко-месяц” остаётся очень интересной книгой о программной инженерии.
В программном обеспечении производительность варьируется чрезвычайно. С одной стороны, у вас не просто люди с низкой производительностью; есть люди с отрицательной производительностью. Это означает, что когда они начинают работать над программным продуктом, они только ухудшают его. Вы уже не можете определить соотношение между производительностью разных людей. Ситуация ещё хуже: есть люди, которые активно снижают качество вашего продукта. Это огромная проблема. С другой стороны, имеются так называемые 10-кратные инженеры, люди, чья производительность в десять раз выше, чем у среднего инженера, у которого, надеюсь, положительная производительность. Такие 10-кратные инженеры действительно существуют, но эта гигантская производительность чрезвычайно зависит от контекста. Вы не можете просто перевести 10-кратного инженера-программиста из одной компании в другую или даже с одной должности на другую и ожидать, что он сохранит свою невероятную эффективность. Обычно это сочетание уникальных навыков и конкретной ситуации, которые и создают эту производительность. Тем не менее, важно помнить, что совсем немного людей могут генерировать основную массу ценности программного продукта. Иногда всё сводится к одному человеку, который создаёт почти все умные элементы кода и реальную добавленную стоимость, в то время как остальные занимаются вещами, ценность которых, в лучшем случае, сомнительна. Ключевой урок, выявленный пять десятилетий назад, заключается в том, что когда вы бежите к дедлайну в цепочке поставок, единственный разумный вариант – сократить масштаб программной инициативы. Все остальные варианты хуже.
Прибавление сотрудников только ухудшает ситуацию, ведь часто говорят, что добавление людей к опаздывающему проекту только его задерживает. Это утверждение Брукса было справедливым пять десятилетий назад и остаётся актуальным до сих пор. Остальные варианты тоже не работают. Если вы начнёте заставлять людей работать сверхурочно, это обернётся против вас, потому что люди устали и совершают больше ошибок, что ещё больше задерживает продукт. Если попытаться снизить качество, в итоге получится нечто, что уже не будет работать. Всё это выйдет из-под контроля и разорвётся у вас на глазах, поэтому на качестве экономить нельзя.
С точки зрения цепочки поставок, ключевой урок заключается в том, что если вы берётесь за инициативу, которая, по-видимому, требует более десяти штатных инженеров-программистов, действуйте с предельной осторожностью. Обычно это признак того, что проблема сформулирована крайне неудачно. Требуется невероятная командная работа, чтобы десять человек могли одновременно работать над одним продуктом и при этом сохранять продуктивность. В цепочке поставок я замечаю, что люди часто слишком амбициозны в отношении масштабов и числа участников. Я видел проекты по миграции ERP, в которых одновременно работало 50, 100 или 200 человек. Это абсолютно нелепо. Добиться какого-либо уровня сотрудничества могут только невероятно способные командные игроки, чтобы не потерять всё из-за трения. Если у вас возникают трудности, держите свою программную инициативу узкой, короткой и сфокусированной.
Мое окончательное наблюдение касается частого недопонимания больших компаний. Большинство людей считают, что крупные компании избегают риска, но мой опыт говорит об обратном. По моему опыту, крупные компании избегают неопределенности, а не риска, хотя на первый взгляд эти понятия могут путаться. С расстояния логичное объяснение может заключаться в том, что крупные компании опасаются риска, но на деле я неоднократно наблюдал, что, столкнувшись с выбором между гарантированным провалом и неопределённым успехом, крупные компании неизменно выбирают уверенность провала вместо неопределённого успеха.
Крупные компании неизменно отдают предпочтение гарантированному провалу вместо неопределённого успеха, раз за разом. Это может показаться озадачивающим и нерациональным на первый взгляд, но это не так. Крупные компании – не единое целое; они являются политическими организмами, состоящими из множества людей. Политика и видимость играют первостепенную роль, особенно в очень крупных структурах.
Рассмотрите точку зрения того, кто отвечает за программную инициативу. С одной стороны, у вас есть инициатива, исход которой определён – она провалится. Однако вы действуете по правилам, следуете установленным нормам, и все знают, что она потерпит неудачу. Никто не будет обвинять вас за то, что вы играли по правилам и потерпели провал, ведь именно этого от вас ожидают. Напротив, неопределённый успех выглядит странно. Выбор этого пути означает делать нечто необычное и потенциально вредное для карьеры, гораздо более рискованное, чем просто следовать правилам.
С точки зрения цепочки поставок урок здесь в том, что в мире программного обеспечения крайне важно не ставить себя на путь к провалу лишь ради того, чтобы следовать правилам, особенно когда эти правила совершенно абсурдны. Например, я видел, как компании терпели неудачу десятилетиями, используя такие методы, как ABC-анализ и страховые запасы – методы, которые можно доказать как ошибочные и которые гарантированно ведут к провалу соответствующих инициатив. Эти методы ошибочны по базовым математическим и статистическим причинам, так что неудивительно, что они не приносят добавленной ценности в цепочку поставок. Тем не менее, их считали предпочтительными, поскольку они не казались безумными, являясь учебным материалом.
Остерегайтесь того удобства, которое можно получить, ставя себя на путь к провалу лишь для устранения неопределенности. Устранение неопределенности – не цель; цель состоит в максимизации шансов на успех, а не в снижении неопределенности.
В заключение, программная инженерия слишком важна, чтобы её оставлять только в руках инженеров-программистов. Программное обеспечение повсюду в цепочке поставок и способствует механизации умственного труда. Мы всё ещё находимся на ранней стадии этого процесса, но уже можно с уверенностью сказать, что компании, которые не будут оставаться крайне конкурентоспособными в этой области, будут полностью вытеснены с рынка обычными рыночными силами. Для цепочки поставок самая большая проблема носит культурный характер. Это не техническая проблема, а культурная. Программная инженерия бросает вызов тому, как мы смотрим на проблемы и как мы их решаем. Большинство интуитивных решений оказываются неверными, и то с размахом.
В некотором смысле, программная инженерия в цепочке поставок заключается в укрощении хаоса, в управлении всей той сложностью и неопределённостью, которые царят в цепочке поставок. Чтобы усмирить этот хаос, что и является задачей инженеров-программистов, если сам процесс окажется слишком отполированным или упорядоченным, если в нём не будет элемента хаоса, тогда не останется места для перемен, случайностей или творчества. То, что воспринимается как совершенство, быстро превращается в стагнацию, а затем – в провал. Для более традиционных компаний самая большая проблема такого культурного подхода, помимо культурного шока, заключается в отказе от иллюзии контроля. Ваш пятилетний план миграции ERP – иллюзия; вы не контролируете такой масштабный проект. Аналогичным образом, и ваш бизнес-кейс, описывающий ожидаемую прибыль от вашей текущей инициативы, также является иллюзией.
При попытке механизировать интеллектуальную деятельность, самая большая опасность заключается не в том, чтобы делать то, что вы не можете полностью обосновать рационально. Самая большая опасность – это делать вещи, которые являются полностью иррациональными под видом рациональности.
Давайте взглянем на вопрос. Следующая лекция состоится в среду, 15 декабря, в то же время, в 15:00 по парижскому времени, и будет посвящена кибербезопасности. А теперь я рассмотрю вопрос.
Вопрос: Как измерить капиталистическую отдачу от ваших инвестиций в программное обеспечение?
В основном, нет. Измерение является побочным продуктом самого начинания. Это вызывает замешательство, если вы пытаетесь измерить рентабельность инвестиций. Предполагается, что вы можете заранее придумать меру, что обычно и подразумевается в такого рода вопросе. Предполагается, что вы можете определить эту меру до составления бизнес-кейса с различными сценариями, и затем принять решение, стоит ли инвестировать в программное обеспечение. Я говорю, что с программным обеспечением всё работает не так. Сначала вы делаете дело, затем узнаёте, что нужно узнать, а затем по ходу дела даже обнаруживаете, какие преимущества существуют. Чтобы направлять свои действия, вам необходимо общее понимание на высоком уровне. Урок состоит не в том, чтобы действовать случайным образом, а в том, чтобы не совершать действий, глубоко иррациональных под видом рациональности. Интуиция высокого уровня, если вы абсолютно уверены в чем-то, и ваша интуиция подсказывает, что это правильный путь, может быть гораздо более рациональным аргументом по сравнению с изощрёнными расчётами, которые лишь подразумевают рациональность, но основаны на бессмысленных числах. Реальность такова, что по мере продвижения вашего проекта по разработке ПО измерения станут яснее, потому что вы начнёте понимать, чего хотите достичь, и затем узнаете, как оценить адекватность того, что делаете, по сравнению с тем, что следует делать. Измерение придёт как побочный эффект, если вы всё сделаете хорошо. Однако в связи с этим, в случае с программным обеспечением, гораздо лучше просто пробовать и быстро терпеть неудачу. Вы не хотите вовлекаться в какие-то масштабные обязательства; лучше действовать инкрементально, с участием меньшего количества людей и высокой продуктивностью. Вы научитесь, как двигаться дальше по ходу дела.
Но затем возникает другая проблема: как только вы начинаете делать это, менеджмент в компаниях должен уметь жонглировать множеством инициатив одновременно. Это очень тревожно, особенно для более традиционных компаний, поскольку руководство не ожидает, что так много инициатив будут направлены в разные стороны. Тем не менее, именно это уже происходит в крупных софтверных компаниях на протяжении десятилетий, и это является одной из сущностей выводов программной инженерии с человеческой точки зрения.
Вопрос: Разве не противоречит утверждение, что наличие множества ключевых слов не ассоциируется с конкретной технологией?
Что ж, я не утверждаю, что наличие множества ключевых слов защищает вас от ассоциации с какой-либо конкретной технологией. Это две разные проблемы. Первая — это проблема, когда у человека существует сильная связь между его личной идентичностью, воспринимаемой идентичностью и его навыками. Это первая проблема. Вторая проблема заключается в том, что составление резюме сопровождается очень сильным скрытым конфликтом интересов. Моё послание таково: с одной стороны, берегитесь политики идентичности — она невероятно токсична. С другой стороны, берегитесь конфликтов интересов во всех их проявлениях — они также невероятно токсичны.
Итак, если вы действительно делаете акцент на какой-то одной технологии, вы можете убрать некоторые ключевые слова, относящиеся к тем технологиям, которые вам не нравятся, из вашего резюме. Однако обычно эти две проблемы раздельны, и может быть человек, который говорит: “Моя идентичность заключается в том, что я — программист на Python”, как я показывал на слайде, а затем в своём резюме указывает более 20 ключевых слов. Эти две вещи не взаимоисключающие; они могут происходить одновременно. Также не стоит недооценивать тот факт, что иногда идентичность может быть связана с чем-то стремительным, чем-то, что вы хотите приобрести. Вы можете сказать: “Пока что я программировал на Python, но хочу стать программистом на Rust, так что буду считать себя программистом на Rust, хотя до сих пор в основном занимался Python.” Возможны всевозможные варианты поведения.
Вопрос: Программная инженерия считается вспомогательной наукой для управления цепочками поставок. Какие вспомогательные науки можно назвать для программной инженерии?
Вероятно, психология, социология и этнология — все эти области имеют отношение к программной инженерии. Если вы начнёте рассматривать её, в первую очередь, как взаимодействие людей, то эти вспомогательные науки станут критически важными. Для серьёзной работы в программной инженерии дело не только в технологиях программного обеспечения, хотя вам необходимо понимать контекст ПО, чтобы человеческое взаимодействие имело смысл. Вам не обязательно разбираться, что именно входит в код, но нужно понимать такие понятия, как кодовая база или существующие инструменты и проблемы, которые они пытаются решить. Однако, для целей этой серии лекций о цепочках поставок, мне необходимо провести чёткую грань, определив, что я включаю, а что исключаю, так как, очевидно, не могу охватить каждую область исследований.
Вопрос: Спросите у десяти умных людей решение, и они предложат более десяти способов. Лучше согласиться с одним из пяти лучших и использовать его последовательно. Как вы находите баланс между этими двумя противоречивыми подходами и выгодами?
Это очень широкий вопрос, но если попытаться рассмотреть его в контексте программной инженерии, можно предложить множество вариантов, однако не все следует оценивать одинаково. Существует навык долгосрочного видения в программном обеспечении. Когда я говорю, что нужно сосредоточиться на том, что не меняется, оказывается, что некоторые люди в этом деле превосходны, а некоторые — нет. Опыт играет ключевую роль, когда нужно оценить, у кого есть способность к долгосрочному видению и пониманию неизменного. По моему скромному опыту, человеку обычно требуется не меньше 35 лет, чтобы начать в этом преуспевать, а самые лучшие специалисты — за 60. Требуются годы, чтобы увидеть динамику и закономерности.
Когда вы утверждаете, что у вас есть столько людей, возникает иллюзия, что все эти решения выглядят хорошо, но это лишь внешнее впечатление. Вы не знаете, сколько усилий потребуется, чтобы испытать новшества. Можете ли вы просто создать прототип или проверить это? Среди этих десяти человек, есть ли кто-то с уникальными навыками, способными выявить решения, которые в долгосрочной перспективе окажутся губительными? Помните, что ваши затраты на обслуживание в основном определяются принятыми решениями. Существует ли такое важное решение, которое может навредить вам в долгосрочной перспективе?
Это сложный аспект, и, кстати, тот, кто обладает долгосрочным видением, может объяснить, почему определённый вариант в долгосрочной перспективе приведёт к самым разнообразным проблемам. Это не просто предчувствие или интуиция. Он скажет: “Такое уже было, я видел это в других продуктах.” Есть поговорка: умный учится на своих ошибках, а мудрый — на ошибках других. Это очень применимо в данном случае.
Вопрос: Как предприятия измеряют рост операционной эффективности на каждый доллар, вложенный в внедрение программного обеспечения для цепочек поставок?
Это невероятно сложный вопрос. Проблема заключается буквально в несоизмеримости парадигм. Это происходит из-за эпистемологии; идея в том, что когда вы переходите от одного способа работы к другому, и эти парадигмы кардинально различаются, большинство мер оказывается бессмысленным. Возьмём, к примеру, телемаркетинг против электронной коммерции. Каталоговые компании существовали с середины XIX века. Если вы начнёте рассматривать электронную коммерцию как улучшение по сравнению с каталоговыми компаниями, вы можете попытаться измерить улучшение, но реальность такова, что практически каждая каталоговая компания обанкротилась. Современные компании электронной коммерции доминируют на несколько порядков превосходя самую крупную каталоговую компанию в истории. Amazon, вероятно, в 100 раз больше самой крупной исторической каталоговой компании, и сравнение оказывается довольно размытым.
Механизация интеллектуальной работы настолько тревожна и запутана, потому что она не похожа на физическую сферу. При физическом производстве эффективность можно измерить каноническими методами. Однако, когда вы начинаете механизировать вашу интеллектуальную работу, что вообще означает эффективность? Для такой компании, как Amazon, вся их цепочка поставок полностью управляется программным обеспечением. Если бы люди просто оставались дома и ничего не делали, я подозреваю, что вся цепочка поставок функционировала бы нормально, даже если все эти инженеры без дела в течение одного-двух дней. Так почему же Amazon продолжает держать этих инженеров? Потому что они инвестируют в свои улучшения.
Кстати, интересный факт о Джеффе Безосе — его управленческий процесс, называемый “disagree but commit”. Он говорит, что существуют проекты, по которым его интуиция как генерального директора подсказывает, что они ошибочны, и он с ними не согласен. Однако он берёт на себя обязательство поддерживать бюджет проекта, потому что нанял и доверяет людям, работающим над ним. Это своего рода шизофренический подход — как генеральный директор, он должен быть высшей властью в компании, но отказывается от этой власти и говорит: “Я не согласен, но у вас есть бюджет и можете продолжать.”
Причина такого подхода в том, что проекты по разработке программного обеспечения обычно достаточно дешевы. Если кто-то предлагает на первый взгляд безумную идею, которая не слишком затратна и не обанкротит компанию, почему бы не попробовать? Если это сработает, это может оказаться блестящей идеей. Это представляет собой культурный шок при переходе от традиционных компаний цепочек поставок, где от руководства ожидается видение и умение вести команды. В сфере программного обеспечения лидерство в основном заключается в решении проблем, возникающих среди инженеров по разработке ПО.
В Lokad, при инвестировании в программное обеспечение, основное внимание уделяется не возврату инвестиций в долларах. Вместо этого акцент делается на том, решает ли инвестиция фундаментальный аспект управления цепочками поставок. Если это является ядром для широкого спектра ситуаций в цепочках поставок, тогда это стоит осуществлять.
Например, на вторичном автомобильном рынке первостепенное значение имеет решение проблемы механической совместимости. Вы не продаёте автозапчасти для обслуживания людей; вы продаёте запчасти для обслуживания автомобилей. Одна деталь может быть совместима с несколькими транспортными средствами, и некоторые детали могут иметь механическое пересечение. Эту проблему необходимо решать; она является ядром бизнеса. Если вы её не решите, кто-то другой сделает это, и вас в конце концов вытеснят с рынка.
Что касается инвестиций в программное обеспечение, важно идти на риски и принимать инновации, при условии, что они не угрожают финансовой стабильности компании.
Вопрос: Утверждать, что большие проектные команды нелепы, вводит в заблуждение. В системах ERP 10 человек могут быть достаточными для разработки, но более крупные проекты требуют большего количества людей. Башню строят с большим количеством людей, чем дом. Не могли бы вы уточнить свои комментарии?
Я собираюсь занять позицию, которая может вызвать антагонизм у многих. Жизнеобеспечение миллионов завязано на невероятно крупных IT-компаниях. В США в 2020 году IT-компании обеспечивали рабочими места для трёх миллионов американцев. Поэтому, когда я говорю, что абсолютно нет оснований для ERP-системы, которая требует такого большого количества людей, очевидно, что все, кто зарабатывает на жизнь продажей больших команд или являясь их частью, яростно не согласятся со мной.
Моя контраргументация такова: ваше несогласие исходит из фундаментальных научных причин, объясняющих, почему работу нельзя выполнить с меньшим количеством людей, или это связано с вашими собственными финансовыми интересами по поддержанию статус-кво и наличии целой армии людей для выполнения работы? Если обратить внимание на все произошедшие инновации — творческое разрушение, описанное экономистом Шумпетером — каждый раз, когда происходила важная экономическая инновация, наблюдалось массовое повышение производительности. Но те, кто отставал от прогресса, яростно боролись, чтобы помешать этим инновациям.
ERP-системы — это не новинка; они существуют уже примерно четыре десятилетия. Большинство современных ERP, которые я вижу, не добавляют много ценности по сравнению с теми, что использовались компаниями год или два назад. Я видел множество старых ERP, которые вполне работали, и новые ERP часто не являются существенно лучше, особенно учитывая миллионы, влетающие в проекты по миграции ERP. В этих масштабных проектах я наблюдаю ужасающую производительность IT-компаний.
Моя контраргументация состоит в том, чтобы обратить внимание на такие компании, как JD.com, Amazon или Rakuten. Сколько людей необходимо этим компаниям для выполнения аналогичных задач? Обычно итоговые соотношения оказываются безумными. Например, Zalando, крупная европейская e-компания, базирующаяся в Берлине, Германия, разработала собственную ERP-систему с командой, которая меньше большинства команд, которые я видел в компаниях аналогичного размера, нуждающихся в миграции ERP. Таким образом, с одной стороны, у вас есть компания вроде Zalando, способная самостоятельно разрабатывать ERP, полностью адаптированную под свои нужды. Она отлично справляется со своей ERP-задачей, а затраты и количество вовлечённых людей составляют лишь малую долю от того, что требуется другим компаниям аналогичного размера даже для обновления версии. Затраты опять же лишь малую долю. Я ставлю под вопрос необходимость участия такого большого количества людей, и в этом заключается проблема белых воротничков в XXI веке. Чтобы быть действительно хорошим сотрудником, нужно иметь смелость автоматизировать себя, сделать себя устаревшим.
Это действительно нечто необычное. Когда синие воротнички устаревали, это делали другие. Но в наше время почти не осталось рабочих синих воротничков. Требуется совершенно иной образ мышления, и именно поэтому возникает борьба за адаптацию к этой новой парадигме, в основном исходящая из сферы программного обеспечения. Делать себя устаревшим — это нормально, потому что вы на самом деле не делаете себя устаревшим; нет предела человеческой изобретательности. Вы просто автоматизируете некоторые задачи, освобождая себя для решения следующего, ещё более интересного вызова. Компании вроде Amazon не увольняют своих инженеров сразу после решения проблемы. Они вознаграждают их и продвигают для решения следующей, более сложной задачи.
В ответ на вопрос о том, что специалисты по цепочке поставок застряли в аналитическом мышлении после Второй мировой войны, я согласен, что для многих компаний, но не для всех, программная инженерия сделала шаг вперёд. Она определяет себя как процесс, ориентированный на людей, или интерпретационный процесс. Я действительно согласен. Программная индустрия — это не только жёсткие, основные технологии. Хотя некоторые должности требуют невероятных количественных технических навыков, основная часть программной индустрии рассматривает себя как обладающую подходом, ориентированным на людей, как имеющую общую культуру.
В значительной степени я считаю, что доминирование США и Кремниевой долины в программном обеспечении по всему миру обусловлено сложностью воспроизведения их культуры. Культура, как правило, очень неосязаема и трудна для документирования. Когда вы документируете её, вы укрощаете хаотичный ингредиент, необходимый для инноваций. Если вы документируете культуру, организуете и упорядочиваете её, вы внезапно теряете тот аспект сырой, хаотичной вспышки идей и инноваций.
Есть места, такие как Кремниевая долина, где эта культура преобладает, и они опережают своё время в этом отношении. В заключение по этой теме я хотел бы процитировать Уильяма Гибсона, который сказал: “Будущее уже здесь; оно просто не распределено равномерно.” Я вижу, как эта культура сейчас воспроизводится в гораздо меньших масштабах во многих других местах, и этот процесс будет продолжаться и расти со временем.
Это всё на сегодня. До встречи в следующий раз. В нашем следующем занятии мы обсудим тему, которая может показаться довольно удручающей, но очень важной: кибербезопасность. До встречи в следующий раз!
