Используйте параллельно работающие компактные команды

с частой синхронизацией усилий.

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

Разбивайте большие проекты на осуществимые части

Фундаментальной стратегией Майкрософт является разбиение больших проектов на многие версионированые выпуски без (или с минимально короткой) отдельной фазы сопровождения.

Извлекайте уроки из пройденных вех

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

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

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

Используйте прототипирование

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

Используйте частые билды и быстрые тесты

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

Частые итерации разработки и внедрения

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

Избегайте расползания рамок проекта

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

Оценка снизу вверх

В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. должны исходить от тех, кто будет затем выполнять оцениваемую работу. Подход “снизу вверх” (bottom‑up estimating) дает следующие преимущества:

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

Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.

Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.