Управление проектами в разработке программного обеспечения: ответы на ключевые вопросы
26 октября 2022 г.Вы начинаете заниматься разработкой программного обеспечения. У вас есть перспективная идея, подробные требования, достаточный уровень технических знаний и опытная команда. Вам не хватает только опытного руководителя проекта. С учетом вышеизложенного, каковы шансы, что вы завершите проект?
Печальная правда заключается в том, что шансы на успех не так высоки. Различные исследования показывают, что основные причины неудач при разработке программного обеспечения в основном связаны с плохим управлением проектами.
Распространенными ошибками в управлении проектами разработки программного обеспечения, которые приводят к их провалу, являются изменение целей проекта, неадекватная коммуникация, плохое управление изменениями, неточная оценка затрат, невыявленные риски и другие.
Поэтому, чтобы ваш проект не вышел из-под контроля, вы должны сделать здоровое управление проектом своим приоритетом. Ниже мы делимся нашим опытом в разработке корпоративных программных решений, отвечая на острые вопросы об управлении проектами разработки программного обеспечения.
Насколько важно управление проектом для успеха проекта разработки программного обеспечения?
Скоро, очень.
Проекты по разработке программного обеспечения, как правило, очень сложны. Чтобы проект считался успешным, он должен соответствовать требованиям и гарантировать высокое качество исполнения, а также быть выполненным вовремя и в рамках бюджета. Именно за это отвечает руководитель проекта.
Таким образом, преимущества найма преданных своему делу специалистов для управления проектами разработки программного обеспечения заключаются в следующем:
- Сниженные риски
Руководитель проекта отвечает за эффективное управление рисками. В самом начале проекта они намечают, документируют и расставляют приоритеты потенциальных рисков, а также разрабатывают стратегию реагирования на риски.
Четыре распространенных способа реагирования на риски охватывают:
* Избегать: устранить угрозу или отказаться от нее. * Смягчить: уменьшить вероятность или влияние угрозы. * Передача: назначить или передать угрозу третьему лицу. * Принять: признать наличие угрозы и отказаться от ее устранения, передачи или смягчения.
Чтобы разработать подходящую стратегию реагирования на риски, руководитель проекта может организовать сеансы мозгового штурма с командой, прибегнуть к раскадровке или взять интервью у сотрудников всех подразделений. Имея под рукой стратегию управления рисками, команде проекта становится легче предвидеть риски и своевременно их предотвращать.
* Улучшенный контроль над затратами по проекту
При управлении проектами разработки программного обеспечения часто случаются перерасходы средств. Поскольку они не только влияют на маржу, но и мешают реализации проекта, опытный менеджер предлагает оптимальный подход к управлению затратами.
Они оценивают, составляют бюджет и контролируют расходы на протяжении всего жизненного цикла проекта, чтобы удерживать расходы в рамках утвержденного объема. Грамотное управление затратами также помогает формировать ожидания заинтересованных сторон, контролировать расползание масштаба, повышать рентабельность проекта и отслеживать долгосрочные тенденции затрат. * Оптимальное использование ресурсов
Здоровое управление проектами в разработке программного обеспечения помогает обеспечить координацию и эффективное использование всех ресурсов проекта, включая людей, их навыки, время, инструменты, оборудование и услуги.
На этапе проекта проектный менеджер оценивает выделение и планирует необходимые ресурсы, а также распределяет их в соответствии с приоритетами. Во время разработки PM отслеживает использование ресурсов и устраняет любые узкие места, которые могут помешать завершению проекта. * Улучшенный контроль над объемом проекта
Распространенной проблемы при управлении проектами разработки программного обеспечения лучше избегать. Неконтролируемые изменения влияют на график проекта, бюджет, затраты и распределение ресурсов, а также ставят под угрозу достижение контрольных точек.
Подходя к управлению проектами в разработке программного обеспечения, проектировщик устанавливает процедуру запроса на изменение и следит за тем, чтобы она выполнялась для каждого нового требования. Цель состоит в том, чтобы избежать неконтролируемого расширения масштабов и обеспечить выполнение проекта вовремя и в рамках бюджета. После того как новое действие будет одобрено и добавлено в область действия, сроки проекта и базовые планы бюджета обновятся соответствующим образом.
Что такое управление проектами в разработке программного обеспечения?
Управление проектами в разработке программного обеспечения – это искусство планирования, составления графиков и отслеживания действий по проекту с учетом доступных ресурсов и ограничений.
<цитата>Как сказано выше, проекты по разработке программного обеспечения довольно сложны и включают несколько этапов. Менеджер проекта планирует и контролирует выполнение проекта на всех этапах.
По данным Института управления проектами, существует пять ключевых этапов жизненный цикл разработки программного обеспечения с точки зрения менеджера по проектам.
* Концепция проекта
Ключевая цель стадии концепции проекта — определить основные цели проекта, определить бизнес-потребности и подготовить техническое задание. Последние должны включать, прежде всего, требования к будущему решению и график реализации проекта. Концепция проекта обычно требует тесного сотрудничества между всеми заинтересованными сторонами проекта, при этом бизнес-аналитик и менеджер проекта берут на себя ведущую роль. * Планирование проекта
Этап планирования проекта — это совместная работа руководителя проекта и проектной группы. Команда проекта разрабатывает техническую архитектуру решения и придумывает его внешний вид. PM, в свою очередь, разрабатывает план проекта, создает структуру разбивки работ и готовит график проекта. Конечная цель этапа — получить четкое представление о масштабах проекта и заложить основу для мониторинга и контроля исполнения проекта.
На этом этапе PM также настраивает инструменты связи и отслеживания прогресса, а также планирует будущие развертывания, определяя критерии приемлемости. * Запуск и реализация проекта
Пока проектная группа занимается проектированием и тестированием будущего решения, руководитель проекта следит за работой команды, устраняет узкие места, которые могут помешать работе над проектом, облегчает общение между членами команды и заинтересованными сторонами проекта, документирует ход проекта, отслеживает триггеры риска. и отчитывается перед клиентом или высшим руководством. * Принятие проекта
На этапе приемки проекта решение или набор результатов развертываются в тестовой среде, где проводится бета-тестирование. Команда разработчиков предоставляет необходимых лис при необходимости. PM следит за тем, чтобы решение было доставлено полностью и вовремя, а также гарантирует, что поставленное программное обеспечение соответствует согласованным критериям приемки. Другая часть управления проектами в разработке программного обеспечения на этапе приемки проекта связана с подготовкой руководств пользователя, инструкций по установке и другой проектной документации. * Завершение проекта
После завершения проекта менеджер проекта проводит ретроспективный обзор, в ходе которого оценивает и документирует взлеты и падения всего проекта. Они также обеспечивают передачу полного объема результатов клиенту/владельцу продукта, включая весь исходный код, документацию по программному обеспечению, среду разработки и многое другое.
Эти основные этапы могут следовать друг за другом линейно или допускать большее перекрытие — в зависимости от выбранного подхода к управлению проектами разработки программного обеспечения.
Управление проектами в разработке программного обеспечения: популярные методологии
Наиболее широко используемые методологии управления программными проектами включают Scrum, Kanban (обе относятся к семейству Agile) и Waterfall.
Другие, менее популярные подходы к управлению проектами в области разработки программного обеспечения: пошаговая модель разработки, спиральная модель, PRINCE2 и Rational Unified Process (RUP).
Скрам
Скрам — один из самых популярных подходов к управлению проектами в разработке программного обеспечения. Он разбивает процесс разработки на этапы продолжительностью от двух до четырех недель каждый. Спринтам обычно предшествует тщательное планирование. Хорошо подходящий для проектов с высоким уровнем неопределенности, Scrum опирается на кросс-функциональные, самоорганизующиеся команды и поддерживает идею поэтапной разработки, основанной на наблюдениях и экспериментах.
Управление проектами на основе Scrum в разработке программного обеспечения немного отличается от традиционного управления тем, что в нем нет PM как такового. Вместо этого обязанности одного из них распределяются между владельцем продукта и скрам-мастером.
Канбан
Особенность Канбана в том, что в нем нет явно заданных итераций. Это бережливый подход к управлению проектами разработки программного обеспечения, который помогает визуализировать объем проекта, ограничивать незавершенные работы и обеспечивать бесперебойный поток работ. В методологии используются физические или цифровые доски канбан, которые представляют собой уникальный рабочий процесс команды.
Благодаря своему характеру модель хорошо подходит для проектов поддержки и обслуживания. Еще одна особенность Канбана — ограничение объема незавершенной работы. Методология направлена на балансировку масштабов и ресурсов. Задачи извлекаются, когда позволяют доступные ресурсы, а не вводятся в процесс по запросу.
Обязанности по управлению проектом разработки программного обеспечения обычно распределяются между двумя ролями, важными для Канбана: менеджером по предоставлению услуг и менеджером по запросам на услуги. Первый отвечает за повышение эффективности рабочих процессов, а второй в основном занимается интерпретацией потребностей и ожиданий клиента.
Однако нет необходимости нанимать дополнительных членов команды, чтобы соответствовать правилам Канбана. На самом деле опытный менеджер по управлению проектами обычно хорошо подходит для обеих ролей.
Водопад
В отличие от семейства Agile, управление проектами на основе Waterfall разбивает проект на отдельные последовательные этапы.
Традиционно новый этап начинается после полного завершения предыдущего. Однако современные проекты Waterfall допускают некоторую степень дублирования. Например, команда тестировщиков нередко начинает проверять отдельные функции еще во время разработки.
Водопадный подход к управлению проектами разработки программного обеспечения хорошо подходит для проектов с предсказуемым объемом, однако он может оставить команды разработчиков врасплох и неспособными приспосабливаться быстрее, чем конкуренты.
Поскольку в Waterfall и Agile есть свои особенности управления проектами, давайте углубимся в ключевые отличия.
В чем разница между Waterfall и Agile-управлением проектами?
А теперь давайте более подробно рассмотрим, чем отличаются методы управления в проектах Waterfall и Agile. Мы сравниваем их, поскольку они более распространены, чем другие методологии управления проектами, и в них есть существенные различия в том, как организована проектная работа. Последнее влияет на роль и обязанности менеджера проекта (или соответствующую роль в Agile).
Планирование проекта
В Waterfall невозможно двигаться вперед, не понимая, что вы строите и зачем. Вот почему составление исчерпывающей спецификации требований к программному обеспечению является приоритет номер один в проектах Waterfall. Обычно SRS пишет бизнес-аналитик. Но при его отсутствии его может взять на себя руководитель проекта.
Agile, с другой стороны, обеспечивает большую гибкость. Внедрение улучшений продуктов и процессов на ходу — суть методологий Agile. Действия по планированию обычно выполняются за один спринт заранее. Бэклог создается во время так называемого нулевого спринта.
Во время нулевого спринта команда придумывает минимальное количество пользовательских историй, чтобы превратить их в работающий продукт, и, при необходимости, настраивает инфраструктуру для разработки. Спринт обычно остается легким и высокоуровневым.
Управление содержанием проекта и бюджетирование
В Waterfall объем решения должен оставаться неизменным во всех проектах. Запросы на изменение обрабатываются с помощью процедуры управления изменениями и оплачиваются отдельно. Управление проектами в Agile-разработке программного обеспечения обеспечивает большую гибкость с точки зрения управления содержанием, но затрудняет оценку влияния изменений содержания на конечную стоимость программного обеспечения. Это влияет на подход к составлению бюджета проекта.
В Waterfall бюджетирование осуществляется сверху вниз, контролируется и основывается на подробном экономическом обосновании. Такой подход позволяет дать реалистичную оценку стоимости после выявления и анализа требований. Основным недостатком является то, что этот подход не работает в изменчивых, неопределенных и неоднозначных средах, которыми часто являются проекты по разработке программного обеспечения.
Agile-способ управления затратами на проекты по разработке программного обеспечения быстро реагирует на изменения. И это одновременно и преимущество, и сложность. Гибкое бюджетирование соответствует структуре и графику проекта. А поскольку он также следует структуре спринта, команде легче приспосабливаться к меняющимся обстоятельствам, не затрагивая при этом весь бюджет проекта. Менеджер проекта просто пересчитывает расходы в следующем раунде планирования.
Результаты проекта
Выбирая метод Agile, компании получают прибавку к новой функциональности или какой-либо другой результат — будь то техническое видение, работающая функция или MVP — после каждой итерации.
С другой стороны, в классическом Waterfall клиент не получает последовательного рабочего решения до конца проекта. Полномасштабное тестирование также проводится позже в процессе разработки, что может повлиять на время выхода на рынок.
Документация проекта
Согласно Waterfall, правильное документированное планирование является обязательным условием управления проектами разработки программного обеспечения. Требования к проекту должны быть ясны заранее, и каждый член команды должен знать о них. Каждый член команды также должен понимать, какова его роль в проекте и что от него ожидается. Эта информация также обычно документируется и распространяется среди проектной группы.
Команды водопада часто обращаются к документации на протяжении всего процесса разработки, чтобы упростить отслеживание прогресса. И это единственный способ сделать это — учитывая длину и сложность проектов, которые обычно управляются в соответствии с Waterfall. Документация ведется на каждом этапе, что позволяет всем быть в курсе хода проекта, несмотря на последовательный характер модели.
Хотя обширная документация служит снижению рисков в Waterfall, она снижает адаптируемость к изменениям в Agile. Поэтому в Agile-проектах принято создавать меньше документации. И если он производится, документы остаются краткими.
Но, несмотря на распространенное заблуждение, в методологии Agile нет ничего, что по своей сути мешало бы командам создавать столько документации, сколько им нужно. Некоторые документы действительно необходимы.
Добавление пользовательских историй в бэклог, составление макетов и документирование встреч с клиентами являются обязательными. Что предлагает Agile, так это более разумно подходить к процессу документирования и избегать слишком длинной документации.
Какие обязанности у менеджера проекта?
Обязанности руководителя проекта также различаются в зависимости от подхода к управлению проектом разработки программного обеспечения. Давайте посмотрим, что конкретно делает PM или соответствующая Agile-роль на каждом этапе проекта.
В водопаде
Руководитель проекта — самая важная роль в каждой команде Waterfall. Они несут ответственность за качество результатов и выполнение проекта в срок. В их основные обязанности входит надзор за проектной деятельностью и назначение задач членам команды.
Давайте теперь разобьем объем работы PM на этапы.
| Планирование | -Понимание требований и потребностей клиентов -Установление целей проекта -Определение ожиданий заинтересованных сторон -Определение ресурсов, необходимых для выполнения проекта | |----|----| | Дизайн | -Определение и перечисление конкретных задач -Создание рабочего процесса проекта и расписания | | Внедрение и тестирование | - Делегирование конкретных задач членам команды - Отслеживание хода проекта - Выявление потенциальных препятствий и узких мест - Отчетность о прогрессе перед заинтересованными сторонами - Отслеживание хода тестирования и мониторинг качества решения | | Развертывание | -Представление завершенного проекта заинтересованным сторонам-Управление документами-Оценка проекта | | Техническое обслуживание | - Установление ожиданий обслуживания - Отслеживание прогресса в достижении целей обслуживания в течение установленного периода времени |
В Agile
Менеджер Agile-проекта устанавливает приоритеты элементов невыполненной работы для каждого спринта, отслеживает ход разработки и налаживает эффективную коммуникацию внутри команды, а также между командой и заинтересованными сторонами. Они также отслеживают риски на каждом этапе проекта и следят за тем, чтобы процесс разработки соответствовал принципам Agile.
Вот что конкретно делает руководитель проекта на каждом этапе Agile-проекта:
| Концепция | -Определение масштаба проекта в сотрудничестве с клиентом и владельцем продукта -Определение требований к будущему решению (как правило, в форме пользовательских историй) -Предложение оценки времени и стоимости | |----|----| | Начало | -Оценка ресурсов -Сбор команды разработчиков -Наблюдение за ходом разработки решения -Сбор информации от заинтересованных сторон и включение этой информации в разработку решения | | Итерация | -Управление бэклогом -Приоритизация пользовательских историй для реализации в каждой итерации -Мониторинг хода проекта -Управление запросами на изменение -Постоянная обратная связь от клиента -Мониторинг рисков и узких мест | | Релиз | -Контроль качества результатов -Определение и документирование потребностей в обучении пользователей -Принятие результата клиентом -Наблюдение за выпуском | | Техническое обслуживание | -Определение потребностей в обслуживании - Приоритизация запросов на обслуживание - Предложение дополнительного обучения конечным пользователям - Планирование обновлений и дополнительных функций |
На какие подводные камни должен обратить внимание руководитель проекта?
Ключом к успеху в управлении проектами разработки программного обеспечения является способность предотвращать и предотвращать риски. Распространенные ловушки, на которые следует обратить внимание хорошему менеджеру по управлению:
Отсутствие контроля над областью действия
Особенно в Agile клиенты часто запрашивают дополнительные функции на ходу, из-за чего проекты часто идут наперекосяк. Таким образом, руководитель проекта должен внедрить четкую процедуру управления изменениями, чтобы предотвратить расширение масштабов. Им также необходимо убедиться, что все заинтересованные стороны понимают, как изменения повлияют на сроки и ресурсы проекта.
Не сосредотачиваться на соблюдении срока поставки
Разработка продукта со строгими требованиями к времени выхода на рынок, например образовательного приложения, которое необходимо выпустить до начала учебного года, или розничного приложения, которое необходимо развернуть к рождественским распродажам, PM должен найти правильный баланс между соблюдением сроков и обеспечением высокого качества.
Им необходимо приложить дополнительные усилия для определения приоритетов функций и установления сроков реализации каждой функции. Требования к качеству также должны быть определены заранее, чтобы избежать проблем, возникающих после внедрения.
Не удалось установить эффективную коммуникацию
Эффективное управление проектами в области разработки программного обеспечения требует эффективной и прозрачной коммуникации. Его создание является ключевой обязанностью премьер-министра. Им необходимо информировать команду о решениях заинтересованных сторон и регулярно информировать заинтересованные стороны обо всех действиях проекта, узких местах и проблемах.
Не удалось установить четкие процессы
Следование за процессом разработки программного обеспечения может показаться членам команды бременем. Тем не менее, необходимо настроить четкий рабочий процесс, адаптированный к специфике проекта. Это поможет структурировать работу и прояснить ожидания.
Опираясь на незнакомую технологию
Руководителю проекта необходимо следить за тем, чтобы при выборе технологии команда инженеров сосредоточилась на решении бизнес-проблемы клиента. Им также необходимо убедиться, что выбранный набор технологий соответствует передовым инженерным практикам.
Еще одна ловушка, связанная с технологиями, — отсутствие планирования масштабируемости на ранних этапах разработки продукта. Поэтому мы рекомендуем заранее определить требования к масштабируемости наряду с другими нефункциональными требованиями.
Не продумать процесс развертывания заранее
Процесс развертывания часто упускается из виду на ранних этапах разработки, что приводит к серьезным задержкам во время развертывания. Для эффективного управления проектами в области разработки программного обеспечения менеджер по программному обеспечению должен гарантировать, что вопросы развертывания и установки будут продуманы на ранних этапах процесса разработки.
Как подойти к управлению проектами в разработке программного обеспечения: точка зрения ITRex
Мы встретились с Александром Белкавцем, ведущим менеджером по управлению проектами в ITRex, и взяли у него интервью о том, как мы в ITRex подходим к управлению проектами по программному обеспечению. Вот что мы узнали.
На какие факторы вы полагаетесь при выборе подходящей модели управления проектами для наших клиентов?
Александр: На выбор того или иного подхода к управлению проектами влияет множество факторов. Наиболее важными из них являются масштаб проекта, бюджет и время выхода на рынок.
Если мы работаем над продуктом, который необходимо регулярно обновлять, чтобы постоянно приносить пользу конечным пользователям, скажем, над игровым приложением, мы, естественно, выберем Scrum или аналогичный Scrum подход.
Если, с другой стороны, мы работаем над программным решением по заказу государственного учреждения, что обычно означает фиксированный бюджет, мы бы предпочли подход, подобный водопаду, чтобы обеспечить необходимую предсказуемость. Однако нередко фазу разработки делят на более мелкие итерации. Поэтому мы часто прибегаем к гибридному подходу, который позволяет нам извлечь выгоду из предсказуемости Waterfall и непрерывного улучшения Agile и скорости доставки.
Влияют ли какие-либо другие факторы на выбор методологии управления проектами?
Александр: Конечно. Отрасль, в которой будет использоваться будущее решение, потребности в сертификации, готовность клиента участвовать в процессе и многие другие факторы также влияют на проект.
Например, при разработке решений для здравоохранения часто выбирают Waterfall. В США, прежде чем продавать, скажем, новое медицинское устройство, оно должно быть одобрено FDA; и для этого требуется обширная документация, которую невозможно обеспечить в соответствии с Agile.
В чем конкретно заключается ваша роль руководителя проекта? Какова ваша основная цель в управлении проектами наших клиентов?
Александр: Я смотрю на свою роль руководителя проекта с двух точек зрения.
Первый: управление проектом — это управление рисками. Проекты по разработке программного обеспечения подвержены многим рискам — от изначально ошибочных требований до неадекватного выбора источников, меняющегося технологического ландшафта и так далее. Основная цель менеджера проекта в этом отношении — свести к минимуму влияние рисков на проект и, таким образом, максимально увеличить вероятность успешной поставки программного обеспечения.
Вторая точка зрения: управление проектом становится своего рода интегратором, позволяющим гармонично объединить многие подсистемы проекта, такие как разработка, тестирование и развертывание. Основная цель менеджера по управлению проектами — организовать все процессы в рамках проекта таким образом, чтобы минимизировать риски и обеспечить максимальное использование ресурсов.
Можете ли вы вспомнить проект, в котором выбранный подход к управлению проектом оказался решающим фактором в обеспечении успеха продукта?
Александр: Мы разрабатывали мобильное приложение для нашего клиента и начали проект со Scrum. Как только мы выпустили первую версию приложения и получили первые метрики продукта, мы решили перейти на Канбан.
Чтобы удержать первых пользователей, нам нужно было продолжать регулярно добавлять новые функции, хотя необходимость в двухнедельных спринтах отпала. Канбан позволил нам адаптировать продолжительность спринта к сложности новых функций, со средним спринтом в три-четыре недели, поэтому мы продолжали темп поставки, не подвергая команду разработчиков дополнительному давлению. В результате нашему клиенту удалось удержать и привлечь новых пользователей.
Поскольку Agile-команды позиционируются как самоуправляемые, возникает соблазн поверить в то, что проект может быть выполнен и без специального менеджера проекта. Так ли это?
Александр: Если нет отдельного менеджера по проектам, обязанности одного из них придется распределить по всем членам команды. Придется по-прежнему уделять время расстановке приоритетов в бэклоге, закупке ресурсов, составлению отчетов и выполнению других важных управленческих задач. Но в отсутствие продакт-менеджера эти задачи будут делегированы людям без специальных знаний. Это не способствует максимальному использованию талантов.
Подход без PM может сработать для небольшой команды из 3–4 человек, но когда это число становится больше, наличие выделенного менеджера проекта становится жизненно важным.
Если у вас все еще остались вопросы об управлении проектами разработки программного обеспечения, или вы хотите передать ответственность за руководство вашим проектом опытному партнеру, свяжитесь с ITRex< /а>.
Также опубликовано здесь.
Оригинал