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

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

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

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

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

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