Управление проектами

индекс
176,60

Сколько программистов нужно, чтобы вкрутить лампочку


Фредерик Брукс, в своей классической книге «Мифический человеко-месяц, или как создаются программные системы», анализирует, как влияет количество участников проекта на общую эффективность работ и сроки выполнения проекта. Собственно, он наглядно показывает, что логика, подходящая для решения школьных задач про землекопов, в реальности не работает.

Принцип Брукса гласит, что с увеличением количества участников проекта средняя продуктивность работы каждого участника падает. Связано это с тем, что нужно все больше времени и усилий для коммуникаций и координации:
  • Приходится выделять для координации отдельных «непроизводительных» участников ― руководителей группы, менеджеров проектов, руководителей направлений и пр.
  • Приходится тратить время на более сложные методы документирования работ.
  • Приходится больше времени тратить на координационные совещания.
  • Приходится больше времени тратить на всевозможные обсуждения при выполнении взаимозависимых задач или частей одной и той же задачи.

Выражаясь математически, с появлением каждого n+1 -ого участника проекта в проектной команде появляется дополнительные n линий коммуникаций, которые будут съедать время.

Брукс своим трудом сделал фундаментальный вклад в развитие методологии управления проектами (и не только IT-проектами ― в консалтинговых проектах ситуация такая же). До этого момента в умах управленцев царил Тейлоризм, и ставка делалась на увеличение общей эффективности за счет узкой специализации исполнителей (по понятным причинам в проектной работе это не действует так здорово, как на сборочном конвейере).

Но Брукс рассматривал почти идеальную ситуацию с рядом допущений. В реальности «ввод в игру» каждого следующего участника вызывает еще ряд эффектов, существование которых стоит учитывать:


1. Увеличивается «среднее время простоя».

Часть задач или этапов работ в любом проекте взаимозависимы, и всегда возникают ситуации, когда нужно дожидаться коллегу, выполняющего свою часть, чтобы взяться за свою. Есть и еще и схожий психологический эффект: довольно часто люди искренне используют аргумент «я не могу начать, пока он не закончит», упуская из виду, что есть и другие, независимые задачи, которые можно выполнять прямо сейчас.

Так или иначе, при увеличении количества участников непропорционально увеличивается и число ситуаций, когда кто-то кого-то ждет. А пока он ждет, он решил поиграть… а раз уж начала играть, то нужно пройти до конца ― не бросать же на половине…

2. Падает индивидуальная вовлеченность, ответственность и общий уровень «сознательности».

Это выражается в изречениях типа «пусть кто-нибудь другой», «мне что, больше всех надо», «я свою часть уже выполнил», «я тут итак больше всех вкалываю».

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

Дэвид Майерс в «Социальной психологии» описывает замечательный эксперимент на эут тему. Сначала 10 испытуемых тянут канат «в индивидуальном зачете», прилагаемое ими усилие замеряется. Потом эти 10 испытуемых тянут один канат все вместе. Среднее прилагаемое ими усилие оказывается меньше на 10–15%, хотя они утверждают, что стараются точно также.

3. Увеличивает время принятия решений.

Исходная информация распределена среди большего количества людей, есть больше идей и мнений, а достигнуть консенсуса становится все сложнее.

Предположим, троим людям чтобы выбрать цвет обоев нужно 18 минут: по 3 минуты ― каждому на аргументацию, по 2 минуты каждому― на прения, контраргументы (по одной минуте на мнение каждого оппонента), минута на размышления, 2 минуты на озвучивание итоговой позиции и подтверждение согласия. Впятером выбор обоев при том же регламенте займет уже 38 минут (не считая того, что кто-то обязательно опаздает минут на 10).

4. Участник с уникальной специализацией увеличивает общую эффективность, но со временем его позитивное влияние ослабевает.

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

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

***
В общем, размер имеет значение )
+68
23 апреля 2009, 12:05
35

комментарии (53)

+2
wolandino #
Не могу не согласиться, особенно с пунктами 1 и3.
Только четкое разделение участков работы с увеличением числа работников позволяет более-менее оставаться на пред. уровне производительности — но это не всегда возможно, а если еще правильнее — почти всегда невозможно.
Автору плюс.

