Разработка, кухня и скорая помощь

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

Один мой знакомый разработчик уверен, что коль скоро принимает сложные решения – по проектированию, координации процесса, тестированию изменений за несколько часов или даже минут, затем выпуску продукта, – его проектам и обязанностям нет аналога во всей истории Вселенной. Он с гордостью перечислит все, чем овладел: CSS, XHTML, Flash, Ajax и другое – и станет убеждать, что пятьдесят лет назад эти технологии потрясли бы величайшие умы. Уверен, вам тоже доводилось встречать таких людей. Или, возможно, самим казалось, что до вас никто не решал такие сложные задачи.

Я предложил этому разработчику заглянуть «за кулисы» его любимого ресторана в разгар рабочего дня. Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально»^[12]), однако сейчас я подразумеваю продуктивность. Когда люди впервые видят молниеносное управление и координацию работы на профессиональной кухне в разгар рабочего дня, им уже не кажется, что их работа самая сложная на свете. Повара жонглируют горячими сковородками с разными блюдами на разном этапе готовности, носятся между конфорками из одного угла кухни в другой, а официанты при этом вбегают и выбегают, сообщают о новых заказах, изменениях и проблемах.

И все это происходит в небольшом тесном помещении, где температура намного выше 30 градусов, под ярким флуоресцентным светом. И сколько бы заказов они ни готовили каждые несколько секунд, новые поступают примерно с той же скоростью. Иногда заказы возвращаются обратно, или, как в программных проектах, в последнюю минуту клиент вносит поправки (столик 1 не переносит лактозу, на столик 2 нужен соус и т. д.). Наблюдать за большими шумными кухнями – одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.

Шеф-повара и линейные повара – менеджеры кулинарных проектов или, как называет их Бурден, регулировщики движения (кстати, еще одна профессия для вдумчивого изучения). Хотя персонал кухни работает в гораздо меньших масштабах и пользуется гораздо меньшим почетом, чем менеджер команды разработчиков, по ежедневной интенсивности их даже сравнивать нельзя. Если не верите, когда в следующий раз окажетесь в ресторане, спросите официанта, можно ли одним глазком посмотреть на работу кухни. Скорее всего, он откажет, но если все-таки согласится, вы не будете разочарованы. (В некоторых модных ресторанах и барах есть открытая кухня. Если найдете такую, сядьте поближе и понаблюдайте за одним из поваров хотя бы несколько минут. Смотрите, как размещаются заказы, как они отслеживаются, собираются и доставляются. Если на кухне аврал, то вы совершенно по-другому посмотрите на поиск и исправление ошибок в программах.)

Еще одна любопытная область – скорая помощь. Я смотрел по каналам 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 и даже руководил командами программных менеджеров.