Гольдштейн Г.Я. Стратегический инновационный менеджмент (2004) (1142164), страница 30
Текст из файла (страница 30)
Наиболее полно и почти чтос минутной разбивкой во времени осуществляется планирование начальныхчастей проекта, а с большей свободой – последующих. Проект, как правило,разбит на двухнедельные части (модули).2. Каждый модуль проекта превращается в законченную рабочую системуопределенного функционального назначения и сразу же тестируется. Этозначительно выгоднее, чем организовывать большое тестирование в концеэтапа проекта.
В конце каждого модуля предусмотрена его интеграция востальной проект. Имплентатор включает новые блоки программ в системупрограммных блоков проекта и делает ее новую версию для остальнойпроектной команды. На каждом уровне планирования выделяется отдельноевремя для ревизии выполненного пользователем и старшим по должности.3. Объектная технология, которую применяет SIL, хорошо встраивается витеративный характер разработки.4. Быстрое создание прототипов и испытание созданной части проектапользователем помогает разработчикам быстро довести свои идеи допользователя и дает последнему возможность конкретизировать своеотношение к ним.5.
Каждый модуль полностью тестируется перед передачей егорезультатов остальной команде. Для этого используются программыавтоматической проверки, а затем новые коды передаются на вход системы.Так как для этого необходимо не более одного-двух дней, то исполнителисклонны делать это “в рабочем порядке”, не дожидаясь выделенной планомфазы тестирования.
Так как каждый модуль включает оценку валидности егорезультатов в системе, то устраняются многие побочные эффекты новых кодовперед их использованием остальной частью проектной команды.На основании своего опыта SIL сформулировал ряд рекомендаций:1. Когда система слишком сложна для специфицирования, ускорьтесоздание ее прототипа.2. Команды должны выработать стандартные процедуры разработки иописать их в деталях. Это часть того, что способствует формированию команд.3.
Включайте всю команду в организацию процессов разработки, этосоздает чувство сопричастности.4. Если ваш процесс не изменяется, если он не является объектомдискуссии и дебатов, то он не может быть использован. Хороший процесс157органичен, превращается в привычку. Как и любое действие, вы можете егодокументировать.
Лучшее, что вы можете сделать – руководить его развитием,но попытки ускорить это в приказном порядке больше похожи на поощрениевосстания, чем на участие.5. Точно определяйте роль каждого члена команды и делайте так, чтобыкаждая команда имела персонально обозначенную ключевую роль.6. Организуйте эффективные коммуникации в вашем процессе −тренируйте членов команды в командной динамике и эффективной техникесовещаний.7. Разделяйте проекты на малые куски. Выполняйте большое дело путеммалых шагов.8.
Выпускайте письменный отчет в конце каждого этапа, однакоспрессовывайте время, которое вы можете уделить этому. Это поможет понятьвам, что же случилось, и спланировать следующий этап более тщательно.Публикуйте отчет для ваших старших исполнителей и руководства.9. Небольшие изменения лучше, чем их отсутствие. И всегда хорошо,если имеется ряд изменений.10. Желательно, чтобы команда принимала решения консенсусом. Этопозволяет работать вместе для нахождения приемлемых решений передвнесением их в план. Это не всегда легко, но групповой консенсус – помощь всоздании техники.11. Защищайте людей от препятствий и излишнего вмешательстваруководства.12. Обычно тестируйте план.
Как правило, план отводит 1/3 временикодированию, 1/3 – тестированию и ревизии и 1/3 чему-нибудь еще.13. Снабжайте каждого члена команды информацией о положении дел впроектировании. Это создает соответствующий моральный климат,поддерживает сопричастность людей делу и стимулирует их.Распространено мнение, что малые команды талантливых людей лучше всфере НИОКР, чем большие команды средних или даже талантливых людей.Было оценено [44], что при разработке программного обеспечения талантливыепрограммисты в десять и более раз продуктивней наименее талантливых вкоманде. Однако это может оказаться неверным для других типов исследованийи разработок, инжиниринга и прочей интеллектуальной работы. В то же времясуществует и другая истина: малым командам присущи и определенныеограничения, например, при создании очень больших изделий в сжатые сроки.В автомобильной промышленности для разработки нового образца требуетсяоколо семи миллионов инженеро-часов.
В фирмах “Тойота”, “Хонда”,“Крайслер” над одним образцом работают 500-1000 инженеров в течение 3-5лет. В “Боинге” этим заняты несколько тысяч инженеров.Многие менеджеры проектов программного обеспечения предпочитаюточень малые проектные команды из дюжины или менее программистов. Этонаследие культуры ранних лет программирования, когда два или три человекамогли создать новый продукт. Первые версии MS-DOS, Word и Excel в начале80-х годов создавались программными командами из 6–10 человек. Они158включали несколько десятков тысяч программных строк. Но такие малыекоманды даже в 60-е годы не могли быть использованы IBM, когда в ней околотысячи человек создавали операционную систему для 360 компьютеров.
В 1993году первая версия Windows NT включала 4,5 млн программных строк, апроектная команда состояла в пике занятости из 450 человек. В 1995 году пакетWindows 95 состоял из 11 млн программных строк и над ним работалопримерно такое же количество программистов в течение 3 лет. В 1996 годукоманда из 300 человек создала ключевые компоненты Internet Exрlorerbrowser, а на несколько сотен больше работали над устройствами типа Internet–mail [44].Автор работы [44], профессор Слоуновской школы менеджментаМассачусетского технологического института исследовал работу фирмыMicrosoft с 1986 по 1995годы. Основной подход Microsoft к управлениюНИОКР характеризуется лозунгом “Синхронизация и стабилизация”. Выводисследования был концептуально прост. В фирме синхронизуется то, что людиделают индивидуально и как члены команды, работая параллельно над разнымичастями проблемы, периодически стабилизируются разные стороны проекта натекущих выходах процесса еще до его полного окончания.
Термин “выход”относится к акту компиляции или “интегрирования” законченных частейпрограммного обеспечения в процессе разработки. При этом выясняется, какиефункции работают и какие проблемы существуют.В больших проектах большое число членов команды разрабатываютбольшое число отдельных компонентов проекта, которые тесно взаимосвязаны.Проблема начальных этапов разработки состоит в правильной идентификацииэтих частей.
Менеджеры корпорации Microsoft пытаются структурировать икоординировать работу отдельных инженеров и команд таким образом, чтобыпредоставить исполнителям определенную гибкость в работе и развернутьпараллельную разработку деталей проекта на этих этапах. Для обеспеченияэкономии времени и качества разработки требуется тестирование законченныхчастей совместно с потребителями и отработка конструктивных элементов ужев ходе разработки.В области разработки программного обеспечения с серединысемидесятых годов исследователи и менеджеры много говорят об “итеративномулучшении”, “спиральной модели разработки”, “параллельных альтернативныхпроектах” и так далее. Многие фирмы пытаются реализовать эти идеи, ноделают это медленно и во многом формально.
Такой стиль контрастирует споследовательным внедрением в Microsoft параллельной “водопадной” манерыразработок. Процесс разработки организован так, что максимально сближаютсяи соединяются фазы разработки и тестирования, причем практикуется тесноевзаимодействие с потребителями в ходе ОКР. Это отвечает задачам быстройреализации результатов проекта в условиях быстро меняющейся рыночнойситуации.Ключевая стратегия фирмы Microsoft в области НИОКР состоит вфокусировании усилий на разработке компонентов при “фиксированных”ресурсах. Известно, что продуктивность людей с идеями зависит от четкой159направленности их идейного потенциала. Менеджеры Microsoft заставляютразрабатывающий персонал помнить о том, что люди, вкладывая деньги вприобретение продукции, будут иметь ограниченные возможности. Велик ириск ничего не продать на рынке, особенно такой быстроменяющейся отрасликак программное обеспечение.Microsoft начинает проект с разработки “резюме ситуации” (обычно этодокумент на нескольких страницах с определениями цели проекта, приоритетовпо потребителям и рыночным сегментам).Маркетологи фирмы, ставя эти задачи, консультируются с программнымименеджерами.
Затем последние консультируются с разработчиками, выделяячасти проекта и организуя их размещение. В общем, подход соответствуетизвестной схеме Твисса [7].Спецификация, естественно, не полностью определяет все деталипроекта. В дальнейшем она трансформируется в результате естественного“обучения” исполнителей в процессе работы. Опыт Microsoft свидетельствует отом, что такие изменения затрагивают 30% и более первоначальнойспецификации. Далее проект, как уже говорилось, делится на части и в немвыделяются три или четыре подпроекта с ключевыми точками, которыесоставляют главную часть проекта. Все аспектные части проходят полный циклразработки, интеграции этих аспектов, тестирования и фиксации в каждойключевой точке подпроекта.Отдельные части проектной команды синхронизируют свою работу наоснове дневной или недельной временной сетки.
В конце выполнения каждойчасти проекта (и всего подпроекта) разработчики фиксируют все ошибки,тестируют работу и предоставляют возможность первым пользователям ееоценить. Такая частая коррекция ошибок стабилизирует продукт, позволяетразработчикам понять, что сделано, а где появились проблемы.Microsoft также устанавливает приоритеты частей в каждой ключевойточке, чтобы первыми выполнить наиболее важные части проекта.Устанавливается буферное время (20-50% от полного) в рамках каждогоподпроекта для того, чтобы в случае возникновения непредвиденныхтрудностей или задержек, или дополнительных работ, не срывались основныесроки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
