Михайлова Е.А.
Здравый смысл, производственный опыт и научные исследования подсказывают, что при решении сложных задач небольшие группы талантливых людей предпочтительнее, чем большие коллективы. К примеру, для быстрой разработки новых рыночных продуктов наиболее эффективны маленькие коллективы численностью не более десяти человек. Одной из причин этого феномена является общепризнанный факт: в малых рабочих группах упрощены процессы коммуникации и согласования идей между ее членами.
Основной критерий, лежащий в основе определения оптимального размера каждой конкретной рабочей группы, – индивидуальная производительность труда ее членов. Например, при разработке программного обеспечения производительность труда наиболее талантливых программистов в десять или более раз выше, чем у наименее талантливых членов группы /2/. Это утверждение справедливо для любого вида интеллектуальной деятельности, которую нельзя выполнять по шаблону или стандартизировать. При одинаковом количестве ресурсов производительность труда рабочей группы из десяти талантливых человек будет не меньше, чем у коллектива из ста неталантливых разработчиков. Поэтому, в первом случае будут получены большие прибыли при одновременном упрощении коммуникационных процессов и процедур решения проблем. Вполне вероятно, что рабочая группа из десяти человек достигнет лучших результатов значительно быстрее.
Несмотря на тот факт, что небольшие группы талантливых инженеров значительно эффективнее при разработке новых рыночных продуктов, необходимо принимать во внимание и ограничения, свойственные малым группам и проявляющиеся при работе с трудоемкими проектами или с проектами, имеющими жесткое ограничение по срокам разработки. Маленькие группы даже сверхталантливых инженеров не в состоянии разработать, создать и протестировать сложный продукт с большим количеством компонентов настолько быстро, чтобы иметь конкурентное преимущество по срокам вывода новинки на рынок. Например, в автомобильной промышленности инженерам требуется семь миллионов часов, чтобы разработать один новый продукт. Даже в таких известных своими разработками компаниях, как Toyota, Honda, Chrysler зачастую более тысячи инженеров работают от трех до пяти лет над одной новой моделью автомобиля /1/. Лидеры самолетостроения, такие как Boeing, не раз использовали большие группы профессионалов – несколько тысяч инженеров, - для создания новых гражданских авиалайнеров.
Многие руководители проектов по разработке программного обеспечения, напротив, предпочитают очень маленькие команды разработчиков – десять, двенадцать программистов, - что продолжает культурную традицию, возникшую на заре развития программирования. Корни этой традиции в том, что рабочая группа из двух, трех программистов может самостоятельно создать новый продукт. Первые версии MS DOS, WORD и EXCEL были разработаны в начале 80-х гг. командами программистов из шести - десяти человек и содержали всего несколько десятков тысяч строк текста программы /4/. Однако маленькие производственные группы никогда не использовались при разработке больших систем. Например, в 60-х гг. фирме IBM потребовалась рабочая группа из тысячи программистов, чтобы создать операционную систему System 360 /2/. В 90-х гг., с появлением графических интерфейсов, более требовательных к оперативной памяти, группы разработчиков программного обеспечения даже для персональных компьютеров стали огромными по своей численности в сравнении со стандартами, исторически сложившимися в компьютерном производстве. Первая версия WINDOWS NT, представленная в 1993 году, состояла из 4,5 миллионов строк текста программы /1/. Ее разработкой занималась команда из 450 человек, в состав которой входили программные менеджеры, работающие над спецификацией продукта, менеджеры проекта, разработчики, а также пользователи, осуществляющие тестирование продукции /3/. WINDOWS 95, вышедшая в 1995 году, состояла из 11 миллионов строк текста программы и потребовала такого же количества разработчиков, работавших над ее созданием около трех лет /4/. Команда из трехсот человек разработала основные компоненты браузера Microsoft Internet Explorer, вышедшего в 1996 году. Еще несколько сот человек были вовлечены в создание различных дополнительных возможностей, например, почтовых услуг сети Internet.
Со времен разработки и строительства египетских пирамид и древнейших систем орошения, если не раньше, управляющие разбивали крупномасштабные проекты на отдельные блоки или модули, а работников - на отдельные группы, управлять которыми значительно легче, чем одним большим коллективом. Современные компании, наряду с разделением и автоматизацией труда, возвели процесс разбиения продукта на модули в ранг науки вне зависимости от того, что за продукт производится: программное обеспечение, самолеты или автомобили. Однако идея “разделяй и властвуй” таит в себе проблему: как объединить работу большого числа разработчиков и множество различных рабочих модулей для эффективной совместной работы над созданием конкурентоспособного продукта. В этой связи не менее актуальна и проблема дополнительных потерь времени, возникающих в силу необходимости координации деятельности большого числа небольших групп разработчиков. Появление трудностей, связанных с планированием и координацией, определяет необходимость эффективного управления изменениями, особенно, если в проекте есть ограничения по ресурсам: временным и финансовым.
Сегодня, когда технологии и нужды потребителей развиваются с огромной скоростью, разработчики в процессе создания нового продукта должны непрерывно вносить изменения в свои замыслы, демонстрируя новые свойства продукта потенциальным пользователям и реагируя на их пожелания. Эта тенденция, имеющая место на всех без исключения товарных рынках, наиболее отчетливо прослеживается на рынке программного обеспечения. Разработчики программного обеспечения, пожалуй, больше, чем кто-либо другой, нуждаются в эффективных технологиях разделения продукта и задач на автономные модули с тем, чтобы команды из сотен талантливых программистов могли творчески работать и эффективно взаимодействовать на протяжении всего процесса реализации проекта. Возникла потребность в управленческих технологиях, позволяющих управлять огромными коллективами разработчиков новых продуктов также эффективно, как маленькими рабочими группами.
В этой связи особый интерес представляет подход Microsoft к управлению процессом разработки новых продуктов. Концепция подхода, разработанного Microsoft такова: необходимо позволить как командам, так и отдельным разработчикам работать творчески, за счет обеспечения относительной независимости малых групп, но при этом постоянно координировать и, время от времени, стабилизировать процесс разработки нового продукта /3/. Для реализации этой концепции Microsoft разработала и успешно реализует стратегии, обеспечивающие координацию и стабилизацию процесса разработки нового продукта. Первая стратегия направлена на повышение эффективности процесса разработки нового продукта за счет развития функциональных возможностей рабочих групп и жесткого закрепления ресурсов. Вторая стратегия направлена на постоянную синхронизацию процессов разработки нового продукта.
Впервые этот подход был описан M. Cusumano и R. Selby в книге “Секреты Microsoft” (1995г.) /3/. В основу книги лег материал, собранный авторами в течение двух с половиной лет наблюдений за командами разработчиков новой продукции Microsoft. За это время Michael Cusumano и Richard Selby провели ряд интервью с тридцатью восьмью ведущими сотрудниками Microsoft, просмотрели тысячи страниц конфиденциальной проектной документации и отчетов за последние девять лет, начиная с 1986 года, в которых описывались как победы, так и поражения, а также рождались идеи новых проектов. Титаническая работа, проделанная M. Cusumano и R. Selby, позволила им описать процесс разработки новой продукции, который они назвали “координирующе-стабилизирующим” подходом /3/. Суть его проста: постоянная координация деятельности разработчиков, работающих параллельно над различными свойствами и функциями продукта, и периодическая стабилизация разработанных свойств и функций продукта по мере его развития вместо однократного аналогичного процесса по окончании проекта. Сотрудники Microsoft называют технический прием, позволяющий решить проблему эффективного управления большим количеством команд разработчиков, по-разному: “промежуточный отчет”, “ежедневное формирование”, “ночное формирование”, “ноль-дефектный процесс” /4/. Под “формированием” подразумевается процесс объединения частично завершенных или полностью готовых частей программного обеспечения, который позволяет определить, какие функции продукта не работают или какие существуют проблемы.
В крупномасштабных проектах за каждым разработчиком закреплен свой участок работы, в связи с чем возникает потребность в координации их деятельности. Менеджеры Microsoft попытались структурировать и скоординировать работу как отдельных инженеров, так и целых команд таким образом, чтобы обеспечить разработчикам достаточную гибкость для творческой работы и поэтапного развития частей продукта. Чтобы сократить время на разработку и рыночное тестирование продукта, а также произвести его с наилучшими характеристиками, разработчики проводят промежуточное тестирование продукта еще в ходе процесса его разработки.
В последние годы подобная технология управления процессом разработки новых рыночных продуктов получила широкое распространение в целом ряде отраслей. Сегодня многие компании в процессе работы над опытным образцом одновременно осуществляют циклы разработки, создания и рыночного тестирования продукта, что дает возможность полностью контролировать процесс разработки нового продукта.
С середины 70-х гг. исследователи, разработчики и менеджеры по управлению новыми продуктами, отмечают спиралевидный характер модели процесса разработки нового рыночного продукта, особо обращая внимание на спиралевидное повторение фаз проекта и одновременное развитие множественных разновидностей процессов /5/. Как теоретики, так и практики медлили с официальным признанием выявленных закономерностей. Но все же основная идея распространилась чрезвычайно быстро. Она заключается в том, что потребности потребителей в разного рода новых продуктах порой очень трудно определить, а изменения в технологиях, приоритетах потребителей и прочих элементах рыночной среды происходят так быстро, что неразумно пытаться разработать моновариант нового рыночного продукта, заранее будучи уверенным в его успехе у потребителей. Вместо этого, продвигаясь к завершению продукта, проекты должны развиваться так, чтобы обеспечивать одновременную поддержку нескольких конструктивных, сформированных и отлаженных версий нового продукта.
Альтернативой рассмотренному подходу, который практики называют “параллельным инжинирингом”, является гораздо более последовательная концепция управления процессом разработки нового продукта, в основе которой лежит метод “водопада” /4/. При этом методе осуществляется попытка “заморозить” особенности продукта, изобрести идею, разработать необходимые компоненты, а затем, в конце проекта, объединить их в одной фазе, включающей и рыночное тестирование продукта (рис.1) /4, с.11/. Метод “водопада”, впервые заявивший о себе в начале 80-х гг. и до недавнего времени остававшийся основной моделью проектного планирования в большинстве отраслей, сегодня теряет свою привлекательность. И, прежде всего, это связано с тем, что компаниям удается создать свои лучшие продукты только в том случае, если они могут легко изменять их спецификации и отдельные элементы, быстро осуществлять обратную связь с покупателями и проверять новые составляющие непосредственно в процессе разработки продукта.
Не случайно, в последнее десятилетие ХХ века все больше компаний в мире, включая и Microsoft, при разработке нового рыночного продукта следуют технологии, предполагающей следующую схему: зарождение идеи - создание компонентов – рыночное тестирование новинки, и при этом предпочитают как можно чаще в процессе создания продукта общаться с потребителями. На суд потребителей представляются предварительные версии продуктов, к которым последовательно добавляют новые функциональные свойства и возможности. Эта концепция особенно полезна при разработке новых продуктов в минимально короткие сроки в условиях высококонкурентной, быстро меняющиейся рыночной среды.
Microsoft впервые применила технику координирующе-стабилизирующего подхода в конце 80-х гг. для создания EXCEL и WORD /3/. Этот подход, великолепно зарекомендовав себя, стал использоваться при разработке любых прикладных программ, работа над которыми требовала многочисленных контактов с пользователями в ходе реализации проекта. В частности, операционные системы WINDOWS NT и WINDOWS 95 были разработаны с использованием этого подхода. Неудивительно, что такие компании, как Netscape и Yahoo, используют аналогичную технологию, основанную на разработке большого числа версий продукта и многочисленных их проверках совместно с потенциальными пользователями, хотя и со значительно меньшими продуктами и командами разработчиков, чем в Microsoft, и с менее точно определенным процессом развития продукта.
Не меньший практический интерес представляют и стратегии, используемые Microsoft при разработке новых продуктов. Чтобы определить продукт и организовать процесс его разработки, Microsoft использует стратегию концентрации на творческой деятельности, основанную на жестком закреплении ресурсов /3/. Для любой компании важно, чтобы разработкой новых рыночных продуктов занимались творческие люди. Однако еще более важно направлять их творчество. В Microsoft этого добиваются, предлагая разработчикам подумать о том, за какие технические характеристики продукта потребители готовы платить деньги, а также оказывая давление на развитие проекта посредством ограничения таких ресурсов, как время и высококвалифицированный персонал. В противном случае разработчики рискуют создать никому не нужный продукт. Связанный с этим риск поистине велик и перерастает в проблему, во-первых, для быстро развивающихся отраслей, в которых разработчики не имеют точной информации о требованиях потребителей к разрабатываемому продукту и поэтому вынуждены в процессе осуществления проекта часто изменять взаимосвязанные компоненты продукта, и, во-вторых, в случае недостаточной синхронизации работ отдельных команд разработчиков нового продукта.
Работа над новым продуктовым проектом в Microsoft начинается с составления “Описания продукта”, объемом в несколько страниц, где определяются цели нового продукта и виды деятельности пользователей, расположенные в соответствии с приоритетами, которые должны поддерживаться техническими характеристиками нового продукта (рис.2) /4, с.13/. Руководят выполнением этого этапа менеджеры по продукту, непрерывно координирующие свою работу с программными менеджерами, разрабатывающими подробное описание функциональных характеристик нового продукта. Затем программные менеджеры, проконсультировавшись с разработчиками, составляют функциональную спецификацию, которая очерчивает технические характеристики продукта достаточно глубоко для того, чтобы разработать план и обеспечить проект кадрами. В то же время спецификации не определяют всех тонкостей каждой технической характеристики и не ограничивают проект рамками первоначально оговоренных функциональных возможностей. Опыт Microsoft свидетельствует о том, что в спецификации технические характеристики нового продукта описаны в среднем лишь на 30 процентов /3/.
На следующем этапе менеджеры проекта разбивают как продукт, так и процесс его разработки на части и формируют команды разработчиков основных и вспомогательных технических характеристик продукта (рис.2). В свою очередь, сам продуктовый проект также разбивается на три или четыре подпроекта - последовательных этапа, которые представляют собой законченные узлы основных частей продукта (рис.3) /4, с.14/. Каждая из команд разработчиков, занятых в проекте, осуществляет полный цикл проектных работ, включающий разработку, интеграцию, проверку технических характеристик и, в случае необходимости, выявление и устрание недостатков. Более того, на протяжении всего проекта работа команд разработчиков ежедневно и еженедельно синхронизируется как при формировании продукта, так и при поиске и исправлении ошибок. В процессе развития продукта, а точнее, в конце каждого этапа разработчики исправляют практически все ошибки, выявленные ими, проверяющими и первыми пользователями продукта. Исправление ошибок стабилизирует продукт и позволяет команде точно определить, какая часть продукта готова полностью. Затем команда разработчиков переходит на следующий этап, работа на котором проходит по той же схеме.
Microsoft на каждом этапе реализации продуктового проекта устанавливает приоритеты технических характеристик, в результате чего сначала создаются наиболее важные компоненты продукта. Не менее интересен тот факт, что на каждом этапе предусматривается дополнительное, резервное время, необходимое для экстренного решения проблем, возникающих в ходе реализации проекта. В связи с этим еще раз необходимо подчеркнуть - разработчики, приступая к созданию нового продукта, имеют лишь краткое описание его основных характеристик. Не существует полной, законченной спецификации и детально разработанного дизайна продукта, поскольку заранее невозможно определить все характеристики, которыми должен обладать новый продукт.
Стратегия концентрации на творческой деятельности предоставляет разработчикам и программным менеджерам Microsoft возможность на всех этапах процесса разработки продукта осуществлять нововведения и приспосабливать разрабатываемый продукт к изменениям рыночной среды или непредвиденным угрозам со стороны конкурентов.
Команды разработчиков после детального анализа поставленных перед ними задач, что занимает от одного до трех дней, самостоятельно разрабатывают календарный план-график работ. После чего менеджеры окончательно определяют необходимые для реализации проекта ресурсы.
Вторую стратегию, используемую Microsoft при разработке новых продуктов, можно сформулировать следующим образом: все действия по разработке нового продукта необходимо проводить параллельно с постоянной координацией работ, что необходимо для эффективного управления процессами разработки и реализации продукции /3/. Цель данной стратегии – жесткий контроль процесса разработки нового продукта, но без попыток контролировать каждую рабочую минуту разработчиков. В последние годы управляющие различных компаний все чаще высказываются за необходимость уменьшения бюрократизации процесса разработки новых продуктов, за необходимость большей готовности к инновациям, за необходимость ускорения реакции компаний на изменения потребностей покупателей посредством реструктурирования как организационной, так и производственной систем, - как мерах ускорения процесса разработки новой продукции. Однако, как уже отмечалось, создание сложных продуктов требует больших команд разработчиков, порой состоящих из сотен человек, координация работы которых сопряжена со значительными трудностями и огромными затратами времени. Во избежание подобных проблем крупномасштабные продуктовые проекты разбивают на этапы, каждый из которых закрепляют за четко определенной функциональной командой разработчиков. При таком подходе каждый этап проекта должен заканчиваться контролем. Однако, во-первых, такой подход к разработке новых продуктов сдерживает инновационные процессы, во-вторых, в нем недооценивается важность постоянной координации работ. Коммуникативные и координационные трудности, возникающие в процессе работы над крупномасштабными проектами, являются результатом того, что в проекте задействовано больше разработчиков и на его реализацию предусмотрено больше времени, по сравнению с проектом, в котором задачи согласованы, а участники проекта делят обязанности и ответственность в небольших, более гибких группах.
При работе над крупными продуктовыми проектами Microsoft старается предоставить как большому количеству небольших команд разработчиков, так и отдельным инженерам достаточно свободы для работы при одновременном выполнении ими функций, присущих участникам большого коллектива. Как результат – создание сложных продуктов, реализация крупномасштабных проектов относительно быстро и без лишних затрат. В Microsoft команды разработчиков строго соблюдают несколько жестких правил, обеспечивающих высокий уровень коммуникационных и координационных процессов /4/.
Первое правило, которому неукоснительно следуют разработчики - внесение изменений в разрабатываемые ими части продукта, осуществляется в строго определенное время, например, в 14 часов. Это позволяет команде собрать готовые компоненты продукта вместе, перекомпилировать продукт, разработать новую форму продукта к концу дня или к следующему утру, а затем немедленно начать проверку и отладку. Второе правило: в случае внесения разработчиками в создаваемый продукт изменений, которые не соответствуют концепции продукта, они должны немедленно исправить этот недостаток. Это правило имеет сходство со знаменитой системой производства продукции компании Toyota, при которой рабочие останавливают всю производственную линию в случае обнаружения дефекта в собираемой машине.
По мере создания новых версий продукта разработчики проводят его тестирование различными группами потенциальных потребителей продукта, включая приглашение пользователей “с улицы” для опробования опытных образцов в лабораторных условиях. Кроме того, практически все команды Microsoft сосредоточены в одном месте, используют общий язык программирования, у них единый стиль программирования и стандартизированные инструменты. Это упрощает коммуникационные процессы и процедуры обсуждения замыслов, а также значительно облегчает решение возникающих проблем без посредников. Проектные команды используют небольшой набор количественных показателей, чтобы проследить, что нового намечается в проекте и принять решение, когда продвигаться вперед внутри проекта или когда выпускать товар на рынок. В частности, менеджеры тщательно отслеживают ежедневный прогресс в разработке нового продукта посредством контроля за тем, сколько новых ошибок обнаружено, какие приняты решения по их устранению, включая удаление дублирующих компонентов или отсрочку с принятием решения, сколько ошибок устранено и сколько еще присутствует.
Координирующе-стабилизирующий подход Microsoft к планированию новых рыночных продуктов преподает ценные уроки того, как управлять большими командами разработчиков и интегрировать работу большого числа инженеров и подразделений внутри рабочих команд. При разработке программного обеспечения процесс интеграции особенно труден, поскольку изменить компоненты просто, но при этом крайне трудно предсказать эффективность других компонентов в процессе отладки и проверки продукта.
Сегодня Microsoft и другие “молодые” компании могут многому научить мир. Они знают, как управлять командами разработчиков из ста человек и осуществлять нововведения в процессе создания сложных крупномасштабных систем. Основные элементы подхода Microsoft к повышению эффективности работ команд-разработчиков и продвижению новых продуктов на массовый рынок представлены в табл. 1 /4, с.15/.
Таблица 1
Основные элементы подхода Microsoft к планированию новых продуктов
четкое определение продукта, ограничения по времени и персоналу
|
модуляризация по техническим характеристикам, функциям, подсистемам и объектам
|
выделение команд и групп, разрабатывающих отдельные технические характеристики, поэтапных подпроектов
|
большое количество малых производственных групп, в высшей степени обладающих независимостью и ответственностью
|
ежедневное формирование продукта, немедленный поиск и исправление ошибок, поэтапная стабилизация
|
разделение ответственности, единое место, общий язык программирования, открытая культура
|
развитие специфических свойств продукта, предусмотрение запасного времени внутри проекта, развитие самого производственного процесса
|
В этой связи не меньший практический интерес представляют управленческие технологии решения проблемы ограничения чрезмерного разрастания проекта, разработанные менеджерами Microsoft /3/. Размеры любого продуктового проекта успешно ограничиваются несложными управленческими действиями. Во-первых, четким определением продукта. Менеджеры проекта устанавливает четкие границы того, что должен попытаться достичь каждый проект. Во-вторых, программные менеджеры, работающие с разработчиками, и менеджеры по продукту, опираясь на данные о потребительской поддержке, составляют описание продукта с указанием стратегических целей проекта. Chris Peters, бывший вице-президент фирмы Microsoft, подчеркивал: “Разработчики должны иметь ясную цель. Только она поможет большой группе разработчиков, группе из ста человек, во-первых, двигаться в одном направлении и, во-вторых, решить, что следует делать, а что нет. Принятие решения о том, чем разрабатываемый продукт не должен стать, столь же важно, как и принятие решения о том, чем он стать должен” /4/. Руководство Microsoft придерживается мнения, что чистоты целей легче добиться во второй, третьей или более поздних версиях продукта, чем при создании абсолютно нового продукта. Кроме того, обычно есть возможность расположить создаваемые свойства по приоритетам.
Третья стратегия Microsoft – ограничение численности персонала, занятого разработкой нового продукта /3/. По-сути, Microsoft состоит из небольших компаний и исследовательских центров, численность персонала которых обычно составляет не более трехсот – четырехсот человек. Это, прежде всего, команды разработчиков продукта, состоящие из профессионалов в области программирования, тестирования продукта, планирования производства, а также специалистов по связям с пользователями /4/. Не так давно общее количество служащих Microsoft исчислялось десятками, а в проектах участвовало по четыре – пять человек. Рабочие группы из трехсот – четырехсот человек представляются маленькими по сравнению с тысячей, а иногда и более, разработчиков, которых Microsoft привлекает для создания программных продуктов сегодня. В настоящее время Microsoft концентрирует внимание всех своих сотрудников на разработке продукции для сегодняшних рынков, а не на создании технологий “на будущее” или потере времени на документировании процессов и продуктов. Концентрация на выпуске нового рыночного продукта имеет как положительные, так и отрицательные моменты. Недостаток технической документации, например, может привести к необходимости заново принимать решения по общим вопросам. С другой стороны, эта стратегия позволяет разработчикам сконцентрироваться только на разработке нового рыночного продукта.
Четвертая стратегия Microsoft - ограничение времени на разработку нового продукта /3/. Установка лимитов времени помогает разработчикам сконцентрироваться на совместном создании рабочей версии продукта. В проекте обязательно предусматривается время на усовершенствование продукта. Как правило, работа над проектом останавливается, если продукт уже “достаточно хорош”, чтобы быть проданным на рынке. В прошлом, работа над некоторыми продуктовыми проектами длились годами. В настоящее время многие продукты выпускают на рынок за месяц или два до запланированной даты.
Возможно, решающую роль в разбиении больших команд разработчиков на маленькие рабочие группы играет архитектура продукта, то есть возможность разделения его на части. Деление продукта на модули оправдано не только при производстве программного обеспечения. Сегодня большинство мировых компаний создают продукт по отдельным свойствам, функциям или подсистемам. Microsoft не всегда уделяла должное внимание созданию высокоуровневой архитектуры продукта. Разработчики впервые серьезно задумались над этой проблемой, приступив к работе над WINDOWS 95 /4/. Менеджеры проекта предприняли успешную попытку координации и синхронизации процесса разработки компонентов продукта посредством, во-первых, ежедневного и еженедельного их объединения, а, во-вторых, поэтапной стабилизации продукта, то есть определения временного момента, в который разработчики должны приостановить работу над созданием новых характеристик и функций продукта и заняться устранением ошибок.
Пятая стратегия – деление продукта на модули по свойствам и функциям /3/. Разработчики Microsoft разбивают создаваемые продукты-приложения на свойства, операционные системы – на функциональные компоненты, или подсистемы. Свойства и подсистемы будущих продуктов создаются отдельно, что дает возможность разбить один сравнительно большой проект на несколько маленьких проектов. Как только разработка отдельных компонентов завершена, они объединяются в единую систему и проверяются на совместимость. Microsoft разбивает проекты на модули в соответствии со структурой продуктов. Это помогает командам разработчиков создавать продукт в логической последовательности и способствует эффективному объединению людей в команды разработчиков. В свою очередь, команды разработчиков создаются в соответствии с техническими характеристиками и компонентами продукта. Над проектом работают как команды, занятые разработкой технических характеристик продукта, так и команды, разрабатывающие его отдельные компоненты. И те, и другие сосредоточены на создании одного или нескольких свойств или функций, образующих продукт. Структура проекта, таким образом, отражает структуру продукта, а сохранение небольшого числа и численности команд приводит к созданию более тесно интегрированного продукта.
Шестая стратегия Microsoft - разделение проекта на этапы или подпроекты /3/. Команды, созданные в соответствии с техническими характеристиками и компонентами продукта, осуществляют полный цикл разработки нового продукта от зарождения идеи до проверки и стабилизации готового продукта. В результате менеджерам не приходится контролировать проекты, которые заключаются, например, в одновременном формировании огромного числа технических характеристик и продолжаются от полутора до двух лет. Вместо этого менеджеры проекта ставят целью создание только нескольких характеристик за два – три месяца.
Поэтапный подход к разработке новых продуктов требует больше времени, чем одновременное создание всех компонентов будущего продукта и последующее их объединение, а также однократная проверка в конце проекта. На практике отдельные компоненты программного обеспечения претерпевают значительные изменения в ходе реализации проекта, в связи с чем их трудно точно определить заранее. Влияние изменений затрудняет процедуру последующего объединения компонентов в случае отсутствия жесткого контроля за работой как команд разработчиков, так и отдельных инженеров. Поэтапный подход позволяет и маленьким, и большим командам действовать гибко и, в случае необходимости, беспрепятственно вносить изменения в замыслы, как если бы они действовали в одиночку. Подобная свобода обеспечивается, во-первых, ежедневной синхронизацией действий разработчиков и, во-вторых, многократной стабилизацией основных частей продукта в ходе реализации проекта, пока не накопилось столько изменений, что объединить и стабилизировать продукт окажется невозможным.
В заключении, еще раз остановимся на основных моментах подхода Microsoft к планированию новых продуктов. Концепции и стратегии, технические приемы и правила, используемые Microsoft и достаточно подробно описанные M. Cusumano и R. Selby в книге “Секреты Microsoft” (1995г.) /3/, применимы не только при разработке программного обеспечения. Они отражают основные принципы, которые должны применяться и в других областях деятельности, особенно в быстро развивающихся производствах. Принципы Microsoft применимы в любой сфере инженерной деятельности, где создаются многократные версии продукта или в ситуациях, когда между членами команды происходит частый электронный обмен спецификациями на продукт или результатами испытаний посредством разделения баз данных или приложений для рабочих. Даже “нетехнические” команды могут использовать эти принципы: японские переводчики “Секретов Microsoft” использовали в своей работе координирующе-стабилизирующий подход /4/. Семь команд переводчиков, каждая из которых работала над одной из семи глав книги, выступающих как этапы проекта, ежедневно и еженедельно связывались по факсу, чтобы стандартизировать японские фразы, выбранные для перевода технических и других нестандартных английских терминов.
Практически в любом производстве есть смысл ограничивать масштаб продуктового проекта по таким параметрам, как время и кадры, поскольку это ограничение заставляет разработчиков концентрировать свои усилия на скорейшей разработке нового рыночного продукта. Не менее важен и поиск путей разделения сложного системного продукта на модули, подсистемы и компоненты. Кроме того, команды разработчиков работают более эффективно, если у них достаточно независимости, чтобы выдвигать новые замыслы или вносить изменения в уже существующие, как это было бы, если бы они работали в одиночку. Но при этом менеджер проекта должен следить за строгим выполнением правил, обязывающих разработчиков взаимодействовать так часто, как это необходимо, с тем, чтобы координировать их работу. Хорошо отлаженный коммуникационный механизм позволяет эффективно координировать работу над новым продуктом, используя при этом минимальное количество бюрократических регуляторов и правил.
Здравый смысл подсказывает, что в быстро развивающихся производствах продуктовый проект должен быть гибким в силу того, что необходимо предусмотреть возможности для развития спецификаций продукта и улучшения процесса производства, а также запасное время для решения непредвиденных проблем. Гибкость продуктового проекта позволит адаптироваться к быстро меняющейся рыночной среде и ориентироваться на пожелания потребителей, полученные в результате обратной связи, осуществляемой в ходе всего процесса разработки продукта.
Комментариев нет:
Отправить комментарий