The Essense of Management in High-Tech
Если вы представляете себе управление проектами по разработке ПО или оборудования так, как это подается в PMBoK, вам, право, стоит временно об этом забыть, чтобы попробовать вместе со мной увидеть за деревьями лес.
Первое. Планирование и управление - это непродуктивная деятельность. Продуктивная деятельность - это собственно разработка ПО. Управление - это накладные расходы, необходимые для того, чтобы группа людей выполняло целенаправленную деятельность, помогая, а не мешая друг другу.
"План" также не является артефактом, имеющим самостоятельную ценность. План - не более, чем прогноз развития ситуации. "Прогноз" во всех смыслах, и в плане оценки трудозатрат и сроков, и в том числе в том, что в силу разных обстоятельств исполнители могут вашему великолепному плану по факту не последовать.
Потому что план выполняет не менеджер, не станок, а люди. Менеджер сам результата не производит - он производит "управление" для людей, которые производят результат. Люди - не компьютеры, а план - не программа, которую достаточно в них "загрузить" нажатием кнопки. Люди имеют обычно собственное мнение касательно целей, задач, проблем, и способов их решения.
Есть однако группа обстоятельств, которая роднит план с программой. В планах бывают "баги". Планы могут вообще не работать. Планы могут быть неоптимальны. И более того, планы могут служить достижению целей, которые никому не нужны.
Собственно, здесь пролегает граница между defined process (определенный процесс) и emphirical process (эмпирический процесс). Сравнивая описание процесса с программой, план является предполагаемым трейсом ее выполнения. В плане нет условий и циклов, как и в трейсе выполнения - ситуация по факту разляжется вполне определенным образом.
Но. В случае defined процесса у нас есть наперед известная технология, точность соблюдения которой в большой мере обеспечивает нам качество результата. Или, как минимум, известны активности, которые нам придется делать. Например, при строительстве здания по готовому проекту.
А вот в случае emphirical process состав активностей нам наперед не известен. Это "имеет место быть" при любом R&D проекте. Конкретный список активностей обычно тесно связан со способом реализации, или внутренним устройством того артефакта, который мы хотим сделать. Обыкновенно, активности известны наперед, если у нас нет никаких принципиальных проблем, которые нам надо решить по ходу проекта.
Это и отличает большинство проектов по разработке ПО от проекта по доставке презервативов. В начале проекта заранее неизвестна структура результата, часто неполон и противоречив список требований, и обязательно наличествуют некоторые нерешенные принципиальные проблемы, требующие креативного решения, и влияющие на способ достижения цели.
Итак, ключевая специфика наших процессов состоит в наличии проблем, которые надо решить в процессе работы, и в том, что способ их решения существенно влияет на список активностей в проекте. А также в том, что решать эти проблемы будут люди, и никакого типового способа обращаться с этими людми у нас нет.
Я предлагаю сконцентрироваться на основной специфике, которая и является источником сложности, и взглянуть на процесс разработки как на problem solving process, а на планирование -- как на неотъемлемую часть этого же процесса. Со всеми вытекающими отсюда следствиями, а их будет немало. Встретить, так сказать, проблему в лоб, не уходя от нее. Ее все равно не получится обойти сбоку, проигнорировать, или перепрыгнуть. Meet high-tech projects face to face.