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

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

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

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

Окончание игры

Заключительный период разработки программного продукта – сложный и утомительный процесс. Джим МакКарти (Jim McCarthy) в книге «Dynamics of Software Development» (Microsoft Press, 1995) ссылается на него как на работу с желеобразной массой. При каждом исправлении ошибки вы как будто бы снова и снова прикасаетесь к большому кубу из желе, после чего некоторое время ожидаете, пока он перестанет трястись. Чем больше вы к нему прикасаетесь, тем больше различных вариаций его сотрясений и тем сложнее наложение колебаний, возникающих от этих сотрясений. Веб-сайт или программный продукт – это, по существу, сложнейший набор взаимосвязанных частей, и при каждом изменении одной из них вы вызываете всевозможные новые волны в его поведении. Но в отличие от желе в программном продукте не так то легко понять, когда закончатся эти сотрясения. Код не обладает прозрачностью. Понять, к чему приведет даже одно небольшое изменение, можно только после проверки качества и тщательного ручного исследования сборки.[99]

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

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

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

 Баланс нуля ошибок. Когда количество активных и санкционированных (военным советом) к исправлению ошибок становится нулевым, говорят, что команда дошла до баланса нуля ошибок (Zero Bug Bounce, ZBB). Балансом это состояние называется потому, что как только обнаружится очередная ошибка, у команды уже не будет «нуля ошибок». Есть несколько симпатичных теорий относительно дистанции, разделяющей ZBB и текущий выпуск продукта, но ни одна из них не проработана в достаточной степени, чтобы попасть на страницы этой книги.