Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 89

Угроза мятежа. Это экстремально резкая форма выражения неверия в успех. Такой момент наступает, когда командой уже пройден порог крушения всех надежд, и люди практически не реагируют на любую вновь вскрывшуюся проблему, какой бы мелкой она ни была. Более того, люди больше жалуются на мнимые проблемы (к примеру, «Почему руководство, или тестировщики, или маркетологи продолжают работать в прежнем направлении?»), а не решают проблемы насущные. Если ничего не предпринимается, недовольство могут поддержать старые сотрудники, и начнется мелкий или символический саботаж (например, устранение некоторых ошибок может внезапно усложниться). Кто-то должен прямо выступить против сложившейся ситуации и разрядить обстановку. Нужно публично признать факт кризиса, составить список всех жалоб и открыто заняться рассмотрением некоторых из них.

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

Также важно понять, что у трудных ситуаций часто бывают неявное начало и такое же не вполне очевидное завершение. На вашем столе не загорится никакая красная лампочка, предупреждающая о падении морального духа или о том, что мгновение назад был допущен просчет. Вам самим нужно быть на страже, но даже тогда вам не всегда будет на все 100 % понятно, что именно происходит. Ну, а если возникнет проблема и вы решите на нее прореагировать, то вполне вероятно, что вам удастся лишь смягчить ее или минимизировать ее влияние, поскольку ее полного решения может просто не существовать. А это значит, что, в конечном итоге, вам в течение многих недель или даже месяцев придется справляться с более мелкими проблемами и симптомами, порожденными главной проблемой. (Например, справляться с двумя программистами или тестировщиками, которые никак не могут ужиться вместе. Вы можете помочь им навести мосты, но полностью погасить их конфликт вам не удастся.) Итак, частью вашей реакцией на неблагоприятную ситуацию может стать выделение времени на то, чтобы вывести все хронические или не имеющие решения проблемы на некий терпимый уровень. Чем больше будет проблем, с которыми вы справляетесь таким способом, тем больше времени вам придется посвятить их нейтрализации и борьбе за живучесть.

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

Итак, если вы работаете с руководителями проектов или являетесь их начальником и не имеете возможности для надлежащего обучения, то вам в качестве возможностей для обучения необходимо воспользоваться возникающими сложными ситуациями. Несмотря на все стрессы и неприятности с ними связанные, приобретаемый при этом опыт станет бесценным вкладом в следующий проект, если, конечно, у вас впоследствии найдется время для анализа. Стюарт Брэнд (Stewart Brand) как-то сказал: «Бестолковая суета ведет к наслоению ошибок, а продуманное поведение позволяет на них учиться». [67] Даже при самых крупных неприятностях руководители проектов демонстрируют сдержанную реакцию. И пока ситуация не приобретет для команды по-настоящему фатальный характер, всегда есть возможность извлечь из нее какие-то уроки.

В отношении других сложных ситуаций можно сказать следующее: способов преодоления возможных проблем великое множество. Если вы хотите изучить их расширенный список, то лучший, из всех мне встречавшихся источников находится в главе 3 книги Стива Мак-Коннела (McConnell) «Rapid Development» (Microsoft Press, 1996). Вторым по ценности можно назвать бессистемный каталог http://c2.com/cgi/wiki?AntiPatternsCatalog, который в настоящее время является наиболее интересным и колоритным чтивом, правда, его труднее применить на деле и он не всегда отличается хорошим языком (что не удивительно, поскольку он относится к Вики-системам).

То, что вы берете всю ответственность на себя, еще не означает вашей вины – это означает, что вы будете отвечать за разрешение возникшей ситуации. Многие боятся этого, потому что не хотят отвечать за что-нибудь и подставлять себя под взыскания. Хороший руководитель должен вести себя совсем иначе: в вопросах, касающихся его команды, он должен искать любую возможность, чтобы взять всю ответственность на себя и использовать ее на благо команды и проекта. Если избавление разработчика или тестировщика от опасений попасть под обвинения позволит мне принять лучшее или более быстрое решение, я с удовольствием возьму этот прием на вооружение. А если мой собственный руководитель достаточно профессионально работает, то принятая мною ответственность заслужит его одобрение. Возлагая на себя реальную ответственность за решение проблемы, я сразу же делаю ее менее опасной для проекта (см. далее раздел «Роли и четко определенные полномочия»).

Идею о возложении ответственности можно вывести за область обвинений или неудач и распространить на всю сферу взаимоотношений с людьми. Ларри Константин (Larry Constantine) в книге «Beyond Chaos: The Expert Edge in Managing Software Development» (Addison Wesley, 2001) пишет:

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