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

При целенаправленной классификации усилия сосредоточиваются на решении конкретных задач. Целенаправленная классификация проводится в дополнение к ежедневным классификациям. Это – одно из средств управления проектного уровня, призванное помочь придать проекту новый импульс и повысить ценность диаграмм работ по устранению ошибок и анализа текущих тенденций. Рассмотрим несколько общих причин проведения целенаправленной классификации:

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

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

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

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

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

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

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

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