Сделано
Шрифт:
Один мой знакомый разработчик уверен, что коль скоро принимает сложные решения – по проектированию, координации процесса, тестированию изменений за несколько часов или даже минут, затем выпуску продукта, – его проектам и обязанностям нет аналога во всей истории Вселенной. Он с гордостью перечислит все, чем овладел: CSS, XHTML, Flash, Ajax и другое – и станет убеждать, что пятьдесят лет назад эти технологии потрясли бы величайшие умы. Уверен, вам тоже доводилось встречать таких людей. Или, возможно, самим казалось, что до вас никто не решал такие сложные задачи.
Я предложил этому разработчику заглянуть «за кулисы» его любимого ресторана в разгар рабочего дня. Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально» [12] ),
12
Бурден Э. О еде. Строго конфиденциально. Записки из кулинарного подполья. М.: Мидгард Эксмо, 2011.
И все это происходит в небольшом тесном помещении, где температура намного выше 30 градусов, под ярким флуоресцентным светом. И сколько бы заказов они ни готовили каждые несколько секунд, новые поступают примерно с той же скоростью. Иногда заказы возвращаются обратно, или, как в программных проектах, в последнюю минуту клиент вносит поправки (столик 1 не переносит лактозу, на столик 2 нужен соус и т. д.). Наблюдать за большими шумными кухнями – одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.
Шеф-повара и линейные повара – менеджеры кулинарных проектов или, как называет их Бурден, регулировщики движения (кстати, еще одна профессия для вдумчивого изучения). Хотя персонал кухни работает в гораздо меньших масштабах и пользуется гораздо меньшим почетом, чем менеджер команды разработчиков, по ежедневной интенсивности их даже сравнивать нельзя. Если не верите, когда в следующий раз окажетесь в ресторане, спросите официанта, можно ли одним глазком посмотреть на работу кухни. Скорее всего, он откажет, но если все-таки согласится, вы не будете разочарованы. (В некоторых модных ресторанах и барах есть открытая кухня. Если найдете такую, сядьте поближе и понаблюдайте за одним из поваров хотя бы несколько минут. Смотрите, как размещаются заказы, как они отслеживаются, собираются и доставляются. Если на кухне аврал, то вы совершенно по-другому посмотрите на поиск и исправление ошибок в программах.)
Еще одна любопытная область – скорая помощь. Я смотрел по каналам Discovery и PBS, как небольшие команды врачей и медсестер оказывают пациенту помощь и находят выход из совершенно непостижимых ситуаций. Не удивительно, что именно врачи неотложной помощи изобрели процесс триажа [13] , который применяется в разработке ПО для сортировки задач или ошибок в соответствии с приоритетами (подробнее – в главе 15 ).
В медицинской среде, особенно травматологии, находятся удивительные параллели для командной работы, принятия решений в условиях высокого стресса и результатов проекта, которые влияют на многих людей каждый день (на рисунке 1.1 вы видите краткое сравнение с медициной и другими сферами работы). Как писал Атул Гаванде [14] в своей блестящей книге «Сложности: заметки хирурга о несовершенной науке» (Complications: A Surgeon’s Notes on an Imperfect Science (Picador USA, 2003):
13
Триаж (фр. Triage – сортировка) – распределение пострадавших и больных на группы, исходя из нуждаемости в первоочередных и однородных мероприятиях (лечебных, профилактических, эвакуационных) в конкретной обстановке. Прим. ред.
14
Гаванде А. (р. 1965) – американский хирург, журналист, писатель. Широко известен как эксперт в области оптимизации современного здравоохранения. Прим. ред.
Рис. 1.1.
Мы воспринимаем медицину как упорядоченную область знаний и четкую процедуру. Однако это не так. Медицина – наука несовершенная, собрание постоянно меняющихся сведений, непроверенной информации, небезупречных людей – и жизней, которые нужно спасти. Да, наша работа опирается на науку, но, помимо нее, – на привычки, интуицию, а иногда и просто догадки. Между нашими знаниями и стремлениями остается чудовищная пропасть. И эта пропасть усложняет все, что мы делаем.
Этот принцип, как и многие другие идеи из блестящей книги Гаванде, применим к разработке программного обеспечения. Фред Брукс [15] в своей классической работе по софтверному инжинирингу «Мифический человеко-месяц» [16] проводит схожие сравнения между командами хирургов и программистов. Хотя жизнь редко стоит на кону, когда вы работаете над сайтом или базой данных, можно отметить немало обоснованных параллелей с трудностями, которые подстерегают эти команды абсолютно разных профессионалов.
15
Фредерик Филлипс Брукс – младший (р. 1931) – американский ученый в области теории вычислительных систем. Управлял разработкой OS/360 в IBM. Награжден премией Тьюринга в 1999 году. Прим. ред.
16
Брукс Ф., Чапел Х. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2010.
Задача проектного менеджмента
Управление проектами может быть профессией, должностью, ролью или функцией. В некоторых компаниях есть руководители, которые отслеживают все проекты двухсот сотрудников. В других этой должностью «награждают» линейных младших менеджеров, каждый из которых реализует часть масштабного проекта. В зависимости от структуры организации, ее культуры и целей проекта управлять проектами может любой сотрудник одновременно с выполнением других обязанностей или сотрудник, для которого управление будет основной задачей (Винсент, Клод и Рафаэль – наши постоянные менеджеры проекта).
В этой книге я использую термин менеджер проекта (project manager) применительно ко всем, кто управляет проектом. Под таковым я подразумеваю руководство командой на этапе планирования, выстраивания графика и формулировки требований, а также на этапах проектирования, разработки (коммуникация, принятие решений и стратегия «середины игры») и достижения итогового результата (лидерство, кризис-менеджмент и конечная стратегия).
Если в вашей сфере эти функции не формализованы, под менеджером проекта можно подразумевать «человека, который управляет проектом / руководит общим ходом проекта, даже если это не входит в его основные обязанности». Я встречал разные формы этих функций, распределенных среди всех членов команды, и скажу, что это несущественно. Эта книга не о должностях и формальностях, а о том, как реализовать свои цели и добиться результата. Однако чтобы максимально упростить вам чтение, я остановлюсь на термине менеджер проекта, или МП.
Иногда отсутствие менеджера проекта не бросается в глаза. Программисты и их начальство составляют графики и планы работы (если они есть), а бизнес-аналитик или маркетолог занимается планированием и требованиями. Все остальные функции, которые можно отнести к проект-менеджменту, просто распределяются по членам команды. Возможно, этих людей наняли как раз благодаря их интересам, помимо написания кода. Возможно, они вовсе не против заниматься первичным планированием, UI-дизайном или бизнес-стратегией. В такой рабочей структуре заложена возможность значительной оптимизации. Раз все готовы нести ответственность за результат и равномерно распределять ношу, которую отдельный МП целиком и полностью взвалил бы на свои плечи, то в команде будет на одного сотрудника меньше. Эффективность и простота – всегда хорошо.