+1
ustrel #
Много – значит плохо. Что тогда хорошо?
+1
wolandino #
Хорошо — в меру.
А вот понять какая-такая мера — это уже задача ответственного за проект.
+1
ustrel #
Отличный ответ. Спасибо!
+1
Snipe #
Спасибо, в принципе по собственному опыту все 4 пункта могу подтвердить.

А советы автор (Фредерик Брукс) дает какие-нибудь по данной теме?
+2
Parxxxomenko #
Ну, типа, советует сильнее стараться )
Какого-то волшебного откровения, которое бы все разом решало, он, ессно, не приводит. Основная ценность его наблюдений в том, чтобы научится идентифицировать и анализировать проблемы, чтобы находить адекватные противовесы для каждого конкретного случая. Причем в каждом конкретном случае эффективны могут быть прямо противоположные меры.

Например, где-то целесообразно привлекать к принятию решений всех участников, а где-то — наоборот, ограничить группу принимающих решения; где-то целесообразно начать проводить общие собрания (дабы культивировать ощущение сопричастности к большому делу), а где-то — прекратить их проводить, дабы не тратить зря время.

Если попытаться выделить что-то более-менее универсальное:
— не раздувать проектную команду,
— глобальные проекты делить на относительно автономные проекты более низкого уровня,
— улучшать методы координации, методологию управления, нотации описания и пр.,
— не оставлять исполнителей без присмотра наедине с безлимитным интернетом )
0
andry #
не надо делать слишком большие команды=)
0
andry #
не надо делать слишком большие команды=)
0
voip #
Поэтому, наверное, наёмные специалисты широко распространены за рубежом. Он придёт — укажет на недостатки и способы их устранения и уйдёт.

Самые умные из коллектива получат опыт и будут работать эффективнее.
+1
ramovsky #
У Тома Демарко об этом тоже много
0
dchertousov #
все это решается грамотным менеджментом проекта.
у нас был проект на 6-7 разработчиков.
2 менеджера отлично справлялись с ситуацией.
0
Auru #
ок, когда в проекте 150 разработчиков, надо 50 менеджеров?
–1
EKCTPEMICT #
тут нужно выделять из девелоперов тим-лидов, а ПМы уже будут с них спрашивать
+2
Auru #
водопад как раз-таки наоборот бюрократизирует процесс, первых три пункта проявляются интенсивнее.
0
GenriX #
позвольте, а какое отношение водопад имеет к орг.структуре?

у каждой команды могут быть свои мелкие задачи — сроком на две недели. Тим-лиды спрашивают с команды каждый день, а ПМы спрашивают с тим-лидов раз две недели.
0
dchertousov #
ниже написано про тимлидов, очень верно. я как-то не могу представить себе команду из 150 девелоперов, в которой все общаются между собой.
а если проект действительно настолько велик, что нуждается в таком большом количестве разработчиков, то без сложной проектной документации, обдуманного (не всегда быстрого) принятия решений и правильного иерархического менеджмента обойтись нельзя.
но в этом случае это скорее будет гарантией того, что на выходе будет именно то, что нужно конечному пользователю, а не то, что стало совместным решением двух разработчиков.
+1
Auru #
Ну, в общем верно. Такие проекты длятся от года, в большинстве случаев в итоге фуфел выходит. Самое удивительное, часто такие продукты потом не используются заказчиком, происходит какой-то непонятный просер гигантского бабла. Либо если используется, из-за кривизны результата на суппорт тратятся гигантские ресурсы. Пока что, я думаю, что проекты должны быть как можно проще и меньше.
+2
dchertousov #
> Пока что, я думаю, что проекты должны быть как можно проще и меньше.

