Сделано

Еще одна любопытная область – скорая помощь. Я смотрел по каналам Discovery и PBS, как небольшие команды врачей и медсестер оказывают пациенту помощь и находят выход из совершенно непостижимых ситуаций. Не удивительно, что именно врачи неотложной помощи изобрели процесс триажа[13], который применяется в разработке ПО для сортировки задач или ошибок в соответствии с приоритетами (подробнее – в главе 15).

В медицинской среде, особенно травматологии, находятся удивительные параллели для командной работы, принятия решений в условиях высокого стресса и результатов проекта, которые влияют на многих людей каждый день (на рисунке 1.1 вы видите краткое сравнение с медициной и другими сферами работы). Как писал Атул Гаванде[14] в своей блестящей книге «Сложности: заметки хирурга о несовершенной науке» (Complications: A Surgeon’s Notes on an Imperfect Science (Picador USA, 2003):

Рис. 1.1. В теории многие дисциплины опираются на схожие процессы. Все они уделяют время планированию, исполнению и совершенствованию. (Однако не стоит обращаться на кухню за медицинской помощью или обедать в отделении реанимации.)

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

Этот принцип, как и многие другие идеи из блестящей книги Гаванде, применим к разработке программного обеспечения. Фред Брукс[15] в своей классической работе по софтверному инжинирингу «Мифический человеко-месяц»[16] проводит схожие сравнения между командами хирургов и программистов. Хотя жизнь редко стоит на кону, когда вы работаете над сайтом или базой данных, можно отметить немало обоснованных параллелей с трудностями, которые подстерегают эти команды абсолютно разных профессионалов.

Задача проектного менеджмента

Управление проектами может быть профессией, должностью, ролью или функцией. В некоторых компаниях есть руководители, которые отслеживают все проекты двухсот сотрудников. В других этой должностью «награждают» линейных младших менеджеров, каждый из которых реализует часть масштабного проекта. В зависимости от структуры организации, ее культуры и целей проекта управлять проектами может любой сотрудник одновременно с выполнением других обязанностей или сотрудник, для которого управление будет основной задачей (Винсент, Клод и Рафаэль – наши постоянные менеджеры проекта).

В этой книге я использую термин менеджер проекта (project manager) применительно ко всем, кто управляет проектом. Под таковым я подразумеваю руководство командой на этапе планирования, выстраивания графика и формулировки требований, а также на этапах проектирования, разработки (коммуникация, принятие решений и стратегия «середины игры») и достижения итогового результата (лидерство, кризис-менеджмент и конечная стратегия).

Если в вашей сфере эти функции не формализованы, под менеджером проекта можно подразумевать «человека, который управляет проектом / руководит общим ходом проекта, даже если это не входит в его основные обязанности». Я встречал разные формы этих функций, распределенных среди всех членов команды, и скажу, что это несущественно. Эта книга не о должностях и формальностях, а о том, как реализовать свои цели и добиться результата. Однако чтобы максимально упростить вам чтение, я остановлюсь на термине менеджер проекта, или МП.

Иногда отсутствие менеджера проекта не бросается в глаза. Программисты и их начальство составляют графики и планы работы (если они есть), а бизнес-аналитик или маркетолог занимается планированием и требованиями. Все остальные функции, которые можно отнести к проект-менеджменту, просто распределяются по членам команды. Возможно, этих людей наняли как раз благодаря их интересам, помимо написания кода. Возможно, они вовсе не против заниматься первичным планированием, UI-дизайном или бизнес-стратегией. В такой рабочей структуре заложена возможность значительной оптимизации. Раз все готовы нести ответственность за результат и равномерно распределять ношу, которую отдельный МП целиком и полностью взвалил бы на свои плечи, то в команде будет на одного сотрудника меньше. Эффективность и простота – всегда хорошо.

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

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

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

Программный и проектный менеджмент в Microsoft

В конце 1980-х годов Microsoft столкнулась с проблемой координации технической работы с задачами маркетинга и бизнеса (некоторые скажут, что это до сих пор остается проблемой для Microsoft и многих других компаний). Мудрый человек по имени Джейб Блюменталь придумал должность, на которой человек одновременно будет выполнять лидерские и организационные функции. Ему предстояло работать над проектом с первого дня планирования и до последнего дня тестирования. Он должен был разбираться в технических вопросах настолько, чтобы завоевать уважение программистов, уметь широко смотреть на продукт, а кроме того с радостью заниматься написанием спецификаций, анализом маркетинговых планов, составлением графиков, управлением командами, стратегическим планированием, триажем ошибок, мотивированием команды и любой другой необходимой работой, которую не выполняет никто иной (по крайней мере, достаточно хорошо). Новая должность в Microsoft получила название программный менеджер. Он обладал значительными полномочиями, хотя не все члены команды находились в его прямом подчинении. (В теории менеджмента это пример матричной организационной структуры[17], которая предполагает двойное подчинение: в зависимости от должности сотрудника и в зависимости от проекта. Так, программист или тестировщик подчиняются двум менеджерам.)

Джейб стал программным менеджером в работе над продуктом под названием Multiplan (позже его переименовали в Microsoft Excel), и успех не заставил себя ждать. Улучшились процессы проектирования и разработки и координация работы команды, и все были счастливы. После многочисленных совещаний и рабочих встреч команды адаптировались к новой роли. Поручив конкретные обязанности линейному эксперту широкого профиля, Microsoft навсегда изменила динамику работы команд разработчиков. Практически все время работы в Microsoft я как раз выступал в роли программного менеджера. Я работал с продуктовыми командами Internet Explorer, MSN и Windows и даже руководил командами программных менеджеров.

13

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

14

Гаванде А. (р. 1965) – американский хирург, журналист, писатель. Широко известен как эксперт в области оптимизации современного здравоохранения. Прим. ред.

15

Фредерик Филлипс Брукс – младший (р. 1931) – американский ученый в области теории вычислительных систем. Управлял разработкой OS/360 в IBM. Награжден премией Тьюринга в 1999 году. Прим. ред.

16

Брукс Ф., Чапел Х. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2010.

17

Резюме матричной организационной структуры и других типов см. Steven A. Silbiger The Ten-Day MBA (William Morrowand Company, 1993) (Силбигер С. МВА за 10 дней. Самое важное из программ ведущих бизнес-школ мира. М.: Альпина Паблишер, 2018), pp. 139–145. Хотя информацию можно найти почти в каждой книге по теории менеджмента.