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

Классификация

Классификация

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

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

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

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

 Расстановка приоритетов. После первичной обработки и исследований ошибки могут быть расставлены по приоритетам и отправлены на конвейер в соответствии со степенью их важности.

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

Чуть позже, ближе к концу эндшпиля, когда каждые решения по ошибкам тщательно анализируются, классификация должна быть централизована в масштабе всего проекта и проводиться основной группой руководителей проекта (мы рассмотрим этот вопрос в разделе «Военный совет»). Теперь важно разобраться с двумя основными разновидностями классификации: ежедневной и целенаправленной.

Рис. 15.8. По мере развития эндшпиля классификация все более централизуется

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

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

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

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

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

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

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

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

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

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