Книга: Искусство управления IT-проектами

Борьба за живучесть

Борьба за живучесть

Если одновременно возникнет слишком много проблем или однажды произойдет действительно что-то из ряда вон выходящее, то на первый план должна выйти борьба за живучесть. Это значит, что с самого первого шага главным приоритетом будет возвращение проекта в более-менее приемлемое состояние. Представьте, что вы пилот Боинга-747 и у вас пропала тяга всех двигателей. Пока вы не выведете двигатели на рабочий режим, ни что иное для вас не будет иметь ни малейшего значения. Все ваши силы должны быть брошены на решение одной-единственной проблемы, от которой зависит решение всех остальных проблем. Это значит, что вы работаете в режиме борьбы за живучесть.

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

Работая руководителем проекта, вы когда-нибудь все равно попадете в ситуацию, требующую вступить в борьбу за живучесть. Вам некогда будет исследовать альтернативы или разбираться с вариантами. Нечто очень важное окажется у вас в весьма плачевном состоянии и не будет ясного представления о том, как с этим справиться. Чтобы разрешить такую ситуацию, действуйте следующим образом:

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

 Если люди с вами не согласны, найдите общую точку зрения. Этот момент лучше объяснен в следующем разделе. Но если вам кажется, что все присутствующие не согласны с тем, что происходит, или с тем, что нужно делать, наведите порядок и верните дискуссию в исходное состояние. Вернитесь к последней согласованной точке зрения: «Все согласны с тем, что наши задачи – это А, Б и В, и именно в такой последовательности?» Как только вы обретете согласие, пусть по самой простой позиции, снова подведите всех к возникшим проблемам. Ставьте вопросы по одному и не позволяйте дискуссии перескакивать через них, пока не будет найдено решение или для его принятия не будет назначен кто-нибудь отсутствующий на совещании.

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

 Нельзя ли изолировать проблему? Подумайте о корабле, охваченном огнем. Может ли пожар распространиться дальше? Нельзя ли защитить от огня те части корабля, от которых зависит его живучесть? Подумайте, как локализовать проблему и предупредить ее влияние на наиболее критичные части вашего проекта. Возможно, потребуется пожертвовать какими-то менее важными обязательствами или перекинуть часть ресурсов от одной группы к другой. Может, понадобится кратковременная поддержка со стороны специалистов из других областей, чтобы помочь изолировать или сдержать проблему, поскольку обеспечение стабильности проекта того стоит.

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

Оглавление книги