Рис. 1.1. В теории многие дисциплины опираются на схожие процессы. Все они уделяют время планированию, исполнению и совершенствованию. (Однако не стоит обращаться на кухню за медицинской помощью или обедать в отделении реанимации.)
Мы воспринимаем медицину как упорядоченную область знаний и четкую процедуру. Однако это не так. Медицина – наука несовершенная, собрание постоянно меняющихся сведений, непроверенной информации, небезупречных людей – и жизней, которые нужно спасти. Да, наша работа опирается на науку, но, помимо нее, – на привычки, интуицию, а иногда и просто догадки. Между нашими знаниями и стремлениями остается чудовищная пропасть. И эта пропасть усложняет все, что мы делаем.
Этот принцип, как и многие другие идеи из блестящей книги Гаванде, применим к разработке программного обеспечения. Фред Брукс[15] в своей классической работе по софтверному инжинирингу «Мифический человеко-месяц»[16] проводит схожие сравнения между командами хирургов и программистов. Хотя жизнь редко стоит на кону, когда вы работаете над сайтом или базой данных, можно отметить немало обоснованных параллелей с трудностями, которые подстерегают эти команды абсолютно разных профессионалов.
Задача проектного менеджмента
Управление проектами может быть профессией, должностью, ролью или функцией. В некоторых компаниях есть руководители, которые отслеживают все проекты двухсот сотрудников. В других этой должностью «награждают» линейных младших менеджеров, каждый из которых реализует часть масштабного проекта. В зависимости от структуры организации, ее культуры и целей проекта управлять проектами может любой сотрудник одновременно с выполнением других обязанностей или сотрудник, для которого управление будет основной задачей (Винсент, Клод и Рафаэль – наши постоянные менеджеры проекта).
В этой книге я использую термин менеджер проекта (project manager) применительно ко всем, кто управляет проектом. Под таковым я подразумеваю руководство командой на этапе планирования, выстраивания графика и формулировки требований, а также на этапах проектирования, разработки (коммуникация, принятие решений и стратегия «середины игры») и достижения итогового результата (лидерство, кризис-менеджмент и конечная стратегия).
Если в вашей сфере эти функции не формализованы, под менеджером проекта можно подразумевать «человека, который управляет проектом / руководит общим ходом проекта, даже если это не входит в его основные обязанности». Я встречал разные формы этих функций, распределенных среди всех членов команды, и скажу, что это несущественно. Эта книга не о должностях и формальностях, а о том, как реализовать свои цели и добиться результата. Однако чтобы максимально упростить вам чтение, я остановлюсь на термине менеджер проекта, или МП.
Иногда отсутствие менеджера проекта не бросается в глаза. Программисты и их начальство составляют графики и планы работы (если они есть), а бизнес-аналитик или маркетолог занимается планированием и требованиями. Все остальные функции, которые можно отнести к проект-менеджменту, просто распределяются по членам команды. Возможно, этих людей наняли как раз благодаря их интересам, помимо написания кода. Возможно, они вовсе не против заниматься первичным планированием, UI-дизайном или бизнес-стратегией. В такой рабочей структуре заложена возможность значительной оптимизации. Раз все готовы нести ответственность за результат и равномерно распределять ношу, которую отдельный МП целиком и полностью взвалил бы на свои плечи, то в команде будет на одного сотрудника меньше. Эффективность и простота – всегда хорошо.