April 4th, 2013

vit_r

Про ёжика в тумане, зазнайство, языки программирования и вериги

Тема началась тут. Потом dz поднял вопрос тут. Так что, несколько замечаний на память.

Про размеры и взрыв сложности



Первым делом, аналогия. Сначала объясню, почему она правильная, а потом, почему она не работает.

Софтверный проект можно представить как военные действия. Впрочем, любое одноразовое производство чего-то существенного, типа разработки велосипеда или строительства стадиона под это подходят.

Аналогия хороша тем, что показывает критерии успеха. Нужен генерал, который единолично руководит и понимает, какие приказы и зачем отдаёт. Нужен штаб, который собирает информацию и разрабатывает план. Нужна чёткая и однозначная система коммуникации. Нужны инициативные и ответственные командиры на местах, которые и приказ выполнят, и людей при этом не угробят. Нужны смелые и профессиональные солдаты. Дальше можно расширять аналогию на разведку, логистику, подготовку... Всё будет в тему. Не зря менеджеры молятся на трактаты древнекитайских военачальников.

Теперь, почему это всё не более, чем теории.

Отличие от военных действий очень простое: нет риска потери жизни. Нет риска пленения или каких-то моральных терзаний в случае глобального провала. При этом очень часто личная выгода находится в прямом противоречием с общими целями. Особенно, если говорить об уровне среднего менеджмента и всяких технических служб, непосредственно в создании продукта участия не принимающих.

То есть, наша программистская армия сверху до низу состоит из потенциальных дезертиров-коллаборационистов с крупными вкраплениями предателей-мародёров.

Конечно, маленькая фирма из десятка человек очень сильно может зависеть от технических результатов. Практически также, как и от коммерческих талантов руководства. Но сравнивать её всё-таки лучше не с крутой разведгруппой, заброшенной в тыл врага, а с шайкой разбойников, вышедших на большую дорогу. (Особенно хорошо такая модель подходит для стартапов. Тут и роль инвесторов прописывается совершенно однозначно.)

Первым же результатом такого положения вещей оказывается то, что система передачи информации перестаёт работать. Главная причина в том, что отправители хотят спрятать или приукрасить реальное положение вещей. Также играет роль то, что что люди хотят сделать себе жизнь проще. Общий результат никого не волнует, и отправителям становится наплевать на получателей. Главное прокукарекать, как приказано, а поймёт ли кто - это уже не их забота.

Под информацией надо понимать всё: и приказы начальства, и отчёты, и просто технические подробности, и исходный код, и комментарии, и сообщения об ошибках.

Наша потенциальная армия превращается в муравейник. То-есть, общая цель и разделение труда ещё существует, но работа идёт на инстинктах. Десяток муравьёв хватаются за одно задание и тянут на себя. Кто сильнее, перетягивает и тащит добычу в муравейник, преодолевая сопротивление коллег с другого конца гусеницы. Кто-то кого-то по ходу дела кусает. Или просто одна группа устраивает потасовку с другой. Над всем этим сидит менеджмент, смотрит сверху на происходящее безобразие, каркает и срёт.

Проекты размером с муравейник встречаются достаточно часто. Сюда можно отнести создание каких-нибудь уникальных сооружений вроде завода, поезда или самолёта. Также к этому относятся критические вещи вроде устройств с тиражом пару миллионов штук. Ещё можно упомянуть софт масштабов операционной системы.

Большие проекты состоят из сотен и тысяч программистов или инженеров. Комната на сорок человек может быть занята одними тестерами, или отдел в двадцать душ будет заниматься только писанием бумажек для поддержки какого-нибудь SPICE.

Естественно, абсолютно разумно разбивать работы на мелкие части с хорошо прописанными интерфейсами и поручать их разным людям и отделам. Но информация по системе идёт так хреново, а генералы и штаб витают в таких недосягаемых высотах, что главная общая цель становится не существенной, и народ начинает работать на то, что видит в пределах краёв своей тарелки.

При этом, в большинстве случаев нет людей, которые владеют информацией об общем состоянии дел и общем планировании, а всё превращается в «стратегическое распределение ресурсов». Кудесники гарвардской школы эффективного управления вступают в свои права.

Бывает ли наоборот? Да. Даже иногда такое видел, правда не в ИТ. Кодовое слово - Genchi Genbutsu, иначе говоря «спустись с небес и посмотри сам».

Инженеры в производстве подписывают все чертежи, чтобы в случае чего суд знал, кого сажать на скамью подсудимых. Среди подписей есть подпись главного инженера. И это тот человек, который на самом деле знает, что происходит со всем проектом. Не в мельчайших деталях, но на уровне, достаточном для понимания. И главные инженеры систем знают всё, что находится в зонах их ответственности. Естественно, за одним исключением: главного по софту.

Ещё важна общая цель. Грубо говоря, мотивация. Джобсу удалось создать iPhone не только потому, что он сам носил прототип в кармане, но и потому, что все сверху до низу на него молились. И выкладывались по полной, наплевав на отдых и здоровье. В свою очередь, менеджмент наверху тоже не мог произвести фигню. Диктатура, особенно религиозная не менее эффективна чем армия.

Так как в подобной конфигурации главный инженер главнее главного менеджера, старая система постепенно вытесняется новым подходом, декларирующим, что процессы важнее людей. Фирмы перестраиваются, сертифицируются, оцениваются по уровням зрелости процессов. В результате, общие цели заменяются общими лозунгами, а прямой доступ к информации красивой документацией. Не трудно догадаться, что в случае проблем виновных в такой системе не найти. Так грубейшие ошибки в разводке кабелей на A380 списали на различия в версиях софта для проектирования.

В довершение хочу отметить, что достаточно нанять сотню индусов, чтобы любой, даже самый маленький проект превратить в огромный муравейник со сложной внутренней жизнью. Именно этим сейчас и занимаются Эффективные Менеджеры™ в крупных компаниях.