ВУЗ:
Составители:
Рубрика:
161
команды по каждому проекту. Они также ограничивают проект во времени,
особенно в приложениях, таких как Office или мультимедийный продукт.
Microsoft использует вторую стратегию – параллельное выполнение чего-
то с частичной синхронизацией. Целью при этом является дисциплина в
процессе разработки без непрерывного контроля каждый день. Большие
проекты проще в планировании и управлении, если они выполняются четко
определенными функциональными группами, по точным правилам и под
контролем. Этот подход, однако, не способствует инновациям и переоценивает
важность синхронизации. Связь и координация затруднена по функциям и
фазам и это может вызвать задержку осуществления проекта и дополнительную
необходимость в людях.
Это заставляет Microsoft делать так, как это делается в малых компаниях
и при индивидуальных исполнителях – обеспечивать свободную работу в
параллель.
Подход Microsoft к организации маркетинга НИОКР (“синхронизация –
стабилизация”) дает ценные уроки в том, как управлять большими командами
по проекту и как интегрировать работу многих подкоманд или отдельных лиц.
Интеграционный процесс особенно труден в проектировании
программного обеспечения, так как здесь можно легко менять компоненты и
трудно предвидеть последствия этого для других компонентов и процесса
тестирования. Программисты не имеют дела с металлом и производством,
которое длится не один месяц. Это – также проблемы технического и
управленческого образования.
Для поддержания объемов проектов в небольших пределах менеджеры
компании пытаются ограничить их размеры и области разными путями:
– четкое, ограниченное продуктовое видение;
– ограничения по персоналу;
– временные ограничения (обычно создание новой версии существующих
продуктов занимает от 9 до 24 месяцев);
– использование делимой продуктовой архитектуры;
– использование делимой процессной архитектуры.
В заключение отметим ключевые элементы подхода Microsoft:
– размеры проекта и области ограничены (ясное и ограниченное
продуктовое видение, персонала и ограничения времени);
– делимость продуктовой архитектуры (модули, функции, подсистемы и
цели);
– делимость проектной архитектуры (команды по кускам и кластерам,
субпроекты по ключевым точкам);
– структура и управление малыми командами (много малых
мультифункциональных групп с высокой автономией и ответственностью);
– немного твердых правил по координации и синхронизации (деление
проекта по дням, немедленное обнаружение ошибок и их коррекция,
стабилизация по ключевым точкам);
– хорошие коммуникации внутри и между функциями и командами
(широкая ответственность, одно место, обычный язык, открытая культура);
Страницы
- « первая
- ‹ предыдущая
- …
- 159
- 160
- 161
- 162
- 163
- …
- следующая ›
- последняя »