Не могу не согласиться.
0
SquirrelEx #
Да да, наблюдал такое пару раз… Я считаю большие проекты необходимо делить на логически законченные части, которые можно потом собрать воедино. И это всегда можно сделать в проекте на год например. Тогда получается несколько небольших проектов которыми управлять куда проще. Но при таком подходе крайне важно уделить много времени разбиению. Его должны проводить 3-5 опытных специалистов (опять таки согласно выше описанным законам). Жалеть на это времени явно не стоит так как при ошибке на этом этапе можно запросто запороть весь проект.
Ну и к тому же надо более пессимистично относиться к срокам… А то скажут 2 месяца а получается год, а через год никому уже и не нужен этот проект…
НЛО прилетело и опубликовало эту надпись здесь
0
dchertousov #
один из менеджеров работал не фуллтайм, а когда этого требовала ситуация.
0
GenriX #
Оптимальная команда до 7 (включительно) человек. Один менеджер вполне может справиться с такой командой. Согласен, что den1 — это перебор.
0
Auru #
Делать-то что?
0
Greesha #
Если для вас это актуальный вопрос, попробуйте гибкие методологии, вроде SCRUM. Если во взаимодействие вовлечена вся команда (на ежедневных скрам-митингах), то можно избежать очень многих накладок.

А Брукс, насколько я помню, говорил о добавлении новых участников в конце проекта, когда становится ясно, что в сроки не уложиться, и предпринимается безнадёжная попытка ускорить разработку за счёт привлечения новых «ресурсов» (этим нехорошим словом некоторые менеджеры называют разработчиков).
0
Auru #
О, романтизм agile :) для небольших групп специально натренированных человеков подойдет. Но когда человеков больше ста?
0
GenriX #
Надо их разбить на команды по 7 человек и пусть работают. :)
0
Xobb #
Что делать-то?
0
atomicxp #
Делать что-то?
То что делать?
0
easterism #
«Что-то делать» надо обязательно
0
Joka #
брать книгу Чернышевского «Что делать ?» и искать что делать :)
0
imac #
мне видется что 1. вытекает из 2. И потеря вовлеченности и ответственности является очень усугубляющим пунктиком, часто этот человек утягивает половину команды, или больше(
0
tangro #
Прикольно перекликается с недавней статьей о «принципе Питера». Выходит чем больше компания — тем она медленнее, неэфективнее, тем больше в ней некомпетентных людей на неподходящих им должностях и тем меньше все стараются.

Почему же тогда мегакорпорации из десятков тысяч сотрудников зарабатывают миллиарды и банкротятся достаточно редко, а компании «наш супербизнес из 5 человек в подвальном офисе» еле-еле на хлеб себе зарабатывают и вылетают с рынка косяками и целыми стаями?
0
Varnak #
потому, что те кто сидят в подвале, в отличее от корпораций плохо умеют продовать свой труд.
потому, что компание-миллионщики имеют возможность «влить новую кровь» купив стартап с идеей и уже сплоченной, эффективной командой
+1
Parxxxomenko #
А еще мегакорпорации — продукт эволюционного отбора из тысяч стартапаов )
0
Max2D #
Потому что мега-корпорации не бросают все тысячи своих сотрудников на разработку одного продукта. Обычно, у каждой такой компании несколько совершенно независимых разработок, в которых задействованы разные команды.

И еще, они дорожат своим местом и своей зарплатой.
НЛО прилетело и опубликовало эту надпись здесь
0
Setti #
и что делать?
0
aprel_co #
Все песимистично. Мы все умрем)
Как это большие компании типа Oracle еще в силах выпускать качественный продукт.
Судя по этой статье, у них бы программисты состарились, пока выпустили бы хоть что-то)
+1
varagian #
Серебряной пули нет. Он как раз и писал о том, что универсальную методику создать невозможно.
Но, не стоит забывать, что он полагал полноту графа связей между участниками проекта( то есть чисто связей ~n^2, что верно далеко не всегда — например, OpenSource сообщество вообще бы не могло существовать по Бруксу )
Кстати, в подобном направлении написаны неплохие(имхо) труды Эдвардом Йорданом «Путь камикадзе» и Эдом Салливаном «Under Pressure and On Time»
+1
Fortop #
OpenSource сообщество чрезвычайно неэффективно. В нем дублируется все 10тки и 100ни раз.
0
Fortop #
Ах, да, но оно таки существует :) Правда только потому, что это не проект, а страта, как и сообщество любителей суши, собак и т.д.
0
m0sia #
только с одной разницей: сообщество любителей собак или суши не производят ровным счетом ничего. Opensource community скорее стоит сравнивать с сообществами краснодеревщиков или художников.
0
Nullius #
Опоздает через «о».
0
rudnytskiy #
Спасибо большое за очерченные проблемы, мое мнение по пунктам ниже

