Тема началась тут. Потом
dz поднял вопрос тут. Так что, несколько замечаний на память.
Первым делом, аналогия. Сначала объясню, почему она правильная, а потом, почему она не работает.
Софтверный проект можно представить как военные действия. Впрочем, любое одноразовое производство чего-то существенного, типа разработки велосипеда или строительства стадиона под это подходят.
Аналогия хороша тем, что показывает критерии успеха. Нужен генерал, который единолично руководит и понимает, какие приказы и зачем отдаёт. Нужен штаб, который собирает информацию и разрабатывает план. Нужна чёткая и однозначная система коммуникации. Нужны инициативные и ответственные командиры на местах, которые и приказ выполнят, и людей при этом не угробят. Нужны смелые и профессиональные солдаты. Дальше можно расширять аналогию на разведку, логистику, подготовку... Всё будет в тему. Не зря менеджеры молятся на трактаты древнекитайских военачальников.
Теперь, почему это всё не более, чем теории.
Отличие от военных действий очень простое: нет риска потери жизни. Нет риска пленения или каких-то моральных терзаний в случае глобального провала. При этом очень часто личная выгода находится в прямом противоречием с общими целями. Особенно, если говорить об уровне среднего менеджмента и всяких технических служб, непосредственно в создании продукта участия не принимающих.
То есть, наша программистская армия сверху до низу состоит из потенциальных дезертиров-коллаборационистов с крупными вкраплениями предателей-мародёров.
Конечно, маленькая фирма из десятка человек очень сильно может зависеть от технических результатов. Практически также, как и от коммерческих талантов руководства. Но сравнивать её всё-таки лучше не с крутой разведгруппой, заброшенной в тыл врага, а с шайкой разбойников, вышедших на большую дорогу. (Особенно хорошо такая модель подходит для стартапов. Тут и роль инвесторов прописывается совершенно однозначно.)
Первым же результатом такого положения вещей оказывается то, что система передачи информации перестаёт работать. Главная причина в том, что отправители хотят спрятать или приукрасить реальное положение вещей. Также играет роль то, что что люди хотят сделать себе жизнь проще. Общий результат никого не волнует, и отправителям становится наплевать на получателей. Главное прокукарекать, как приказано, а поймёт ли кто - это уже не их забота.
Под информацией надо понимать всё: и приказы начальства, и отчёты, и просто технические подробности, и исходный код, и комментарии, и сообщения об ошибках.
Наша потенциальная армия превращается в муравейник. То-есть, общая цель и разделение труда ещё существует, но работа идёт на инстинктах. Десяток муравьёв хватаются за одно задание и тянут на себя. Кто сильнее, перетягивает и тащит добычу в муравейник, преодолевая сопротивление коллег с другого конца гусеницы. Кто-то кого-то по ходу дела кусает. Или просто одна группа устраивает потасовку с другой. Над всем этим сидит менеджмент, смотрит сверху на происходящее безобразие, каркает и срёт.
Проекты размером с муравейник встречаются достаточно часто. Сюда можно отнести создание каких-нибудь уникальных сооружений вроде завода, поезда или самолёта. Также к этому относятся критические вещи вроде устройств с тиражом пару миллионов штук. Ещё можно упомянуть софт масштабов операционной системы.
Большие проекты состоят из сотен и тысяч программистов или инженеров. Комната на сорок человек может быть занята одними тестерами, или отдел в двадцать душ будет заниматься только писанием бумажек для поддержки какого-нибудь SPICE.
Естественно, абсолютно разумно разбивать работы на мелкие части с хорошо прописанными интерфейсами и поручать их разным людям и отделам. Но информация по системе идёт так хреново, а генералы и штаб витают в таких недосягаемых высотах, что главная общая цель становится не существенной, и народ начинает работать на то, что видит в пределах краёв своей тарелки.
При этом, в большинстве случаев нет людей, которые владеют информацией об общем состоянии дел и общем планировании, а всё превращается в «стратегическое распределение ресурсов». Кудесники гарвардской школы эффективного управления вступают в свои права.
Бывает ли наоборот? Да. Даже иногда такое видел, правда не в ИТ. Кодовое слово - Genchi Genbutsu, иначе говоря «спустись с небес и посмотри сам».
Инженеры в производстве подписывают все чертежи, чтобы в случае чего суд знал, кого сажать на скамью подсудимых. Среди подписей есть подпись главного инженера. И это тот человек, который на самом деле знает, что происходит со всем проектом. Не в мельчайших деталях, но на уровне, достаточном для понимания. И главные инженеры систем знают всё, что находится в зонах их ответственности. Естественно, за одним исключением: главного по софту.
Ещё важна общая цель. Грубо говоря, мотивация. Джобсу удалось создать iPhone не только потому, что он сам носил прототип в кармане, но и потому, что все сверху до низу на него молились. И выкладывались по полной, наплевав на отдых и здоровье. В свою очередь, менеджмент наверху тоже не мог произвести фигню. Диктатура, особенно религиозная не менее эффективна чем армия.
Так как в подобной конфигурации главный инженер главнее главного менеджера, старая система постепенно вытесняется новым подходом, декларирующим, что процессы важнее людей. Фирмы перестраиваются, сертифицируются, оцениваются по уровням зрелости процессов. В результате, общие цели заменяются общими лозунгами, а прямой доступ к информации красивой документацией. Не трудно догадаться, что в случае проблем виновных в такой системе не найти. Так грубейшие ошибки в разводке кабелей на A380 списали на различия в версиях софта для проектирования.
В довершение хочу отметить, что достаточно нанять сотню индусов, чтобы любой, даже самый маленький проект превратить в огромный муравейник со сложной внутренней жизнью. Именно этим сейчас и занимаются Эффективные Менеджеры™ в крупных компаниях.
Про размеры и взрыв сложности
Первым делом, аналогия. Сначала объясню, почему она правильная, а потом, почему она не работает.
Софтверный проект можно представить как военные действия. Впрочем, любое одноразовое производство чего-то существенного, типа разработки велосипеда или строительства стадиона под это подходят.
Аналогия хороша тем, что показывает критерии успеха. Нужен генерал, который единолично руководит и понимает, какие приказы и зачем отдаёт. Нужен штаб, который собирает информацию и разрабатывает план. Нужна чёткая и однозначная система коммуникации. Нужны инициативные и ответственные командиры на местах, которые и приказ выполнят, и людей при этом не угробят. Нужны смелые и профессиональные солдаты. Дальше можно расширять аналогию на разведку, логистику, подготовку... Всё будет в тему. Не зря менеджеры молятся на трактаты древнекитайских военачальников.
Теперь, почему это всё не более, чем теории.
Отличие от военных действий очень простое: нет риска потери жизни. Нет риска пленения или каких-то моральных терзаний в случае глобального провала. При этом очень часто личная выгода находится в прямом противоречием с общими целями. Особенно, если говорить об уровне среднего менеджмента и всяких технических служб, непосредственно в создании продукта участия не принимающих.
То есть, наша программистская армия сверху до низу состоит из потенциальных дезертиров-коллаборационистов с крупными вкраплениями предателей-мародёров.
Конечно, маленькая фирма из десятка человек очень сильно может зависеть от технических результатов. Практически также, как и от коммерческих талантов руководства. Но сравнивать её всё-таки лучше не с крутой разведгруппой, заброшенной в тыл врага, а с шайкой разбойников, вышедших на большую дорогу. (Особенно хорошо такая модель подходит для стартапов. Тут и роль инвесторов прописывается совершенно однозначно.)
Первым же результатом такого положения вещей оказывается то, что система передачи информации перестаёт работать. Главная причина в том, что отправители хотят спрятать или приукрасить реальное положение вещей. Также играет роль то, что что люди хотят сделать себе жизнь проще. Общий результат никого не волнует, и отправителям становится наплевать на получателей. Главное прокукарекать, как приказано, а поймёт ли кто - это уже не их забота.
Под информацией надо понимать всё: и приказы начальства, и отчёты, и просто технические подробности, и исходный код, и комментарии, и сообщения об ошибках.
Наша потенциальная армия превращается в муравейник. То-есть, общая цель и разделение труда ещё существует, но работа идёт на инстинктах. Десяток муравьёв хватаются за одно задание и тянут на себя. Кто сильнее, перетягивает и тащит добычу в муравейник, преодолевая сопротивление коллег с другого конца гусеницы. Кто-то кого-то по ходу дела кусает. Или просто одна группа устраивает потасовку с другой. Над всем этим сидит менеджмент, смотрит сверху на происходящее безобразие, каркает и срёт.
Проекты размером с муравейник встречаются достаточно часто. Сюда можно отнести создание каких-нибудь уникальных сооружений вроде завода, поезда или самолёта. Также к этому относятся критические вещи вроде устройств с тиражом пару миллионов штук. Ещё можно упомянуть софт масштабов операционной системы.
Большие проекты состоят из сотен и тысяч программистов или инженеров. Комната на сорок человек может быть занята одними тестерами, или отдел в двадцать душ будет заниматься только писанием бумажек для поддержки какого-нибудь SPICE.
Естественно, абсолютно разумно разбивать работы на мелкие части с хорошо прописанными интерфейсами и поручать их разным людям и отделам. Но информация по системе идёт так хреново, а генералы и штаб витают в таких недосягаемых высотах, что главная общая цель становится не существенной, и народ начинает работать на то, что видит в пределах краёв своей тарелки.
При этом, в большинстве случаев нет людей, которые владеют информацией об общем состоянии дел и общем планировании, а всё превращается в «стратегическое распределение ресурсов». Кудесники гарвардской школы эффективного управления вступают в свои права.
Бывает ли наоборот? Да. Даже иногда такое видел, правда не в ИТ. Кодовое слово - Genchi Genbutsu, иначе говоря «спустись с небес и посмотри сам».
Инженеры в производстве подписывают все чертежи, чтобы в случае чего суд знал, кого сажать на скамью подсудимых. Среди подписей есть подпись главного инженера. И это тот человек, который на самом деле знает, что происходит со всем проектом. Не в мельчайших деталях, но на уровне, достаточном для понимания. И главные инженеры систем знают всё, что находится в зонах их ответственности. Естественно, за одним исключением: главного по софту.
Ещё важна общая цель. Грубо говоря, мотивация. Джобсу удалось создать iPhone не только потому, что он сам носил прототип в кармане, но и потому, что все сверху до низу на него молились. И выкладывались по полной, наплевав на отдых и здоровье. В свою очередь, менеджмент наверху тоже не мог произвести фигню. Диктатура, особенно религиозная не менее эффективна чем армия.
Так как в подобной конфигурации главный инженер главнее главного менеджера, старая система постепенно вытесняется новым подходом, декларирующим, что процессы важнее людей. Фирмы перестраиваются, сертифицируются, оцениваются по уровням зрелости процессов. В результате, общие цели заменяются общими лозунгами, а прямой доступ к информации красивой документацией. Не трудно догадаться, что в случае проблем виновных в такой системе не найти. Так грубейшие ошибки в разводке кабелей на A380 списали на различия в версиях софта для проектирования.
В довершение хочу отметить, что достаточно нанять сотню индусов, чтобы любой, даже самый маленький проект превратить в огромный муравейник со сложной внутренней жизнью. Именно этим сейчас и занимаются Эффективные Менеджеры™ в крупных компаниях.
no subject
Date: 2013-04-04 04:13 pm (UTC)no subject
Date: 2013-04-04 04:32 pm (UTC)no subject
Date: 2013-04-04 04:42 pm (UTC)Там просто классический пример взаимодействия в команде. :))
no subject
Date: 2013-04-05 10:27 am (UTC)Инженер проявил инициативу, и добавил в лимузин габаритные огни от обычного грузовика.
Пришел мэнеджер, отругал его и выбросил, потому что ему пришло в голову и он уже заказал у субконтракторов со светодиодами. :)
Вот и что в такой патовой ситуации делать?
Любой вариант чреват проблемами:
проявил инициативу, сделал сам "как правильно" -- мэнеджер раскритикует и обругает, заставит переделывать по-креативному -- так как он сам только что придумал, потому что ему нужно продемонстрировать важность своих начальственых целеуказаний;
не будеш проявлять инициативу, подождеш пока начальство соизволит -- будеш обруган и раскритикован, а то и уволен как "тунеядец";
попробуеш сам сделать по-креативному -- будеш опять же пойман за этим делом, обруган и раскритикован за разбазаривание средств и попадеш в список неблагонадежных.
no subject
Date: 2013-04-05 10:46 am (UTC)Менеджмент не должен указывать инженерам как решать технические задачи.
no subject
Date: 2013-04-05 10:55 am (UTC)no subject
Date: 2013-04-04 04:37 pm (UTC)no subject
Date: 2013-04-04 04:39 pm (UTC)no subject
Date: 2013-04-04 04:50 pm (UTC)no subject
Date: 2013-04-04 09:53 pm (UTC)no subject
Date: 2013-04-04 10:30 pm (UTC)no subject
Date: 2013-04-04 10:32 pm (UTC)no subject
Date: 2013-04-04 11:10 pm (UTC)Первым делом, софтверная индустрия живёт по законам социализма. То, есть паразитирует на притоке внешних ресурсов. Прежде, чем с ней что-то случится, она должна полностью обескровить реальный сектор экономики.
Вторым, с уходом производства в Азию и ростом производительности труда людей приходится чем-то занимать. Как можно большее количество и трудом как можно менее эффективным. Софтопроизводство - наиболее подходящее для этого занятие, меньше всего нагружающее окружающую среду.
no subject
Date: 2013-04-05 12:09 pm (UTC)no subject
Date: 2013-04-05 01:47 pm (UTC)no subject
Date: 2013-04-05 03:07 pm (UTC)заодно и на улицах поспокойнее будет
no subject
Date: 2013-04-05 03:11 pm (UTC)no subject
Date: 2013-04-05 03:23 pm (UTC)no subject
Date: 2013-04-10 06:31 pm (UTC)То тут главное слово "зависимость". То есть, почти как наркотики, что не очень сочетается с "добровольно".
no subject
Date: 2013-04-11 01:56 pm (UTC)ИМХО, это из разряда диагнозов "вялотекущая шизофрения" ...
PS: да, и еще - употребляя какую наркоту можно зарабатывать деньги ?
no subject
Date: 2013-04-11 02:32 pm (UTC)no subject
Date: 2013-04-05 02:29 pm (UTC)no subject
Date: 2013-04-05 02:47 pm (UTC)no subject
Date: 2013-04-05 02:51 pm (UTC)no subject
Date: 2013-04-10 03:42 pm (UTC)http://www.crashdev.com/2008/01/pirate-ship-as-organizational-model.html
Где-то еще было сравнение с мафией, но не нашел
no subject
Date: 2013-04-10 06:32 pm (UTC)no subject
Date: 2013-04-11 03:31 am (UTC)no subject
Date: 2013-04-11 04:59 am (UTC)