Лидер, компетенции и команда

Стратегической инноватике требуется не менеджер, а лидер. Лидер вскрывает всю глубину кризисного положения, разрабатывает и выдвигает концепцию радикального развития организации, опираясь на возможности и потенциал ее сотрудников, на глубокое знание и предвидение состояния внешней среды. Лидер может объединить и вести участников инновационного сложного и непредсказуемого процесса, выдвигает далеко не очевидные (порой парадоксальные), но единственно возможные решения, казалось бы, тупиковых ситуаций и лишь лидеру могут в этом случае поверить участники. Требуется содействие в выдвижении и становлении лидера (хотя чаще всего будущие лидеры выдвигаются сами).

Выполнение проекта по методике SIL, первоначально формируется так называемой руководящей командой [79]. Благодаря наличию этой команды, которую можно назвать руководящим ядром, вся проектная команда может забыть о внешних обстоятельствах и сосредоточиться непосредственно на проекте. Зона ответственности руководящего ядра:

· идентификация целей проекта;

· подготовка проектного задания;

· выбор и комплектование членов команды;

· определение других необходимых ресурсов и обеспечение ими проектной команды;

· мониторинг процесса в работе проектной команды;

· «сигнализация вовне» о результатах, полученных командой проекта;

· обеспечение совместимости деятельности команды с работой остальной части организации.

Процесс разработки проекта начинается с составления ряда исходных документов: спецификации требований, определения проекта (название, цели, этапы, команды), плана проекта.

Проектная команда группируется из людей, которые хотят работать (по меньшей мере, три человека). Старшие группы принимают решения на основе консенсуса. По мере роста зрелости проекта ведущий разработчик будет меньше занят программированием, а больше – руководством разработки.

Роли в проектной команде распределяются в зависимости от характера проекта. Команда может включать как минимум стратегического менеджера разработки и двух программистов. В проектной команде должны быть выделены три главных роли [57, 60, 79]:

· имплементатор (комплексный специалист), который отслеживает программные блоки для всего проекта;

· специалист по области применения, который отвечает за выполнение требований спецификации и ревизует результаты;

· специалист по ревизии технических аспектов разработки.

Процесс планирования проекта ведется по методу «сверху – вниз» и детализован до модулей. Каждый член команды работает в своем модуле (длительность которого 10–30 дней). В каждом модуле устанавливаются пять ключевых точек [79]:

· план составлен;

· план одобрен командой проекта (или принято решение о его развитии);

· первоначальный вариант выполнен;

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

· оценка работы (модуль выполнен и оценен руководителем).

Процесс планирования и разработки проекта:

1. Процесс на уровне проекта.

1.1. Определение проекта. Организация решает делать проект и формирует руководящее ядро. Руководящее ядро пишет резюме и формирует команду проекта.

1.2. План проекта. Проектная команда разбивает проект на стадии, устанавливает стандарты и процедуры обеспечения качества работы, это получает одобрение руководящего ядра (если необходимо – проводится ревизия).

1.3. Выполнение проекта. Проектная команда следует установленному порядку процесса для каждой стадии плана проекта. Руководящее ядро преодолевает препятствия и обеспечивает нужные ресурсы.

1.4. Оценка проекта. И руководящее ядро, и проектная команда ищут пути улучшения продукта, улучшения проекта и проектного процесса.

2. Процесс на уровне этапа.

2.1. План этапа. Команда проекта разбивает этап на модули, приписывая каждый модуль члену команды, который представляет план руководящему ядру (при необходимости план пересматривается).

2.2. Выполнение этапа. Проектная команда следует процессу на уровне модуля для каждого модуля этапа. План пересматривается по результатам опроса потребителей. Лидер команды преодолевает препятствия и обеспечивает ресурсы, поддерживая прогресс в соответствии с планом этапа.

2.3. Оценка этапа. Команда проекта рассматривает пути улучшения продукта этапа, улучшая план этапа и процесс проектирования.

3. Процесс на уровне модуля.

3.1. План модуля. Программист (или старший разработчик) разрабатывает детальную методику и тестовую программу для проектной команды или план работы по модулю.

3.2. Выполнение модуля. Программист следует разработанной методике, выполняет план, который может пересматриваться по замечаниям проектной команды.

