В течение большей части моей карьеры, с 60-х по 90-е годы, «смертельные» (death march) проекты были, скорее, исключением, чем правилом, однако по мере реализацией на рубеже веков проектов, посвященных решению «проблемы 2000 года», и последующего массового появления систем на базе Internet/Web, практически все стало тяготеть к «маршам смерти».
Сегодня мы слышим много дискуссий по вопросам, какие языки программирования лучше, как эффективнее сочетать процессы быстрой и формальной разработки при выполнении напряженных проектов. Однако есть и еще один компонент — люди, который также требует особого внимания в «смертельных» проектах. Несмотря на то, что некоторые ИТ-менеджеры по-прежнему верят, что новейший язык программирования или модная методология «скорой» (agile) разработки позволит группам, работающим над их проектами, добиться более высокого уровня производительности, и за счет этого закончить проекты существенно быстрее, такая вера почти всегда оказывается безосновательной.
В конце концов, если бы существовали превосходные средства и методологии, их бы уже использовали, а планы и сроки выполнения проектов уже были бы соответствующим образом скорректированы. И даже при существовании совершенно нового языка программирования или методологии, которые, как предполагалось, позволяют добиться сверхъестественных результатов в «смертельном» проекте, имеется серьезный риск того, что группа, выполняющая проект, окажется недостаточно хорошо обучена, чтобы использовать эти решения должным образом. И новые инструменты разработки, и методологии могут не оправдать завышенные ожидания и оптимистичные заявления их производителей, а лишь показать поразительные результаты на тщательно подобранном демонстрационном проекте, однако вовсе не обязательно, что то же самое будет и на вашем проекте.
Итак, «смертельные» проекты, как правило, заканчиваются успехом или неудачей в зависимости от результатов труда людей, которые над ними работают. Если кадровые вопросы должным образом не решаются, «смертельный» проект может создать напряжение, которого специалисты по разработкам просто не выдержат — в худшем случае люди «перегорят» и уйдут. В хорошо управляемом «смертельном» проекте специалисты, ведущие разработку, не только чувствуют себя превосходно, но и, как правило, добровольно становятся участниками другого «смертельного» проекта.
Конечно, первый шаг в разработке успешной кадровой стратегии — выбор нужных людей. Люди «среднего» таланта и энергетики, скорее всего, не добьются успеха, и, возможно даже, не выдержат ритма работы в «смертельном» проекте. Успешными членами группы могут быть мужчины или женщины, специалисты по Java или знатоки Linux, но зачастую у них есть одинаковые важные черты: как правило, это молодые, не обремененные семьей, антисоциальные трудоголики. Они иногда могут сбежать с работы, чтобы посмотреть очередной дурацкий фильм (например, летом 2008-го в Америке наибольшим успехом пользовались «ВАЛЛ-И» и «Железный человек»), но вы не увидите их за пивом в местном баре, и менеджеру проекта не стоит беспокоиться о том, что они уйдут с работы в шесть часов для того, чтобы поужинать с семьей.
Где же можно найти таких людей и как узнать, что именно такие специалисты нужны для вашего «смертельного» проекта? Можно использовать все обычные стратегии набора ИТ-специалистов, но крайне важно рассматривать перспективы членов группы, реализующей «смертельный» проект, в социальном контексте (особенно потому, что многие из таких специалистов оказываются асоциальными!). Возможно, стоит взглянуть на их страницы Facebook или LinkedIn, или посмотреть их блог (если он у них есть). Но я также рекомендую пригласить перспективных кандидатов для «смертельного» проекта в офис для того, чтобы они встретились с менеджером проекта и другими членами группы. Эффективный способ сделать это — «прослушивание», при котором потенциальные члены группы реализации «смертельного» проекта делают короткую техническую презентацию перед аудиторией, состоящей из других технических членов группы, менеджера проекта и, возможно, нескольких нетехнических специалистов, например, кого-нибудь из финансового отдела или отдела продаж. Такая презентация не только позволяет убедиться в технических навыках кандидата, но и также (что намного важнее!) дает шанс оценить его энергичность, энтузиазм, чувство юмора, способность взаимодействовать и налаживать отношения с другими членами группы.
Возможно, самое важное, когда вы приглашаете и проводите интервью с перспективными кандидатами, — это откровенно и честно рассказать о том, что реально потребуется. Десять лет назад менеджеры проекта могли бы высказать сожаление по поводу интенсивного давления, связанного с такими проектами, или просто не заострять внимание на том, что сроки его реализации крайне жесткие, но в современных условиях следует признать, что давление со стороны конкурентов неизбежно превращает любой проект в какой-то степени в «смертельный». Это не означает, что каждый ИТ-специалист посчитает это желательным или даже приемлемым — существует множество причин, почему кто-то может отказаться от такого проекта, и самая очевидная из них состоит в желании проводить время с семьей вне офиса. Если кто-то не имеет возможности или не хочет выносить все тяготы «смертельного» проекта, лучше выяснить это с самого начала, чем потом оказаться в тупиковой ситуации посередине проекта. Действительно, правдивое объяснение кандидату, что данный проект относится к категории «смертельных», может отпугнуть всех, кроме тех людей, о которых я упоминал чуть раньше: молодых, энергичных, не имеющих семьи, асоциальных технарей-трудоголиков. (С другой стороны, не следует автоматически отвергать всех, кому за 30; многие из «зрелых» ИТ-профессионалов тоже с большим энтузиазмом относятся к своей работе!).
Конечно, все это предполагает, что менеджер проекта имеет право набирать в свою команду людей, которых он хочет, и право отвергать кандидатов, которые, по его мнению, не имеют достаточной квалификации или не подходят по другим причинам. Но многие менеджеры проектов говорили мне, что у них нет такой власти: специалисты из «пула» ИТ-сотрудников в компании произвольно назначаются на «смертельный» проект по прихоти старших менеджеров или отдела кадров. Если вы как менеджер проекта оказались в такой ситуации, то мой совет очень прост: увольняйтесь. Уходите сейчас, в самом начале проекта, до того, как ситуация станет еще хуже. Очень рискованно для карьеры отвечать за проект, шансы которого на успех весьма сомнительны, даже если в группе работают очень квалифицированные специалисты. Это самоубийство — отвечать за «смертельный» проект, когда вы знаете, что люди, которых вам навязали, просто для этого не подходят. Это плохо не только для вашей карьеры, но и для тех горемык, которые оказались в группе.
Предположим, что вы сможете набрать для своего «смертельного» проекта нужных людей, тогда еще один совет: даже самый энергичный трудоголик имеет предел выносливости, поэтому так важно для менеджера проекта гарантировать, что «смертельный» проект продлится не больше шести месяцев. Есть и исключения: американский проект Apollo, который NASA вела в 60-х и 70-х годах, несколько проектов по разработке корпорации Microsoft (в том числе недавний проект Windows Vista) и другие, продолжавшиеся более двух или трех лет, если не дольше. Но упомянутые организации могут позволить себе привлечь к работе суперзвезд с уровнем выносливости, намного превышающим тот, какой имеют специалисты, находящиеся в распоряжении средней организации. Простые смертные, как правило, начинают перегорать после шести месяцев непрерывных 80-часовых рабочих недель, а если запланировано, что проект при таких темпах продолжается 12, 18 или 24 месяца, то риск неудачи резко возрастает. Даже в приемлемый полугодовой период одна из важнейших повседневных задач менеджера проекта состоит в том, чтобы наблюдать за членами группы, которые демонстрируют признаки усталости; и прежде, чем производительность работы такого сотрудника станет отрицательной (например, он добавляет две новых ошибки, исправляя одну), лучше отослать его домой на все выходные для того, чтобы он отдохнул и восстановил силы.
Каждая организация разрабатывает свои собственные стратегии для оптимизации кадрового компонента проекта, но этого не произойдет до тех пор, пока организация не осознает, что успех проекта в значительной степени зависит от отдельных членов группы, предпринимающих экстраординарные усилия. Как следствие, некоторые организации в общем бюджете проекта предусматривают определенный «моральный бюджет» — пицца и пиво для проектной группы в пятницу вечером или бутылка шампанского, посланная для того, чтобы смягчить раздраженного мужа или жену, который не видит свою вторую половину по несколько недель, и такой расход не вызовет скандала с сотрудниками бухгалтерии.
По моему мнению, одна из важнейших составляющих хорошей кадровой стратегии состоит в том, чтобы предоставить членам команды адекватные условия работы. Если менеджер проекта не может себе позволить выделить каждому члену группы большой отдельный кабинет с дверью, которую можно закрыть и, таким образом, как-то уединиться, то просто бессмысленно ожидать, что люди будут продуктивно работать, сидя в шумных, переполненных, не имеющих окон «камерах» с неудобными стульями и сломанными столами. Многочисленные исследования за последние 20 лет подтвердили, что люди значительно более производительно работают, если они могут выполнять интеллектуальные задачи в тихой обстановке, не отвлекаясь. Другие исследования показали, что, если кого-то прерывают на середине интеллектуальной задачи, то, как правило, требуется 15–30 минут для того, чтобы вновь сконцентрироваться на этой задаче и продолжить ее решать.
Конечно, многие менеджеры проектов согласятся, что у них просто нет власти или ресурсов для того, чтобы выступить против «полиции обстановки» (Furniture Police), которая управляет распределением и организацией офисного пространства, подбором столов и стульев для ИТ-специалистов и т.п. Если это так, то вот еще один совет: нарушайте правила. Посоветуйте проектной группе работать с полуночи до 8 утра, когда никого нет в офисе, и когда достаточно тихо для того, чтобы люди могли действительно сделать какую-то работу. Скажите им, что они могут работать дома. Скажите им, чтобы они взяли свои ноутбуки и пошли в библиотеку или кафе по соседству. Возьмите деньги из какой-то другой части бюджета для того, чтобы арендовать пустой склад, где группа могла бы сидеть более свободно и продуктивно работать. Все это, скорее всего, вызовет определенную административную критику и жалобы, но к тому моменту, когда корпоративная бюрократия поймет, что происходит, проект уже может быть завершен!
Многих менеджеры проектов шокирует, когда я им советую «нарушить некоторые правила» либо они спрашивают меня, не шучу ли я. «Мы не можем нарушать правила! — говорят они мне. — Как вы думаете, что произойдет, если мы так сделаем? Нас уволят!» Возможно и так, но есть кое-что, о чем стоит задуматься.
-
Оказаться уволенными, возможно, не так уж и плохо; смотрите мои предыдущие комментарии о том, что делать, если вы не имеет права набрать свою собственную группу для «смертельного» проекта.
-
Я не советую вам убивать людей, грабить банк или нарушать какие-то «серьезные» правила, в результате чего вы могли бы оказаться в тюрьме. Я имею в виду деспотичные, нерациональные бюрократические правила, принятые в компании (например, «Мы не разрешаем своим сотрудникам использовать социальные сети, подобные Facebook!» или «Мы не позволяет людям работать дома — мы не доверяем им!»), которые крайне негативно сказываются на производительности и моральном состоянии.
-
Как я уже упоминал, зачастую «время реакции» корпоративной бюрократии настолько велико, что к тому моменту, когда будет замечено, что вы делаете что-то необычное (например, призываете группу находиться в офисе с полуночи до восьми утра), ваш проект будет уже завершен.
-
Несмотря на то, что высшее руководство редко признает, что эти бюрократические правила нерациональны, они сами обычно достаточно рациональны для того, чтобы не заметить ваших нарушений этих правил, если ваш проект закончится успешно. Сначала нарушайте правила, если вы верите, что это позволит добиться значительных улучшений; а потом уже повинитесь, если вам вообще придется это делать.
Еще одна трудная задача для менеджеров «смертельных» проектов — это найти приемлемое вознаграждение для членов группы, которые помогли добиться успеха. Опционы и крупные бонусы — это очевидное решение, но во многих компаниях их просто нет. Альтернативой может стать месячный отпуск, либо оплаченное компанией обучение (не однодневный семинар, а субсидии на получение MBA). Еще один вариант — долгосрочный «заем» на оплату высококачественного ПК, который сотрудник может использовать для работы дома. Почти всегда можно найти неординарное решение, но опять-таки это требует глубокого понимания того, что без преданных членов группы, уверенных, что к ним будут относиться справедливо, уровень производительности, необходимый для «смертельного» проекта, просто не будет достигнут.
Многие из этих стратегий противоречат традиционным кадровым политикам, особенно в «старомодных» компаниях или в госучреждениях. Если бы у вас было несколько десятилетий для того, чтобы разрешить все конфликты, то, возможно, отдел персонала и кадров, в конечном счете начал как-то менять свою работу. Но, к сожалению, мы не можем позволить себе такую роскошь в современной глобально-конкурентной среде. Реальность такова, что политика в отношении персонала и кадровые стратегии должны меняться быстро и серьезно, если мы хотим добиться успеха в реализации современных, весьма напряженных «смертельных» проектах.
О том, как труд профессионалов в области ПО изменяет мир http://www.osp.ru/os/2003/06/183155
Заметки о российском программировании http://www.osp.ru/os/1997/03/179182
Путешествие Йордона в Россию http://www.osp.ru/os/2008/05/5205720