1. Вы знаете, в крупных проектах составляются Диаграммы Ганта, и поэтому от менеджера зависит, чтобы не было простоев
2. согласен
3. вопрос решается простой дисциплиной и организацией
4. обычно в таких ситуациях такой специалист перекидывается на другие проекты
0
Parxxxomenko #
1. Составление диаграмм Ганта не гарантирует точность планирования.

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

4. Теоретически перебрасывается. Если он или его руководитель осознают, что он действительно стал недозагружен и готовы с этим что-то делать. Если его руководитель готов делиться ресурсом, а не держать его «про запас, на всякий». Если этот другой проект есть. Если условия найма дают свободу для маневра.
0
GenriX #
3. А это смотря какая команда.

Если все уже побратались, то ПМ узнает о принятых решениях по факту, из отчетов, потому что команада уже понимает друг друга с полу слова и способна, в большенстве случаев, решить вопрос без ПМа.

А если ПМ только собрал команду, то никуда отсюда не дется. Все должны делать, что он скажет. Когда уже народ втянется, тогда сами.

С Вашими замечаниями а) и б) согласен на 100%, если команда где-то в серединке своего формирования.
+3
zaartix #
«сколько нужно Центравриан, чтобы вкрутить лампочку?
один, но вкручивать он ее не станет, а будет мечтать о былых временах, когда мог отдать приказ слугам»
(с) Londo Mollari
0
amgorb #
Работать надо не больше, а качественней, причем всем — лажа менеджеров вначале не так заметна, но из-за этого летят сроки. Лажа архитекторов или того, кто отвечает за общую структуру — заметна в завершающих стадиях, и часто это бывает вынужденный конец проекта. Лажи программистов и верстальщиков зато часто видно невооруженным взглядом :)
0
Lux_In_Tenebris #
Занятно…
Предпочитаю работать в одиночку. =)
А если уж и приходится совместно, то только последовательно или с чётким разделением функций.
0
acerv #
Вы так написали, что любой ввод человека в работу — ужас и катастрофа. Но, тем не менее, я не считаю, что это так. Существуют процессы разработки (которых, может, и не было во времена Брукса), которые позволяют оперативно (ну, может с некоторыми временными издержками) ввести человека в команду. Скрам и парное программирование например.
0
Parxxxomenko #
Вы утрировали ключевой тезис статьи, что дало вам возможность абсолютно справедливо отвергнуть его в таком виде )))

Каждый дополнительный человек в проекте — это, действительно, не ужас и катастрофа. Это может быть нужным, полезным и оправданным решением. Но мой жизненный опыт подсказывает мне, что менеджеры чаще делают ошибку «перебор», чем «недобор», пытаясь перестраховаться.

Мораль как бы в том, что избыточный «человеческий ресурс» тоже может являтся источником проблем. И не все менеджеры это осознают.
И как бы при буксовании проекта не всегда нужно вливать туда дополнительных людей: иногда нужно, наоборот, кардинально сократить команду проекта.
0
ur001 #
Хорошая статья. Только заканчивается неожиданно.
Напрашивается аргументация в пользу той или иной методологии разработки учитывающей перечисленные негативные эффекты…
А так можно сделать вывод что лучше каждому разработчику дать по проекту, нежели всей командой работать над несколькими
0
Parxxxomenko #
IМНО локализация проблемы — большая часть ее решения )
Мне не кажется, что есть «правильная» методология, которая оптимально все это решает.

Встречаются правилные управленцы, которые хорошо чувствуют и понимают ситуацию. И часто это выражается в том, что в нужные моменты они игнорируют методологию и поступают как надо. Ведь любая методология — это решение в общем виде. Как статистика: обо всем вообще и ни о ком конкретно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.