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

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

Бажин Р.В.
выпускник группы MBA CIO-29
Школа IT-менеджмента РАНХиГС при Президенте РФ
ООО «ИнПлат»
Заместитель технического директора
г. Москва

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

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

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

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

Во многих современных предприятиях, занимающихся разработкой программного обеспечения уже используются различные методологии управления проектами. Но, зачастую, они отсутствуют, т.е. проекты идут по принципу - «Как получится», используя свой наработанный опыт, либо внедрены формально (просто - «Чтобы было», или, например, «Как у партнеров/конкурентов») - поэтому не приносят ожидаемого эффекта. В других случаях, внедряются правильно подобранные методологии, но со временем меняются многие факторы, влияющие на отдачу от используемой методологии, и положительный эффект значительно снижается, либо уже отсутствует.

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

Для достижения данной цели приходится решать следующие задачи:

• выявление существующих методологий управления проектами;
• выявление факторов, которые влияют на эффективность использования той или иной методологии;
• выявление наличия и состояния факторов конкретного предприятия, специализирующегося на разработке программного обеспечения, которые могут повлиять на выбор методологии управления проектами;
• выбор методологии управления проектами по разработке ПО;
• адаптация и внедрение выбранной методологии управления проектами в компании.

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

Существует два вида/уровня того, что называют стандартами/методологиями/техниками управления проектами:

• Project Management Processes – Процессы управления проектом
• Project Life Cycle – Жизненный цикл проекта

К Процессам управления проектом относятся стандарты, подходящие для любого проекта, из любой отрасли – они описывают подход в целом к управлению проектами. Обычно содержат список высокоуровневых процессов, техник и артефактов которые желательны на проекте. К данному виду стандартов относятся PMI PMBOK, IPMA ICB, PRINCE2, SWEBOK, ГОСТ Р и ряд других менее известных.

К жизненному циклу проекта относятся стандарты, определяющие конкретные фазы проекта, конкретные взаимосвязи между фазами, конкретные шаблоны артефактов, конкретные процессы, с рекомендациями по их постановке. Понятно, что четкие рекомендации могут быть даны только для конкретной отрасли. В отрасли разработки ПО к данному виду стандартов относятся: Waterfall; Agile и его разновидности: SCRUM, Lean, Kanban, XP,..; MSF, RUP и другие.

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

• как эталон (желаемое состояние организации процессов, выполнения работ) «эффективная методология – серебряная пуля»;
• для обоснования существующей практики управления проектами, как доказательство (обоснование) правильности принятых решений;
• как руководство по достижению целей «методология»;
• как набор требований (ограничений), предъявляемых внешней средой: клиентами, партнерами, собственниками, государственными организациями, профессиональными объединениями - «стандарт».
• для объяснения (понимания) существующей практики: используется терминология, концепции, идеи - «модель».
• для обеспечения «эффективного» диалога между менеджментом, участниками проектных команд, клиентами и субподрядчиками «глоссарий».
• для нахождения (смены) фокуса – центра приложения управленческих усилий, инвестиций в методологии.

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

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

По характеру обоснования рекомендаций: концептуальные (модели получены рационально-логическим методом, в основе которых концепции теории менеджмента, например: CMM, PRINCE, RUP) и эмпирические (разработанные на основе теоретического обобщения успешных практик ИТ-проектов, например: SCRUM, XP, Crystal).

В зависимости от назначения: модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики. Модель зрелости CMMI, модель оценки процессов SPICE и стандарт ISO 9000 используются для управления ИТ-компанией (подразделением). Проектные методологии: MSF, SCRUM, XP, используются для управления ИТ-проектами разработки ПО. Методологии внедрения информационных систем используются для организации проекта внедрения. Групповые и индивидуальные практики (Personal Software process; Team Software process) служат для непрерывного повышения эффективности работы команд и разработчиков.

По характеру знаний и фокусу: инженерные, управленческие и интегрированные.

В зависимости от цели использования, истории создания и назначения.

В зависимости от решаемой задачи: методологии разработки ПО и методологии внедрения информационных систем.

В зависимости от используемой в ней модели жизненного цикла: водопадные (каскадные) и итеративные методологии.

К существующей классификации в зависимости от используемой в ней модели жизненного цикла добавилась более общая классификация в зависимости от условий реализации проекта: прогнозируемые и адаптивные.

В зависимости от уровня формализма.

Анализ факторов, влияющих на выбор той или иной методологии, а также процесс её внедрения рассмотрим примере компании разрабатывающей программно-аппаратные комплексы для государственных органов.
В процессе исследования компании выявлены следующие важные для нас факторы:

