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

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

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

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

Рис. 15.9. Власть военного совета в ходе эндшпиля постепенно усиливается

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

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

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

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

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

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