Ключевая стратегия фирмы

Ключевая стратегия фирмы Microsoft в области НИОКР состоит в фокусировании усилий на разработке компонентов при “фиксированных” ресурсах. Известно, что продуктивность людей с идеями зависит от четкой направленности их идейного потенциала. Менеджеры Microsoft заставляют разрабатывающий персонал помнить о том, что люди, вкладывая деньги в приобретение продукции, будут иметь ограниченные возможности. Велик и риск ничего не продать на рынке, особенно такой быстроменяющейся отрасли как программное обеспечение.

Microsoft начинает проект с разработки “резюме ситуации” (обычно это документ на нескольких страницах с определениями цели проекта, приоритетов по потребителям и рыночным сегментам).

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

Спецификация, естественно, не полностью определяет все детали проекта. В дальнейшем она трансформируется в результате естественного “обучения” исполнителей в процессе работы. Опыт Microsoft свидетельст­вует о том, что такие изменения затрагивают 30% и более первоначальной спецификации. Далее проект, как уже говорилось, делится на части и в нем выделяются три или четыре подпроекта с ключевыми точками, которые составляют главную часть проекта. Все аспектные части проходят полный цикл разработки, интеграции этих аспектов, тестирования и фиксации в каждой ключевой точке подпроекта.

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

Microsoft также устанавливает приоритеты частей в каждой ключевой точке, чтобы первыми выполнить наиболее важные части проекта.

Устанавливается буферное время (20-50% от полного) в рамках каждого подпроекта для того, чтобы в случае возникновения непредвиденных трудностей или задержек, или дополнительных работ, не срывались основные сроки. Разработчики продукта составляют краткий обзор положения перед кодированием, так как персонал реализует и то, что не было предусмотрено ранее для улучшения продукта. Такой подход оставляет разработчикам благоприятные возможности, но и таит определенные угрозы.

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

Менеджеры обычно позволяют членам команды иметь свои собственные планы, но только после того, как они согласуют это в деталях с остальным пер­соналом. Менеджеры затем “фиксируют” проектные ресурсы по численности команды по каждому проекту. Они также ограничивают проект во времени, особенно в приложениях, таких как Office или мультимедийный продукт.

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

Это заставляет Microsoft делать так, как это делается в малых компаниях и при индивидуальных исполнителях – обеспечивать свободную работу в параллель.

Подход Microsoft к организации маркетинга НИОКР (“синхронизация – стабилизация”) дает ценные уроки в том, как управлять большими командами по проекту и как интегрировать работу многих подкоманд или отдельных лиц.

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

Для поддержания объемов проектов в небольших пределах менеджеры компании пытаются ограничить их размеры и области разными путями:

– четкое, ограниченное продуктовое видение;
– ограничения по персоналу;
– временные ограничения (обычно создание новой версии существующих продуктов занимает от 9 до 24 месяцев);
– использование делимой продуктовой архитектуры;
– использование делимой процессной архитектуры.

В заключение отметим ключевые элементы подхода Microsoft:

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