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

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

Механизмы вовлечения в работу

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

На выходе каждого этапа проекта имеется рабочий продукт (work product) — документ, набор тестов или код, проходящий проверку качества, предусматривающую обзор/инспекцию, аудирование или тестирование. В таблице 1 приведена матрица для процедуры инспекции.

В столбцах расположены документы, в строках — список участников, а на пересечении указывается роль, которую выполняет конкретное лицо во время подготовки и проведения инспекции документа. Заглавная буква означает, что данное вовлечение обязательно, что обычно устанавливается на уровне процесса организации, но может быть определено во время адаптации процесса для конкретного проекта. Если же буква прописная, то это напоминание организатору инспекции о возможном привлечении конкретного человека: «И» — должен участвовать в проверке; «О» — должен одобрить готовый документ; «Инф» — должен быть оповещен о проходящей инспекции.

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

Помимо матрицы мы используем «проверочные списки» (checklist), необходимые при передаче рабочего продукта с одного этапа на другой либо в процессе разработки документации или кода. В этих проверочных списках указаны участники, ответственные за их заполнение.

Механизмы в действии

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

Инспекции документов. Таблица 2 иллюстрирует пример вовлечения заинтересованных сторон к инспекциям двух различных документов: проектного плана и процедур системного тестирования.

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

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

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

Поставка продукта. На этапе поставки готового продукта заказчику необходимо разделять два вида поставок, промежуточную и конечную, на которых проходит проверка качества, но глубина проверки в этих случаях будет разной. Очевидно, что для промежуточной поставки проверка будет менее масштабной, а некоторые проверки необходимы только для финальной поставки, — например, проверка пользовательской документации; проверка отчета по тестированию (имеется ввиду полное тестирование); валидация инсталляции продукта; проверка того, что вся проектная документация была доведена до конца. Глубина проверки и уровень ответственности влияют на количество вовлекаемых участников (Табл. 3). Для поставок мы используем процедуру инспекции и соответственно механизм матрицы для вовлечения всех заинтересованных сторон.

Перепланирование. Как бы тщательно и правильно мы ни спланировали проект, зачастую на ход работы могут влиять не зависящие от нас факторы: изменение требований заказчика, возникновение сложностей с аппаратным обеспечением или ПО, необходимым для разработки продукта, нехватка ресурсов и т.д. Данные факторы могут повлиять на даты промежуточных поставок, а иногда и на дату финальной поставки, поэтому важно своевременно реагировать на подобного рода изменения. В таких случаях необходимо произвести перепланирование: минимальное, среднее и полное. Мы создали специальный проверочный список, с помощью которого лидер проекта определяет тип перепланирования. Последовательно выбирая из заданного списка те области проекта, которые необходимо пересмотреть, мы получаем тип перепланирования, подходящий к данной ситуации. Результат вычисляется эмпирической формулой, которая учитывает как приоритеты факторов (областей изменений), так и их суммарное влияние. В примере из таблицы 4, выбирая «Да» напротив изменений в ресурсах команды разработки (именно этот аспект является в данном случае ключевым), мы получаем «Среднее» перепланирование. В то же время, если бы изменения касались только внутренних дат, не влияющих на дату конечной поставки (область 4), то перепланирование было бы «Минимальное». При этом результатом заполнения данного проверочного списка может стать «Полное» перепланирование в трех случаях: если мы выберем «Да» напротив всех областей, кроме первой; если определим изменения только в процессе разработки (область 1); если изменения затронут все области.

Следующим шагом является определение списка участников, которых необходимо привлечь к перепланированию данного типа (кто должен инспектировать изменения, кто ответствен за их одобрение). Здесь мы вновь возвращаемся к матрице, в которой по горизонтали указывается список участников, а по вертикали — виды перепланирования. На пересечении мы получаем «обязательное» или «необязательное» (в случае необходимости) вовлечение. В зависимости от типа перепланирования количество «обязательно» вовлекаемых участников меняется: для полного перепланирования — 7 человек, а для минимального — 3.

***

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

Анна Орлова, Наталья Черкасова (Anna.OrlovaNatalia.Cherkasova@motorola.com) — инженеры по качеству программных продуктов компании Motorola, Санкт-Петербургский центр разработки программных продуктов.

Таблица 2. Матрица инспекции проектного плана и процедур системного тестирования

Таблица 3. Матрица инспекции при поставке продукта

Таблица 4. Проверочный список для определения типа перепланирования