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

Коэффициент ответных отказов. Вейнберг (Weinberg) называет темп рецидивов, вызванных исправлением ошибок, коэффициентом ответных отказов (Fault Feedback Ratio, FFR). [97] Если каждая исправленная ошибка вызывает появление двух дополнительных ошибок, коэффициент FFR равен 2,0. Согласно утверждениям Вейнберга, приемлемым коэффициентом является число от 0,1 до 0,3. Если это число больше, значит, качество работы должно быть повышено (и/или снижен темп работы). Многие базы данных ошибок дают возможность связать новые ошибки с уже существующими, позволяя отслеживать показатель FFR. Но я никогда не сталкивался с автоматизацией этого процесса, все строилось на субъективных оценках тех, кто занимался классификацией в масштабе всего проекта. (Учтите, что иногда исправление одной ошибки просто вскрывает существование других ошибок. К FFR это не имеет никакого отношения.)

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

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

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

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

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

Аналитические совещания с участием заказчиков или клиентов

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

Один из важных аспектов экстремального программирования (XP) заключается в содействии участию представителя заказчика в самом процессе разработки программного обеспечения. [98] Этот человек должен использовать ежедневные сборки и развивать отношения с программистами и их руководителями. Тогда вы и ваша команда смогут получать отзывы о существующих проблемах ежедневно или ежечасно, а не еженедельно или ежемесячно. По началу эти отношения могут быть непростыми (см. раздел «Распределение ролей» в главе 9), но затраты всегда окупятся более разумными проектными решениями и удовлетворением заказчиков готовым продуктом.

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

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

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