• проекты заказчиков компании имеют строгие ограничения по времени исполнения, внедрения, стоимости и набору требований;
• к заказу может прилагаться верхнеуровневый план проекта и архитектуры;
• длительность проектов обычно составляет – от двух лет;
• практически никогда компания не возвращается к завершенным проектам, не дорабатывает их:
• одним, из главных факторов, влияющих на ведение проектов, являются периодические демонстрации заказчикам очередного этапа разработки, где демонстрируется весь новый функционал (частота демонстраций может варьироваться от 2 недель до 1,5 месяцев);
• персонал в компании работает обычно многие годы, ротация кадров не велика, поэтому почти все сотрудники глубоко погружены в сферу деятельности;
• уровень квалификации персонала – выше среднего;
• эмоциональная атмосфера в Центре РПО можно назвать несколько напряженной, а отношения между сотрудниками – рабочими;
• загруженность сотрудников центра, в среднем, составляет 70%, отставание от сроков реализации по проектам составляет 2-6 недель;
• методология разработки - «как получится…»;
• ключевой фактор – руководитель ИТ, обладающий авторитарным стилем руководства с некоторыми демократическими элементами;
• предприятие отнести к функциональному типу организации.

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

Рассмотрим какие методологии больше подходят для нашего выбора, через призму классификации инструментальных средств управления разработкой ПО:

• в зависимости от характера обоснования рекомендаций – отнесение методологии к концептуальной или эмпирической должно оказать влияние на наш выбор;
• в зависимости от назначения (модели зрелости и процессные модели, проектные методологии и индивидуальные и групповые практики) - проектные методологии (MSF, SCRUM, XP,…), которые используются для управления ИТ-проектами разработки программного обеспечения;
• в зависимости от цели использования, истории создания и назначения - группа методологии, целью которых является успешное выполнение отдельного проекта. К этой группе относится большинство проектных методологий, и практически все адаптивные методологии. Логика успешного функционирования организации выглядит как рост компетенций, создание технических активов за счет последовательного выполнения успешных проектов. Нашей целью является успешное выполнение отдельного проекта, а не обеспечение устойчивого функционирование всей компании;
• в зависимости от используемой модели жизненного цикла (водопадные (каскадные) или итеративные методологии) – постоянное выявление новых и изменения существующих требований и ограничений (практически, рабочий день ИТ директора состоит из череды совещаний со своими подчиненными, непосредственными исполнителями, реализующими требования по продукту, где обсуждаются новые требования, изменения в старых, а так же их практическая реализация) склоняет нас к выбору итеративной методологии. Однако, существует этап в начале каждого проекта, на котором необходимо определиться с общей концепцией, архитектурой и верхнеуровневым расписанием проекта, который необходимо закончить до начала практической реализации задуманного – это уже является элементом водопадных методологий;
• в зависимости от условий реализации проекта (прогнозируемые и адаптивные) – больше подходят методологии, планы проектов (сроки этапов), которых могут меняться со временем из-за изменяемости требований, а так же графиков демонстраций новой функциональности. Однако, если к проекту заказчик предъявляет требование – согласовать в начале проекта основные этапы проекта, то должны присутствовать элементы прогнозируемых методологий;
• в зависимости от уровня формализма (документирования) – реалии существующих проектов таковы, что, с одной стороны, для собственных нужд не требуется большой формализации, т.к. проекты не находятся далее на сопровождении у Компании А, т.е., фактически документация нужна только на время жизни проекта в компании. С другой стороны, заказчикам продукты должны сдаваться полностью документированными.

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

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

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

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

Список использованных источников

• Алферов П.А. Курс «Управление проектами». Презентация, 2011, 153 с.
• Друкер П. Ф. Практика менеджмента. Пер. с англ.: - М.: Издательский дом «Вильямс», 2001. – 398 с.
• Йордон. Э. Управление сложными интернет-проектами. - М.: «Лори», 2003. - 344 с.
• Колтунова Е.В. Выбор методов моделей и стандартов управления разработкой программного обеспечения. Диссертационное исследование. - СПб., 2000-2007. 184с.
• Турин К., 2011 г. http://trunin.com/2011/02/chto-luchshe-pmbok-ili-agile-process.html
• Griffiths M. http://www.pmtoday.ru/project-management/risks/top-five-risks.html
• Lucas H. Information Technology: Strategic Decision Making for Managers: Wiley, 2005. - 446 с.
• http://www.agilemanifesto.org