3.3. Оценка модуля. Лидер команды и старший программист рассматривают пути улучшения продукта модуля, улучшения плана этапа, улучшения процесса проекта.

В любом проектировании возникает проблема специфицирования в начале проекта. Существует пять способов блокирования этой проблемы:

1. Планирование осуществляется по частям. Наиболее полно и почти что с минутной разбивкой во времени осуществляется планирование начальных частей проекта, а с большей свободой – последующих. Проект, как правило, разбит на двухнедельные части (модули).

2. Каждый модуль проекта превращается в законченную рабочую систему определенного функционального назначения и сразу же тестируется. Это значительно выгоднее, чем организовать большое тестирование в конце этапа проекта. В конце каждого модуля предусмотрена его интеграция в остальной проект. Имплентатор включает новые блоки программ в систему программных блоков проекта и делает ее новую версию для остальной проектной команды. На каждом уровне планирования выделяется отдельное время для ревизии выполненного пользователем и старшим по должности.

3. Объектная технология, которую применяет SIL, хорошо встраивается в итеративный характер разработки.

4. Быстрое создание прототипов и испытание созданной части проекта пользователем помогает разработчикам быстро довести свои идеи до пользователя и дает последнему возможность конкретизировать свое отношение к ним.

5. Каждый модуль полностью тестируется перед передачей его результатов остальной команде. Для этого используются программы автоматической проверки, а затем новые коды передаются на вход системы. Так как для этого необходимо не более одного-двух дней, то исполнители склонны делать это «в рабочем порядке», не дожидаясь выделенной планом фазы тестирования. Так как каждый модуль включает оценку валидности его результатов в системе, то устраняются многие побочные эффекты новых кодов перед их использованием остальной частью проектной команды.

В процессе составления плана и разработки проблема специфицирования, как показывает практика, возникает постоянно, это обусловлено большим разнообразием работ, которые сложно разделить на части с учётом их (работ) специфики. Поэтому существует ряд рекомендаций, направленных на разрешение проблемы специфицирования [79]:

1. Когда система слишком сложна для специфицирования, ускорьте создание ее прототипа.

2. Команды должны выработать стандартные процедуры разработки и описать их в деталях. Это часть того, что способствует формированию команд.

3. Включайте всю команду в организацию процессов разработки, это создает чувство сопричастности.

4. Если ваш процесс не изменяется, если он не является объектом дискуссии и дебатов, то он не может быть использован. Хороший процесс органичен, превращается в привычку. Как и любое действие, вы можете его документировать. Лучшее, что вы можете сделать – руководить его развитием, но попытки ускорить это в приказном порядке больше похожи на поощрение восстания, чем на участие.

5. Точно определяйте роль каждого члена команды и делайте так, чтобы каждая команда имела персонально обозначенную ключевую роль.

6. Организуйте эффективные коммуникации в вашем процессе – тренируйте членов команды в командной динамике и эффективной технике совещаний.

7. Разделяйте проекты на малые куски. Выполняйте большое дело путем малых шагов.

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

9. Небольшие измерения лучше, чем их отсутствие. И всегда хорошо, если имеется ряд измерений.

10. Желательно, чтобы команда принимала решения консенсусом. Это позволяет работать вместе для нахождения приемлемых решений перед внесением их в план. Это не всегда легко, но групповой консенсус – помощь в создании техники.

11. Защищайте людей от препятствий и излишнего вмешательства руководства.

12. Тестируйте план, как правило, 1/3 времени отводится кодированию, 1/3 – тестированию и ревизии и 1/3 – другим видам действий.

13. Снабжайте каждого члена команды информацией о положении дел в проектировании. Это создает соответствующий моральный климат, поддерживает сопричастность людей и стимулирует их.

Менеджеры обычно позволяют членам команды иметь свои собственные планы, но только после того, как они согласуют это в деталях с остальным персоналом. Менеджеры затем «фиксируют» проектные ресурсы по численности команды по каждому проекту.

Спецификация естественно не полностью определяет все детали проекта. В дальнейшем она трансформируется в результате естественного «обучения» исполнителей в процессе работы. Далее проект делится на части и в нем выделяются три или четыре подпроекта с ключевыми точками, которые составляют главную часть проекта. Все аспектные части проходят полный цикл разработки, интеграции этих аспектов, тестирования и фиксации в каждой ключевой точке подпроекта.

