Стр. 407 - УПРАВЛЕНИЕ ИННОВАЦИОННОЙ ДЕЯТЕЛЬНОСТЬЮ

391

12.

Тестируйте план, как правило, 1/3 времени отводится кодированию,

1/3 – тестированию и ревизии и 1/3 – другим видам действий.

13. Снабжайте каждого члена команды информацией о положении дел в

проектировании. Это создает соответствующий моральный климат, поддержи-

вает сопричастность людей и стимулирует их.

Менеджеры обычно позволяют членам команды иметь свои собственные

планы, но только после того, как они согласуют это в деталях с остальным пер-

соналом. Менеджеры затем «фиксируют» проектные ресурсы по численности

команды по каждому проекту.

Спецификация естественно не полностью определяет все детали проекта.

В дальнейшем она трансформируется в результате естественного «обучения»

исполнителей в процессе работы. Далее проект делится на части и в нем выде-

ляются три или четыре подпроекта с ключевыми точками, которые составляют

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

интеграции этих аспектов, тестирования и фиксации в каждой ключевой точке

подпроекта.

Отдельные части проектной команды синхронизируют свою работу на

основе дневной или недельной временной сетки. В конце выполнения каждой

части проекта (и всего подпроекта) разработчики фиксируют все ошибки, тес-

тируют работу и предоставляют возможность первым пользователям ее оце-

нить. Такая частая коррекция ошибок стабилизирует продукт, позволяет разра-

ботчикам понять, что сделано, а где появились проблемы.

Устанавливается буферное время (20-50% от полного) в рамках каждого

подпроекта для того, чтобы в случае возникновения непредвиденных трудно-

стей, задержек или дополнительных работ не срывались основные сроки. Раз-

работчики продукта составляют краткий обзор положения перед кодированием,

так как персонал реализует и то, что не было предусмотрено ранее для улучше-

ния продукта. В частности, для прикладных продуктов команды разработки

пытаются переходить от частей схемы прямо к особенностям их использования,

что типично для поведения потребителей и это требует тщательного обдумыва-

ния и тестирования с пользователями. Дополнительно проекты наиболее при-

кладного характера имеют модульную структуру, что позволяет командам час-

тично добавлять или комбинировать относительно легко отдельные части.

Вторая стратегия – параллельное выполнение с частичной синхронизаци-

ей. Целью является дисциплина в процессе разработки без непрерывного кон-

троля каждый день. Большие проекты проще в планировании и управлении, ес-

ли они выполняются четко определенными функциональными группами, по

точным правилам и под контролем. Этот подход, однако, не способствует ин-

новациям и переоценивает важность синхронизации. Связь и координация за-

труднена по функциям и фазам и это может вызвать задержку осуществления

проекта и дополнительную необходимость в людях [79].

Интеграционный процесс особенно труден в проектировании программ-

ного обеспечения, так как здесь можно легко менять компоненты и трудно пред-