12
В проектной организации члены команд обычно собраны в одном месте.
Большая часть ресурсов организации задействована в работах проектов, а
менеджеры проектов в значительной степени независимы и обладают
большими полномочиями. Проектные организации часто имеют
подразделения, называемые отделами, эти подразделения подотчетны
непосредственно менеджеру проекта. Члены проектной команды полностью
ориентированы на результаты проекта и его руководителя. Проектную
структуру организации часто представляют как противоположность
функциональной [17].
Обычно проектные организационные стронуты применяются при
необходимости осуществления больших проектов проект комплексного
характера, охватывающий решение широкого круга сложных технических,
экономических и иных задач. Такая структура наиболее эффективна при
осуществлении больших проектов с длительным жизненным циклом.
Проектная организационная структура ориентирована на предприятия, у
которых основной вид направлены на создание нового, нетипового продукта
или услуги.
Несомненным преимуществом проектной организационной структуры
является Наличие единого центра ответственности за проект с четко
определенными полномочиями и концентрация усилий на решении одной
задачи, на выполнении одного конкретного проекта, объединение
специалистов различных профилей в рамках одной команды, а часто и в
рамках одного помещения позволяет осуществить комплексный подход
решению проблем в частность, и к реализации проекта в целом. Для проектной
организации характерна большая концентрация всех членов команды на
поставленных целях, которые четко понятны всем членам команды, участники
команды считают себя единым целым, позволяет поддерживать высокий
уровень мотивации в команде. Централизованное управление позволяет
значительно быстрее принимать решения, оперативно реагировать на
13
изменения требования. Помимо этого, для проектной структуры характерно
усиления личной ответственности руководителя деятельность проектной
команды и за результаты проекта. Так как проектная структура не зависит от
функциональной структуры и сложившейся системы подчинения компании,
она достаточно проста для понимания и внедрения [5].
При всех вышеописанных преимуществах применения проектной
организационной структуры в проектной организации, такие структуры имеют
свои недостатки. В первую очередь стоит обратить внимание на проблемы,
связанные с оптимальной загрузкой членов команды работой,
соответствующей их компетенции и квалификации, часть команды может
оказаться недогружена или перегружена на этапах проекта. Так же могут
возникнуть сложности с привлечением в команду квалифицированных
специалистов на полный срок. Для решения этой проблемы приходится
заранее привлекать специалистов и держать из значительно дольше, чем это
необходимо [26]. Как следствие из вышеописанной проблемы при
использовании «чистой» проектной структуры в организации зачастую
возникает дублирование ресурсов. Немаловажным де мотивирующим
фактором для персонала в проектной организации может оказаться
обеспокоенность членов команды своей судьбой после завершения проекта,
зачастую член команды больше озабочен сохранением своего рабочего места
после завершения проекта, чем самим проектом, что особенно вредно на
финальных стадиях проектов.
Решением, совмещающим достоинства функционально и проектной
организации, и нивелирующим их недостатки считается матричная структура.
Пример организации с матричной структурой приведен на Рисунке 3.
14
Рисунок 3. Матричная организационная структура.
Источник: PMBOK Guide. Свод знаний по управлению проектами
[17]
Большая часть современных организаций включает в себя все подобные
структуры, даже полностью функциональная организация может создать
специальную проектную команду для управления отдельными проектами.
Остановимся на этих структурах более подробно. В матричной
структуре, отношения отчетности представляет из себя сетку, а каждый
сотрудник как правило отчитывается перед двумя руководителями:
функциональным менеджером и менеджером проекта.
Применение матричных структур обычно дает компании ряд
значительных преимуществ, среди них: гибкое, эффективное распределение и
совместное использование ресурсов, руководители имеют возможность
разместить сотрудников там, где они наиболее необходимы [26]. Более
эффективный обмен информацией: в функциональных или линейных
структурах сотрудники как правило, имеют изолированные каналы
коммуникации: сотрудники одного отдела общаются в основном с
15
сотрудниками этого отдела. В матричной структуре сотрудники находятся в
постоянном контакте, поддерживая как горизонтальные, так и вертикальные
связи. В результате чего скорость личного взаимодействия растет, увеличивая
поток информации между проектами и отделами. За счет увеличения потока
информации, организаций с матричными структурами выигрывают от более
быстрого и эффективного принятия решений[26].
Матричная структуры способствует более демократичному стилю
управления, работники получают более широкую автономию, получая задачи
из нескольких источников сотрудники должны принимать решения о
расстановке приоритетов. С другой стороны, подобное преимущество может
оказаться проблемой для сотрудников, не умеющих самостоятельно
принимать решения и управлять приоритетами.
В зависимости от внутренней организации различают слабые, сильные
и сбалансированные матрицы. Первые из них сохраняют в себе признаки
функциональной организации, а функции менеджера проекта в них скорее
соответствуют функциям диспетчера проектов. В сбалансированных матрицах
уделяется больше внимания роли менеджера проекта, однако в ней менеджер
по-прежнему не обладает всеми полномочиями по управлению проектом.
Сильные матрицы, в противоположность слабым обладают многими
свойствами проектных организаций, в них включаются штатные менеджеры
проектов с широкими спектром полномочий.
Интересным видом организационной структуры являются Ad Hoc
матрицы, такие структуры, такие структуры применяются в случаях, когда для
организации нет необходимости создавать долгоживущие матричные
структуры. В этих случаях матрица создается для решения краткосрочной
проблемы и прекращает свое существование, когда необходимость в ней
отпадает. Такой подход позволяет гибко распределить персонал, обеспечив
его наличие именно там, где от сейчас нужен.
16
Хотя матричные структуры начали внедряться с конца 1970-х годов, их
использование по-прежнему является предметом споров. Применение
матричных структур оказались неудачными для некоторых организации, что
породило недоброжелателей. Одним из критиков матриц является Найджел
Николсон, чья бизнес-школа утверждает, что матричная структура является
“одной из самых сложных и наименее успешные организационные формы " в
силу присущей ей сложности [28].
Матричные структуры рассматриваются как одни из наиболее сложных
организационных структур для внедрения и поддержки. Организации,
использующие матричные структуры могут сталкиваются со следующими их
недостатками: внутренняя сложность, двойное подчинение функциональному
руководителю и менеджеру проекта может привести к сбою в системе
управления, особенно на первых этапах внедрения структуры. Некоторые
противники матриц утверждают, что матричные структуры “размывают
ответственность". Другой проблемой применения матричной структуры могут
стать дополнительные расходы на управление, так как матричные структуры
требуют наличие дополнительных менеджерских позиций, особенно это
касается сильных матриц. Еще одной характерной проблемой, с которой
может столкнуться организация, использующая матричную структуру,
является дефицит ресурсов. Использование матрицы ведет к росту числа что
ведет лиц, заинтересованных в использовании разделяемых ресурсов, что
ведет к возникновению интенсивной конкуренции за ресурсы. Помимо этого,
подобная конкуренция может приводить к конфликтам между различными
проектами.
Несмотря на все вышеописанные недостатки и наличие негативного
опыта, сторонники матричных структур считают, большинство негативных
результатов применения матрицы связано с к бесхозяйственности,
недостаточным уровнем организации, или плохой их реализацией, а не с самой
матричной структурой [28]. Матричная структура успешно внедрены во
17
многих крупных, глобально-ориентированных компаниях. Основываясь на
этом, поклонники матричной организации делают вывод, что матричные
структуры наиболее подходят "там, где существует конечная задача
вовлеченный и где каждый разделяет подобное чувство цели.”
Таким образом, на основании проведенного обзора организационных
структур в современных организациях мы можем сделать вывод, что выбор
той или иной структуры в значительной степени зависит от характера
деятельности организации и от характера выполняемых ей проектов. В целом
стоит отметить тенденции к использованию матричных организационных
структур с различной степенью связанности.
1.2 Современные методологии управлении разработкой ПО,
влияние выбранной методологии на структуру проектной команды
В этой главе мы проведем обзор наиболее распространенных
методологий управления процессом разработки ПО. В настоящий момент
основным трендом в этой области являются Agile методологии, такие как
Scrum и Kanban, большинство из публикуемых сегодня работ посвящено
именно этим методологиям. Однако, при формальном главенстве Scrum и
Kanban методологий, многие компании-разработчики фактически
продолжают использовать популярные в конце 90-х и в начале 2000-х
методологии RAD и Экстремальное программирование (XP). Например, в
ходе интервью с одним из руководителей разработки компании UCS, которая
существует на российском рынке с 1992 года, и в 2016 году занимала 37%
российского рынка систем автоматизации ресторанного бизнеса по
результатам исследования Лемма групп [24] , автор настоящей работы
установил, что в 2016 году в ходе вхождения компании UCS в медиахолдинг
Rambler, компания UCS совместно с Rambler провела внутренний аудит, в
ходе которого было выявлено, что основной методологией разработки ПО в
компании UCS является RAD. По результатам аудита было принято решение
18
сохранить указанную методологию в качестве основной методологии при
разработке ПО. Признаки использования методологии XP так же будут
показаны далее при рассмотрении практик, применяемых в компании Акселот.
В сентябре 2017 года в свет вышло новое издание самого популярного в
мире стандарта по управлению проектами — PMI PMBoK 6th Edition. Помимо
того, это было первое издание PMBoK, состоящее из двух книг: сам стандарт
PMI PMBoK, а также дополнение к нему Agile Practice Guide. Исходя из
названия дополнения можно сделать вывод, что в этой версии PMBoK
методологии Agile играют ключевую роль. Рассматривая PMBoK как зеркало
основных трендов и законодателя в сфере управлении проектами, мы можем
сделать вывод, что наиболее распространенными методологиями в проектном
управлении на данный момент являются методологии Agile. Все
рассмотренные ниже методологии управления разработкой ПО относится
именно к этой группе.
Но ради справедливости упомянем вначале утратившие в настоящий
момент популярность в разработке ПО каскадные методологии (Waterfall,
Водопад). Данные методологии базируются на каскадной модели, которая
была описана Винтсоном Ройсом в 1970 году в своей статье [29]. В этой же
статье В. Ройс показал, как подобная модель может быть доработана до
итеративной модели. В исходной каскадной модели присутствовали следящие
фазы
1. Определение требований
2. Проектирование
3. Конструирование
4. Воплощение
5. Тестирование и отладка
6. Инсталляция
7. Поддержка
19
Следуя каскадной модели, разработчик переходит от одной стадии к
другой строго последовательно, так как модель подразумевает, что переход от
одной фазы разработки к другой происходит только после полного и
успешного завершения предыдущей фазы, и что переходов назад либо вперёд
либо перекрытия фаз — не происходит. Каскадную модель следует
использовать:
Только тогда, когда требования известны, понятны и
зафиксированы. Противоречивых требований не имеется;
Нет проблем с доступностью программистов нужной
квалификации;
В относительно небольших проектах;
Первый же из трех выше перечисленных пунктов делает указанную
методологию слабо применимой в современном, динамично меняющейся IT
среде. Даже в проектах с качественно проработанным и согласованным ТЗ
регулярно возникают изменение в требованиях. Не зря управление
изменениями рассматривается как одна из важнейших компетенций для
хорошего менеджера проектов.
Перейдем к рассмотрению Agile методологий. Agile — представляет из
себя большое семейство подходов к разработке ПО, базирующихся на
принципах Манифеста Agile [22]. Agile не включает практик, но определяет
ценности и принципы, которыми руководствуются команды разработки.
Манифеста Agile был разработан в феврале 2001 года на встрече на
встрече 17 независимых экспертов по нескольким методикам разработки.
Манифест содержит в себе 4 основные идеи и 12 принципов и не содержит
практических советов [4].
Основные идеи Манифеста:
люди и взаимодействие важнее процессов и инструментов;
20
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий
контракта;
готовность к изменениям важнее следования первоначальному
плану;
При рассмотрении гибких методик начнем с утрачивающих сегодня
популярность день RAD и XP (Экстремальное программирование).
В 2004 году в своей книге «Экстремальное программирование: новые
возможности» Александр Федоренко [14] определил экстремальное
программирование как «… молодая, но быстро развивающаяся методология
разработки программного обеспечения». Методология получила признание и
широкое распространение благодаря ориентации на обычных людей,
максимальному упрощению бюрократических процедур и большому
количеству качественной литературы.
В основе идеи Экстремального программирования лежат четыре
базовых принципа: общение, простота, обратная связь и храбрость.
Экстремальное программирование предлагает готовое решение: делайте все
максимально просто, держите заказчика при себе, позвольте ему активно
следить за процессом разработки, приветствуйте изменения. Фактически
представитель заказчика должен входить в состав команды разработки [3].
Важными приемами для XP являются:
Разработка через тестирование (TDD);
Игра в планирование;
Заказчик всегда рядом;
Парное программирование;
Непрерывная интеграция (CI);
Непрерывный рефакторинг;
Частые небольшие релизы;
21
Простота проектирования;
Коллективное владение кодом;
Стандарт оформления кода;
Достоинствами XP является огромная гибкость, возможность быстро
вносить изменения в ПО на любом этапе его жизненного цикла, отсутствие
необходимости убеждать заказчиков в том, что результат соответствует их
ожиданиям.
Явными недостатками XP являются невозможность выполнения
больших и сложных проектов, невозможность планировать сроки и
трудоемкость на длительную перспективу и четко предсказать результаты
проекта в терминах соотношения качества результата, а так же сложности с
определением затрат времени и ресурсов. Стоит отметить
неприспособленность XP для задач, в которых решения находятся не на основе
ранее полученного (накопленного) опыта, а требуют проведения сложных
исследований. Побочным эффектом применения XP может стать снижение
качества кода, утрате контроля над кодом в случае смены команды разработки.
Именно с этими недостатками XP связан его уход со сцены по мере
возрастания сложности современных IT проектов.
Другой утрачивающей на сегодняшний день популярность методикой
Rapid Application Development (Быстрая разработка приложений, RAD).
RAD — представляет из себя концепцию организации процесса
разработки ПО, ориентированную на максимально быстрое получение
результата в условиях сильных ограничений по срокам и бюджету и при
отсутствии чётко определённых требований к продукту.
RAD появилась в конце 1980х как результат неудовлетворенности
каскадной моделью и набрала большую популярность в 1990х, начале 2000х.
Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-
х годах сформулировал основные принципы RAD, основываясь на идеях