Отдельные части проектной команды синхронизируют свою работу на основе дневной или недельной временной сетки. В конце выполнения каждой части проекта (и всего подпроекта) разработчики фиксируют все ошибки, тестируют работу и предоставляют возможность первым пользователям ее оценить. Такая частая коррекция ошибок стабилизирует продукт, позволяет разработчикам понять, что сделано, а где появились проблемы.

Устанавливается буферное время (20-50% от полного) в рамках каждого подпроекта для того, чтобы в случае возникновения непредвиденных трудностей, задержек или дополнительных работ не срывались основные сроки. Разработчики продукта составляют краткий обзор положения перед кодированием, так как персонал реализует и то, что не было предусмотрено ранее для улучшения продукта. В частности, для прикладных продуктов команды разработки пытаются переходить от частей схемы прямо к особенностям их использования, что типично для поведения потребителей и это требует тщательного обдумывания и тестирования с пользователями. Дополнительно проекты наиболее прикладного характера имеют модульную структуру, что позволяет командам частично добавлять или комбинировать относительно легко отдельные части.

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

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

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

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

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

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

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

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

Ключевые элементы данного подхода:

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

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

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

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

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

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

· гибкость продукта–процесса для подстройки к неизвестному (развитие продуктивной спецификации, буферное время проекта, развитый процесс).

В современной рыночной обстановке организации прежде всего сталкиваются с увеличивающейся нестабильностью, неопределенностью и сложностью. Практически часто они вынуждены инвестировать средства в организационную перестройку (реинжиниринг) в целях выживания, выбирая между двумя подходами [53, 57, 60, 79]:

1. В увеличении внутренней сложности управления путем введения в систему управления новых функций и, соответственно, новых функциональных подразделений, способных адекватно реагировать на развитие внешней среды фирмы. Кроме создания новых штабных функций, необходимы инвестиции и в вертикальные информационные системы. Данная стратегия – стратегия сложных организаций и простых работ.

2. В создании автономных мобильных команд, способных быстро реагировать на вызовы внешней среды. При этом снижаются затраты на внутренний контроль и координацию, достигается уменьшение штабных усилий, уменьшение бюрократии и улучшение общих результатов. Лозунг этого подхода: «Простое управление сложными работами».

Поэтому путем адаптации частных методов проектирования систем управления и возникла теория IOR. Подходы IOR основаны на таких фундаментальных системных основах, как понятие открытой системы, разницы между социальной и технической системами и принципа наилучшего использования всех возможностей. Базовые концепции IOR [48]:

· интегральное проектирование;

· управляемость;

· двойная концепция продуктовой структуры и системы контроля;

· выделение структурных параметров:

· функциональную концепцию (практически ответ на вопрос: есть подсистемы или они отсутствуют?);

· дифференциацию функций;

· специализацию деятельности (степень разбиения функций на подфункции);

· выделение рабочих и контрольных функций;

· специализацию контроля;

· дифференциацию управления (стратегическое, оперативное, структурное);

· разделение функций управления по фазам цикла управления.

Правила последовательности проектирования инновационного процесса абсолютно необходимы в IOR, так как они не только обеспечивают эффективность проектирования, но и структурируют процесс проектирования в ясной менеджерам и исполнителям манере. Далее приводится краткий обзор наиболее фундаментальных правил [48]:

Правило 1. Сначала проектируйте производственную структуру, а затем систему управления.

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

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

Правило 4. Проектируйте систему управления «снизу – вверх». Но предлагается следующая процедура:

· тщательное проектирование индивидуальных инструкций;

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

· гибкий выбор шагов внедрения перестраиваемой структуры управления.

Правило 5. Проектируйте циклы управления в такой последовательности: размещение, выбор и связь. Единство времени, места и действия – лидирующий принцип.

Маркетологи фирмы консультируются с программными менеджерами. Затем последние консультируются с разработчиками, выделяя части проекта и организуя их размещение. Подход соответствует известной схеме Твисса
(рис. 9.21.) [44].

Рис. 9.21. Инновация как результат взаимодействия сфер НИОКР, маркетинга,