62
от развития и укрепления вертикальных связей.
На основе вышеприведённых моментов можно сделать вывод, что гибкие
методологии будут полноценно работать только в компаниях с плоской
организационной структурой. Это не означает, что внедрение гибких
методологий невозможно в иерархических структурах - однако, в этом случае
могут понадобиться значительные изменения в организационной структуре, так
как отдельное внедрение для конкретной проектной группы может не привести
к желаемым результатам. Таким образом, далее требуется провести анализ
организационной структуры, который в общем виде заключается в следующем:
построение графической модели организационной структуры;
определение первичных количественных характеристик -
количество уровней управления, численность, номенклатура должностей,
количество структурных единиц;
определение некоторых количественных оценок;
определение качественных характеристик с использованием
экспертных оценок;
оценка соответствия организационной структуры управления
системе целей, технологии, размерам предприятия, состоянию внешней среды.
Следующим этапом внедрения гибких методологий является анализ
сотрудников, при котором собирается информация об интересах сотрудников,
межличностных отношениях, микрогруппах, формальных и неформальных
лидерах и возможных ролях в гибких методологиях. Анализ может быть основан
на социометрическом методе анализа, в котором используются опросы,
фокусируются на количественном измерении межличностных отношений и
анализе небольших социальных групп в формальных и неформальных
ситуациях. Кроме того, можно провести анализ потребностей на основе
пирамиды Маслоу. Схема анализа сотрудников представлена ниже (рис. 11).
63
Рисунок 11. Общая схема анализа сотрудников
На этапе выбора базовой методологии производится выбор существующей
методологии гибкой разработки, наиболее близко подходящей для проектной
деятельности в организации. Здесь стоит учитывать, что и Kanban, и Scrum, и XP
являются не строго определёнными методологиями, а скорее «каркасом», на
основе которого позже можно создать собственную методологию.
После принятия решения о выборе конкретной методологии Agile перед
руководством возникает задача выбора тренера или консультанта,
специализирующегося на выбранной гибкой методологии. Следующим шагом
после выбора тренера является выбор команды, которая будет первая работать
по выбранной методологии. На начальном этапе внедрения предпочтительным
будет выбрать одну конкретную команду, при этом выбор со стороны
руководства должен быть осознанным. Команда может состоять из 7-9 человек
и работать над долгим сложным проектом (полгода, год). Но на практике
элементы Agile могут быть использованы и малыми командами в коротких
проектах.
Для работы по принципам гибкой методологии требуется сработанная
команда с высоким уровнем квалификации и профессионализма. В противном
случае внедрение Agile может привести не к ожидаемому повышению
эффективности работы команды, а к значительному снижению. Однако выбор
сильной команды так же может отрицательно сказаться на результатах
внедрения, так как её члены могут неявно «сопротивляться» переходу, если
процессы работы и так были отлажены и переход навязывается ей как дань моде
или желание менеджмента внедрить прогрессивные подходы. Таким образом,
хорошим выбором для внедрения Agile будет сильная команда, члены которой
осознают несовершенство процессов своей работы. Кроме того, нужно уделить
64
внимание конкретным членам команды. Для Agile не слишком подходят
специалисты, которым важна индивидуальная оценка работы, поскольку
оцениваются командные результаты. Следовательно, ставку желательно делать
на «командных игроков», так как специалистам необходимо все время
находиться в контакте для поиска оптимальных решений и идей для улучшения
продукта.
Следующим этапом внедрения Agile является адаптирование выбранной
методологии к требованиям проекта, команды и организации. На этапе
адаптирования проводится анализ конфликтов между выбранной гибкой
методологией и принципами организации или интересами сотрудников, после
чего вносятся необходимые изменения (рис. 12).
Рисунок 12. Общая схема этапа адаптирования гибкой
методологии
На этапе адаптирования анализируются следующие элементы выбранной
гибкой методологии: роли внутри команды, процессы и методы работы.
Адаптирование ролей может быть проведено тремя способами:
реорганизация существующих ролей на основе новых методологий;
добавление новых ролей к уже существующим;
адаптирование ролей гибких методологий к существующим ролям.
Параллельно с адаптированием ролей на основе результатов анализа
организации и выявленных конфликтов проводится изменений организационной
65
структуры.
Организационная структура компании, работающей по принципам Agile, в
общем виде должна соответствовать организационным структурам,
направленным на проектную деятельность. Можно выделить две группы
организационных структур, вовлеченных в процесс регулирования проектной
деятельности компании:
постоянно действующие;
временные.
Предположим, что для функционирования компании требуются постоянно
действующие проектные группы - следовательно, они должны быть полноценно
интегрированы в существующую организационную структуру. Для подобной
интеграции лучше всего подходят проектная и матричная организационная
структура.
Ниже представлена типичная линейно-функциональная структура, которая
характеризуется чёткой системой единоначалия, слабо развитыми
горизонтальными связями и негибкостью для изменений. Выполнение Agile
проектов в подобной компании является фактически невозможным, поэтому в
подобную структуру требуется внести изменения (рис. 13).
Рисунок 13. Линейно-функциональная организационная
структура
66
В линейно-функциональную структуру возможно внесение следующих
изменений:
объединение нескольких функциональных подразделений в одну
продуктовую группу;
сокращение числа менеджеров;
совершение перехода от отделов к функциональным направлениям,
характеризующимся низким уровнем бюрократизации и открытостью
коммуникаций.
Полученная организационная структура представлена ниже (рис. 14).
Рисунок 14. Организационная структура организации после
внедрения Agile
Детали организационной структуры могут меняться в зависимости от
конкретной методологии: например, роль непосредственного руководителя по
продукту может отсутствовать.
Другим вариантом трансформации организационной структуры является
матричная структура. В установившуюся линейно-функциональную структуру
вводятся особые органы, которые координируют существующие
горизонтальные связи по выполнению конкретной программы (проекта),
67
сохраняя при этом вертикальные отношения, свойственные данной структуре.
Основная часть работников, занятых реализацией программы, оказывается в
подчинении не менее двух руководителей.
Переход к данной структуре является наименее болезненным, но в
некоторых случаях менее эффективным за счёт системы двуначалия. Однако её
применение необходимо в тех случаях, когда проекты хоть и являются важной
частью функционирования организации, но при этом не являются абсолютной
доминантой в структуре деятельности. При использовании такой структуры
приоритет должен отдаваться не функциональному, а проектному направлению
для обеспечения максимально возможной независимости проектных команд.
Кроме того, стоит помнить об особой роли руководителя проекта по выбранной
методологии. Матричная структура Agile-организации представлена ниже (рис.
15).
Рисунок 15. Матричная организационная структура предприятия,
работающего по гибкой методологии
В идеальном случае внедрения Agile компания должна перейти на
проектную организацию работ, а проектный менеджмент должен стать одним из
основных направлений управления жизнедеятельностью компании. За
68
изменениями в организационной структуре идут изменения в полномочиях.
Перевод работы на проектные управления однозначно меняет права и
обязанности сотрудников и подразделений, хотя бы просто потому, что
появляются новые подразделения и комитеты, отвечающие за управление
изменениями. За изменениями в организационной структуре и полномочиях
следует изменение в системе мотивации. Введение проектной и линейной систем
мотивации, их взаимная балансировка — необходимый шаг в преобразованиях в
компании, переходящей на гибкие методологии.
Далее следует подобрать параметры работы для команды. В отлаженной
повседневной работе параметры определяет сама команда, однако на начальном
этапе внедрения следует подобрать исходные значения, проконсультировавшись
с приглашенным тренером.
После проведения подготовительной части проводится непосредственное
внедрение выбранной методологии. Разберём этот процесс на примере Scrum.
После консультаций с руководителями и лидерами команды проводится общий
тренинг для всех членов команды, на котором объясняются основные принципы
конкретной методологии, проводятся деловые игры для освоения базовых
практик. Спустя некоторое время после тренинга начинается первый пробный
спринт, который обязательно проводится в присутствии тренера: команда
обсуждает задачи на грядущий спринт, даёт оценку трудоёмкости и формирует
объём работ. Перед тренером изначально стоит задача оказания
непосредственной помощи, исправления ключевых ошибок, внесения
предложений по корректировке процесса, однако по прошествии времени тренер
оказывает только консультационные услуги.
Руководству нужно быть готовым к временному ухудшению качества
исполнения проектов в период перехода на Agile. Однако после полной
адаптации методологии эффективность работы команды обычно возрастает.
При внедрении гибких методологий компании сталкиваются с множеством
проблем, и совершают множество ошибок. Разберём ошибки на примере
методологии Scrum, а также выделим возможные пути их решения.
69
Некоторые компании после внедрения гибких методологий продолжают
пытаться измерять ход работ по проекту по контрольным точкам, однако такой
подход является неверным. В зависимости от методологии используются
различные методы измерения прогресса - например, в Scrum используется
диаграмма сгорания задач.
При внедрении гибких методологий компании сталкиваются с разницей в
продолжительности жизненных циклов - традиционные процессы отличаются
более долгими жизненными циклами проектов, поэтому их продолжительность
требует корректировки.
Большое значение в проектной деятельности несёт качественное
определение объёмов предстоящих работ. Невыполнение данной задачи
приводит к фактическому замедлению темпа работ. Данная проблема может
быть связана с тем, что в большинстве компаний оценивают сроки выполнения
задач, а не трудоемкость. Кроме того, саму оценку проводят обычно не
непосредственные исполнители, а руководители, что противоречит смыслу
гибких методологий.
Рано или поздно компании сталкиваются с проблемой формирования
спринтов. Работы по некоторым проектам невозможно распределить по
небольшим спринтам таким образом, чтобы в конце каждого спринта получить
последний прирост. В таком случае, одно и то же задание может выполняться в
течение нескольких спринтов.
Важной ошибкой после внедрения гибких методологий является
игнорирование ежедневных Scrum-митингов. Если встречи и проводятся, то на
них присутствуют по различным причинам не все члены команды. Схожей
ошибкой является непонимание роли журнала продукта. Журнал продукта часто
ведется командами для галочки, из него участники проекта не могут понять, над
чем они будут работать в ближайшие несколько спринтов, или сколько работы
осталось до конца проекта.
Часто при работе по гибким методологиям возникает проблема, когда
участники команды не хотят брать на себя инициативу и нести ответственность
70
за результат отдельной задачи или спринта. Особенно остро данная проблема
проявляется в компаниях, где создается корпоративная культура, при которой
сотрудникам не хочется проявлять инициативу и брать на себя ответственность.
Существует проблема с пониманием сущности основных ролей. Например,
Scrum-мастер, имеющий опыт работы в роли руководителя проекта, продолжает
вести себя как непосредственный руководитель проекта, принимая большинство
решений по проекту самостоятельно. Однако Scrum-мастер не является рядовым
менеджером, которому команда строго подчиняется, следовательно,
формальные отчёты перед ним не требуются. Так же существует ситуация, когда
владелец продукта не понимает свои функции и не осознаёт основную цель,
которую он должен реализовать, выполняя свою роль.
Подведя итог по перечисленным выше проблемам можно сказать, что
большинство из них возникают в результате непонимания командой сути гибкой
разработки, и в частности непонимании механизмов работы по конкретной
методологии. Таким образом, можно сказать, что важнейшим шагом к переходу
на Scrum является обучение и подготовка персонала и менеджеров, а так же
владельца продукта.
3.3 Расчет экономической эффективности предложенных мероприятий
Для проведения общей оценки применения методологий гибкой
разработки рассмотрим, какое влияние окажет их внедрение на
заинтересованные стороны. Заинтересованная сторона проекта (стейкхолдер) -
лицо, группа или организация, которая может влиять на проект, либо на которую
могут повлиять результаты проекта или отдельные задачи проекта.
В первую очередь, разберём общее влияние от использования Agile на
стейкхолдеров в зависимости от их модели поведения. Некоторых
стейкхолдеров устраивает простое знание того, что происходит в компании и
проекте, они не требуют особых результатов. Гибкие методологии улучшают
71
взаимодействие с подобными стейкхолдерами за счёт прозрачности и частоты
выпуска продукта. Прозрачность заключается в том, что фактически любое
заинтересованное лицо при желании может наблюдать за текущим прогрессом
команды и свободно общаться с её членами. Частота выпуска за счёт коротких
итераций даёт стейкхолдеру возможность отслеживать общий прогресс работы,
а так же вносимые в проект изменения, на регулярной основе.
Существуют стейкхолдеры, которые заинтересованы только в надежных и
предсказуемых результатах проектов. В течение первых нескольких месяцев
после перехода на гибкие методологии отношения с такими заинтересованными
лицами могут быть затруднены, что связано с отсутствием как такового полного
планирования проекта - в некоторых случаях команда может представлять
конечный продукт лишь в самых общих чертах. Для стабилизации отношений
таких стейкхолдеров следует ознакомить с журналами проекта и спринтов.
Помимо двух уже перечисленных групп заинтересованных лиц, можно
выделить ещё и третью, отличающуюся желанием вносить непосредственный
вклад в работу и видеть результаты этого вклада. Применение Agile
обеспечивает идеальные отношения с подобными стейкхолдерами. Эти
заинтересованные лица могут напрямую влиять на проект, а степень их влияния
зависит лишь от конкретной гибкой методологии. Так, например, в Scrum
стейкхолдер может выполнять роль владельца продукта и определять общее
видение проекта в практически любой момент времени.
Разберём теперь влияние Agile на стейкхолдеров в зависимости от их ролей
относительно проекта и организации. К основным стейкхолдерам можно отнести
следующие группы лиц:
руководители, заказчики, инвесторы;
поставщики;
покупатели и пользователи;
работники.
В зависимости от типа организации инвесторы, руководители и заказчики