Искусство управления IT-проектами - Скотт Беркун

Перечень сложных ситуаций

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

 Просчеты в ходе реализации проекта. Неудачи проекта чаще всего связаны с просчетами. Некоторые решения, принятые несколько дней назад, не срабатывают, поэтому что-то на данный момент не ладится. Проблема в том, что график работ остается прежним: чтобы ему соответствовать, нужно что-то делать. Возможная реакция: внесите изменения в требования, скорректируйте рабочий график (пожертвуйте следующей по списку характеристикой, имеющей самый низкий приоритет) или, если понадобится, исследуйте новые варианты. Если вы будете проводить проектные исследования (см. главы 5 и 6), то в вашем распоряжении может оказаться неплохая резервная и заранее понятная альтернатива.

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

 Срыв рабочего графика или нехватка ресурсов. Когда вероятность выполнения намеченного к следующей контрольной дате объема работ падает ниже 75 %, вера в успех теряется. Удачный исход возможен, но маловероятен. Возможная реакция: обратитесь к главам 2 и 14. Там вы найдете описание критериев выхода из подобных ситуаций и их возможную расстановку по приоритетам. Вам нужно либо урезать функциональность и добавить время к рабочему графику, либо проигнорировать всю доступную вашему пониманию логику развития событий, отписать завещание и все-таки попытаться любыми средствами выдержать сроки. Попробуйте прикинуть, нельзя ли каким-то образом изолировать риск срыва рабочего графика и убрать проблемный пункт с критического пути. А нельзя ли его обменять на что-нибудь менее важное из предстоящего этапа работы. Закон Брука (Brook)[66] гласит, что привлечение дополнительной рабочей силы при угрозе срыва сроков может не оправдать ваших ожиданий.

 Низкий уровень качества. Если вы не будете контролировать качество, то не сможете узнать о его снижении. Если вы построили работу по принципу ежедневных заданий или имеете ряд часто отслеживаемых параметров (подсчет ошибок и т. д.), то узнаете об этом практически сразу. Существует множество критериев снижения качества: сложный для последующей модификации программный код, не выполненные в полном объеме требования, низкая производительность или нестабильность работы программы. Причин снижения качества тоже немало: технические (связанные с основными методами разработки), производственные (связанные с контрольными процедурами и инструментальными средствами) или планировочные (связанные с календарным и общим планированием). Возможная реакция: установите для команды критерии высокого качества и ставьте ежедневные цели по их достижению (см. главу 15). Для повышения качества нужно чем-то пожертвовать (функциональностью, временем). Часто бывает, что лучше снизить темп работы до тех пор, пока уровень качества не достигнет нужных высот, и все не узнают, как этого достичь, а затем восстановить прежний темп.

 Смена направления. Руководство или складывающаяся рыночная ситуация может потребовать изменений. Для проекта в этом может и не быть ничего плохого (можно даже рассчитывать на некий прогресс), но и радоваться тут, пожалуй, особо нечему. В смену направления могут вмешаться бюджетные сокращения или новые общие цели. Возможная реакция: нужно выяснить, нельзя ли ограничиться изменениями отдельных компонентов? Выделите те технические условия или их части, которые все еще жизнеспособны, и сохраните их в конвейере разработки (см. главу 14), затем расположите по приоритетам все, что требуется изменить. Убедитесь в том, что вы не попадаете в сферу действия безапелляционного приказа; ведь сказать: «Сделайте X» – не одно и то же, что сказать: «Мы должны увеличить доход на 10 %». Первое является директивой, второе – решаемой проблемой. Добейтесь выяснения сути проблем и вмешайтесь в процесс, предлагая приемлемые для себя решения (см. далее раздел «Разрешение конфликтов и ведение переговоров»).

 Общекомандные или личные проблемы. Бывает, что недовольство одного или нескольких человек негативно отражается на всей команде. Недовольство может быть вызваны кем-то («Я не могу работать с Фрэдом») или чем-то («Я ненавижу наш способ анализа программного кода»). Возможная реакция: сначала поговорите с глазу на глаз со всеми фигурантами. Спросите каждого, что происходит и что можно сделать (вам или ему), чтобы улучшить ситуацию. Устраните проблему и дайте людям возможность найти выход. Ищите не только симптомы, но и причины (см. далее раздел «Разрешение конфликтов и ведение переговоров»).

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

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

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

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