«Управление и Оптимизация Производственного Предприятия»
|
|
|
|
|
Стратегические аспекты управления НИОКР Монография. Таганрог: Изд-во ТРТУ, 2000. 244с. 6. Организационная структура сферы НИОКР, как стратегический фактор фирмы 6.3. Основные тенденции развития теории проектирования и практики систем управления НИОКРВ целях компактности изложения мы используем результаты теоретических посылок в [107] и изложение практики управления разработками программного обеспечения [82, 103]. Даже сопоставление названий этих работ дает возможность почувствовать основную тенденцию современной практики управления НИОКР. Действительно, посвященная теории проектирования систем управления работа [107] называется “От сложных организаций с простыми работами к простым организациям со сложными работами”, а статьи [82] и [103] называются соответственно “Проектное планирование и процессы разработки в малых командах” и “Как Microsoft делает работу больших команд похожей на работу малых команд”. Выбор в качестве объекта рассмотрения практики управления разработками программного обеспечения компьютерной техники очевиден в силу бурного развития этой отрасли (еще в 1997 г. мировой объем продаж этих средств составил 127 млрд. долл.), ее определяющего значения в нашем информационном мире. Корпорация Microsoft является безусловным лидером в этой отрасли, причем действующей успешно как с научно-технической точки зрения, так и в сфере собственно бизнеса. В сентябре 1999 г. в пятерку самых богатых людей США входили четыре представителя этой корпорации во главе с легендарным Биллом Гейтсом. Работа [107] написана видными голландскими учеными и обобщает тенденции подходов к теории проектирования систем управления организации. В частности она базируется на голландской теории проектирования социотехнических систем управления, названной “Интегральное организационное возобновление (Integral Organization Renewal – IOR)”. В современной рыночной обстановке организации прежде всего сталкиваются с увеличивающейся нестабильностью, неопределенностью и сложностью. Практически часто они вынуждены инвестировать средства в организационную перестройку (реинжиниринг) в целях выживания. Им приходится выбирать между двумя подходами. Первый состоит в увеличении внутренней сложности управления путем введения в систему управления новых функций и, соответственно, новых функциональных подразделений, способных адекватно реагировать на развитие внешней среды фирмы. Кроме создания новых штабных функций, необходимы инвестиции и в вертикальные информационные системы. Такую стратегию можно охарактеризовать как стратегию сложных организаций и простых работ. Второй подход состоит в создании автономных мобильных команд, способных быстро реагировать на вызовы внешней среды. При этом снижаются затраты на внутренний контроль и координацию, достигается уменьшение штабных усилий, уменьшение бюрократии и улучшение общих результатов. Таким образом, лозунг этого подхода: “Простое управление сложными работами”. Применение при таком подходе теории классического социотехнического проектирования систем управления (Sociotechnical Systems Design – STSD) не дает простых стандартных решений. Поэтому и возникла путем адаптации частных методов проектирования систем управления теория IOR. Полагалось, что такая система должна удовлетворять следующим исходным условиям:
Подходы IOR основаны на таких фундаментальных системных основах, как понятие открытой системы, разницы между социальной и технической системами и общей оптимальности, как принципа наилучшего использования всех возможностей. Обычно в традиционных STSD социотехническая система определяется как комбинация социальной и технической подсистем. Однако это противоречит понятию производственной системы как интегральной функциональной системы. Изоляция подсистем искусственна и не отражает функциональные отношения, что является сердцевиной реальных производственных систем. Более того, чистых социальных и технических систем просто нет. Оптимизация, собственно говоря, и заключается в поиске баланса таких взаимоотношений. Базовые концепции IOR:
К числу последних относят:
В подходе IOR принципы проектирования первоначально концентрировались на проблеме сложности. Сложность системы зависит от числа ее элементов, числа внешних и внутренних связей и их изменчивости во времени. Рост сложности ведет к:
Следовательно, основные принципы интегрального проектирования должны включать:
Правила последовательности проектирования абсолютно необходимы в IOR. Они не только обеспечивают эффективность проектирования, но и структурируют процесс проектирования в ясной менеджерам и исполнителям манере. Ниже приводится краткий обзор наиболее фундаментальных правил. Правило 1. Сначала проектируйте производственную структуру, а затем систему управления. Правило 2а. Проектируйте производственную структуру “сверху – вниз”. Интегральное проектирование требует начала с макроуровня (идентификация возможных параллельных потоков), затем перехода к мезоуровню (сегментация) и наконец разработка структуры всех групп работ на микроуровне. Правило 2б. Проектирование производственной структуры предшествует проектированию технологических процессов. Эффективное использование оборудования зависит от специфической архитектуры структуры, в которой оно используется, так как эта структура определяет связи. Более того, применяемая технология определяет группировку и связи оборудования и инструмента. Структурная адаптация к оборудованию, следовательно, только узаконивает технические ограничения структурного проектирования. Правило 3. Проектируйте систему управления “снизу – вверх”. Логика этого правила дискуссионна. Но предлагается следующая процедура:
Правило 4. Проектируйте циклы управления в такой последовательности: размещение, выбор и связь. Единство времени, места и действия – лидирующий принцип. Диапазон фирм, перешедших на подход IOR в Голландии, достаточно широк. В 1997 году это были более 50 компаний, в том числе таких как Филипс, Тобакко, Аегон, Национал Нидерланден. В статье [103] рассмотрена организация разработки программного обеспечения для специальных целей в типичной малой фирме – Академическом вычислительном отделе Летнего института лингвистики (SIL) в г. Далласе (США). Каждый проект, выполняемый по методике SIL, первоначально формируется так называемой руководящей командой. Благодаря наличию этой команды, которую можно назвать руководящим ядром, вся проектная команда может забыть о внешних обстоятельствах и сосредоточиться непосредственно на проекте. Здесь выполняется принцип: “Хороший менеджер – преодолеватель препятствий и поставщик ресурсов”. Зона ответственности руководящего ядра:
Проектная команда группируется из людей, которые хотят работать. Она включает группы, состоящие по меньшей мере из трех человек. Старшие группы принимают решения на основе консенсуса. Естественно, что по мере роста зрелости проекта ведущий разработчик будет меньше занят программированием, а больше – руководством разработки. Процесс на уровне проекта начинается с составления ряда исходных документов: спецификации требований, определения проекта (название, цели, этапы, команды), плана проекта. Роли в проектной команде распределяются в зависимости от характера проекта. Команда может включать минимально стратегического менеджера разработки и двух программистов. В проектной команде должны быть выделены три роли:
Процесс планирования ведется по методу “сверху – вниз” и детализован до модулей. Каждый член команды работает в своем модуле (длительность которого 10-30 дней). В каждом модуле устанавливаются пять ключевых точек:
Процесс планирования и разработки проекта можно сжато изложить так. 1. Процесс на уровне проекта.1.1. Определение проекта.
2. Процесс на уровне этапа.2.1. План этапа.
В любом проектировании возникает проблема специфицирования в начале проекта сложной системы. Практически всегда в ходе выполнения проекта она будет дорабатываться или даже полностью меняться. Поэтому SIL при разработке ПО применяет итеративную стратегию. Блокирование проблемы сложности осуществляется следующими пятью способами.
1. Планирование осуществляется по частям. Наиболее полно и почти что с минутной разбивкой во времени осуществляется планирование начальных частей проекта, а с большей свободой – последующих. Проект, как правило, разбит на двухнедельные части (модули). 2. Каждый модуль проекта превращается в законченную рабочую систему определенного функционального назначения и сразу же тестируется. Это значительно выгоднее, чем организовать большое тестирование в конце этапа проекта. В конце каждого модуля предусмотрена его интеграция в остальной проект. Имплентатор включает новые блоки программ в систему программных блоков проекта и делает ее новую версию для остальной проектной команды. На каждом уровне планирования выделяется отдельное время для ревизии выполненного пользователем и старшим по должности. 3. Объектная технология, которую применяет SIL, хорошо встраивается в итеративный характер разработки. 4. Быстрое создание прототипов и испытание созданной части проекта пользователем помогает разработчикам быстро довести свои идеи до пользователя и дает последнему возможность конкретизировать свое отношение к ним. 5. Каждый модуль полностью тестируется перед передачей его результатов остальной команде. Для этого используются программы автоматической проверки, а затем новые коды передаются на вход системы. Так как для этого необходимо не более одного-двух дней, то исполнители склонны делать это “в рабочем порядке”, не дожидаясь выделенной планом фазы тестирования. Так как каждый модуль включает оценку валидности его результатов в системе, то устраняются многие побочные эффекты новых кодов перед их использованием остальной частью проектной команды. На основании своего опыта SIL сформулировал ряд рекомендаций:
Распространено мнение, что малые команды талантливых людей лучше в сфере НИОКР, чем большие команды средних или даже талантливых людей. Было оценено [82], что при разработке программного обеспечения талантливые программисты в десять и более раз продуктивней наименее талантливых в команде. Однако это может оказаться неверным для других типов исследований и разработок, инжиниринга и прочей интеллектуальной работы. В то же время существует и другая истина: малым командам присущи и определенные ограничения, например при создании очень больших изделий в сжатые сроки. Например, в автомобильной промышленности для разработки нового образца требуется около семи миллионов инженеро-часов. В фирмах “Тойота”, “Хонда”, “Крайслер” над одним образцом работают 500-1000 инженеров в течение 3-5 лет. В “Боинге” этим заняты несколько тысяч инженеров. Многие менеджеры проектов программного обеспечения предпочитают очень малые проектные команды из дюжины или менее программистов. Это наследие культуры ранних лет программирования, когда два или три человека могли создать новый продукт. Первые версии MS-DOS, Word и Excel в начале 1980-х годов создавались программными командами из 6–10 человек. Они включали несколько десятков тысяч программных строк. Но такие малые команды даже в 60-е годы не могли быть использованы IBM, когда в ней около тысячи человек создавали операционную систему для 360-х компьютеров. В 1993 году первая версия Windows NT включала 4,5 млн. программных строк, а проектная команда состояла в пике занятости из 450 человек. В 1995 году Windows 95 состоял из 11 млн. программных строк и над ней работало примерно такое же количество программистов в течение 3 лет. В 1996 году команда из 300 людей создала ключевые компоненты Microsoft’s Internet Exрlorer browser, а на несколько сотен больше работали над устройствами типа Internet–mail [82]. Автор работы [82], профессор Слоуновской школы менеджмента Массачусетского технологического института исследовал работу фирмы Microsoft с 1986 по 1995годы. Результаты этих исследований были обобщены в книге [81]. Основной подход Microsoft к управлению НИОКР характеризуется лозунгом “Синхронизация и стабилизация”. Вывод исследования был концептуально прост. В фирме синхронизуется то, что люди делают индивидуально и как члены команды, работая параллельно над разными частями проблемы, периодически стабилизируются разные стороны проекта на текущих выходах процесса еще до его полного окончания. Термин “выход” относится к акту компиляции или “интегрирования” законченных частей программного обеспечения в процессе разработки. При этом выясняется, какие функции работают и какие проблемы существуют. В больших проектах большое число членов команды разрабатывают большое число отдельных компонентов проекта, которые тесно взаимосвязаны. Проблема начальных этапов разработки состоит в правильной идентификации этих частей. Менеджеры корпорации Microsoft пытаются структурировать и координировать работу отдельных инженеров и команд таким образом, чтобы предоставить исполнителям определенную гибкость в работе и развернуть параллельную разработку деталей проекта на этих этапах. Для обеспечения экономии времени и качества разработки требуется тестирование законченных частей совместно с потребителями и отработка конструктивных элементов уже в ходе разработки. В области разработки программного обеспечения с середины семидесятых годов исследователи и менеджеры много говорят об “итеративном улучшении”, “спиральной модели разработки”, “параллельных альтернативных проектах” и так далее. Многие фирмы пытаются реализовать эти идеи, но делают это медленно и во многом формально. Такой стиль контрастирует с последовательным внедрением в Microsoft параллельной “водопадной” манеры разработок. Процесс разработки организован так, что максимально сближаются и соединяются фазы разработки и тестирования, причем практикуется тесное взаимодействие с потребителями в течение ОКР. Это отвечает задачам быстрой реализации результатов проекта в условиях быстро меняющейся рыночной обстановки. Ключевая стратегия фирмы Microsoft в области НИОКР состоит в фокусировании усилий на разработке компонентов при “фиксированных” ресурсах. Известно, что продуктивность людей с идеями зависит от четкой направленности их идейного потенциала. Менеджеры Microsoft заставляют разрабатывающий персонал помнить о том, что люди, вкладывая деньги в приобретение продукции, будут иметь ограниченные возможности. Велик и риск ничего не продать на рынке, особенно такой быстроменяющейся отрасли, как программное обеспечение. Microsoft начинает проект с разработки “резюме ситуации” (обычно это документ на нескольких страницах с определениями цели проекта, приоритетов по потребителям и рыночным сегментам). Маркетологи фирмы, ставя эти задачи, консультируются с программными менеджерами. Затем последние консультируются с разработчиками, выделяя части проекта и организуя их размещение. В общем подход соответствует известной схеме Твисса (рис. 52).
Рис. 52. Инновация как результат взаимодействия сфер НИОКР маркетинга, производства, управления >Спецификация естественно не полностью определяет все детали проекта. В дальнейшем она трансформируется в результате естественного “обучения” исполнителей в процессе работы. Опыт Microsoft свидетельствует о том, что такие изменения затрагивают 30% и более первоначальной спецификации. Далее проект, как уже говорилось, делится на части и в нем выделяются три или четыре подпроекта с ключевыми точками, которые составляют главную часть проекта. Все аспектные части проходят полный цикл разработки, интеграции этих аспектов, тестирования и фиксации в каждой ключевой точке подпроекта. Отдельные части проектной команды синхронизируют свою работу на основе дневной или недельной временной сетки. В конце выполнения каждой части проекта (и всего подпроекта) разработчики фиксируют все ошибки, тестируют работу и предоставляют возможность первым пользователям ее оценить. Такая частая коррекция ошибок стабилизирует продукт, позволяет разработчикам понять, что сделано, а где появились проблемы. Microsoft также устанавливает приоритеты частей в каждой ключевой точке, чтобы первыми выполнить наиболее важные части проекта. Устанавливается буферное время (20-50% от полного) в рамках каждого подпроекта для того, чтобы в случае возникновения непредвиденных трудностей или задержек, или дополнительных работ, не срывались основные сроки. Разработчики продукта составляют краткий обзор положения перед кодированием, так как персонал реализует и то, что не было предусмотрено ранее для улучшения продукта. Такой подход оставляет разработчикам благоприятные возможности, но и таит определенные угрозы. В частности для прикладных продуктов команды разработки пытаются переходить от частей схемы прямо к особенностям их использования, что типично для поведения потребителей и это требует тщательного обдумывания и тестирования с пользователями. Дополнительно проекты наиболее прикладного характера имеют модульную структуру, что позволяет командам частично добавлять или комбинировать относительно легко отдельные части. Менеджеры обычно позволяют членам команды иметь свои собственные планы, но только после того, как они согласуют это в деталях с остальным персоналом. Менеджеры затем “фиксируют” проектные ресурсы по численности команды по каждому проекту. Они также ограничивают проект во времени, особенно в приложениях, таких как Office или мультимедийный продукт. Microsoft использует вторую стратегию – параллельное выполнение чего-то с частичной синхронизацией. Целью при этом является дисциплина в процессе разработки без непрерывного контроля каждый день. Большие проекты проще в планировании и управлении, если они выполняются четко определенными функциональными группами, по точным правилам и под контролем. Этот подход, однако, не способствует инновациям и переоценивает важность синхронизации. Связь и координация затруднена по функциям и фазам и это может вызвать задержку осуществления проекта и дополнительную необходимость в людях. Это заставляет Microsoft делать так, как это делается в малых компаниях и при индивидуальных исполнителях – обеспечивать свободную работу в параллель. Подход Microsoft, (“синхронизация – стабилизация”) дает ценные уроки в том, как управлять большими командами по проекту и как интегрировать работу многих подкоманд или отдельных лиц. Интеграционный процесс особенно труден в проектировании программного обеспечения, так как здесь можно легко менять компоненты и трудно предвидеть последствия этого для других компонентов и процесса тестирования. Программисты не имеют дела с металлом и производством, которое длится не один месяц. Это – также проблемы технического и управленческого образования. Для поддержания объемов проектов в небольших пределах менеджеры компании пытаются ограничить их размеры и области разными путями:
В заключение отметим ключевые элементы подхода Microsoft:
|
||
