Стратегический инновационный менеджмент

Страница: 1 ... 106107108109110111112113114115116 ... 179

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

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

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

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

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

– четкое, ограниченное продуктовое видение;

– ограничения по персоналу;

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

– использование делимой продуктовой архитектуры;

– использование делимой процессной архитектуры.

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

– размеры проекта и области ограничены (ясное и ограниченное продуктовое видение, персонала и ограничения времени);

– делимость продуктовой архитектуры (модули, функции, подсистемы и цели);

– делимость проектной архитектуры (команды по кускам и кластерам, субпроекты по ключевым точкам);

– структура и управление малыми командами (много малых мультифункциональных групп с высокой автономией и ответственностью);

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

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

— 111 —
Страница: 1 ... 106107108109110111112113114115116 ... 179