{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Подходы к разработке проектов

Приветствую! Сегодня я, Дмитрий Балашов, руководитель проектного отдела компании Decart IT, расскажу про подходы к разработке, лежащие на более фундаментальном уровне, чем методологии, которым уже посвящено множество статей.

За основу возьму PMBoK - библию в мире проектного менеджмента от американского Института проектного менеджмента(PMI), а конкретно последнее седьмое издание, учитывающее изменения ковидной эпохи. Статья будет полезна всем, кто работает с проектами, не обязательно в IT.

Подходы к разработке

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

Для предиктивного подхода характерны следующие свойства:

  • Требования поддаются сбору и анализу в начале проекта
  • Глубокое планирование проекта
  • Содержание, расписание, стоимость, ресурсы и риски определяются на ранних стадиях жизненного цикла и относительно стабильны
  • Низкий уровень неопределенности

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

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

На другом краю спектра расположился адаптивный подход, для которого справедливы:

  • Высокий уровень неопределенности требований
  • Высокая вероятность изменения требований на протяжении проекта
  • Реакция на обратную связь и непредвиденные события
  • Итеративная или инкрементная поставка
  • Сильная вовлеченность команды в планирование
  • Размытые бюджет и дедлайн

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

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

Адаптивный подход делает упор на непрерывное улучшение процессов и получение опыта командой для увеличения ценности поставляемого результата.

Гибридный подход представляет собой сочетание предиктивного и адаптивного, Например, в ходе IT-проекта требования и дизайн могут разрабатываться адаптивно, а разработка и развертывание - предиктивно.

Что влияет на выбор подхода

  • Степень инновации. Если команда уже выполняла аналогичные задачи, а работы допускают заблаговременное планирование, подойдет предиктивный подход. Если же проект представляет собой исследование, в приоритете будет адаптивный подход.
  • Определенность требований. Если требования хорошо известны и вероятность изменений мала, выбирайте предиктивный подход. Если высоки неопределенность, изменчивость или сложность, используйте адаптивный.
  • Варианты поставки. Если возможна поэтапная поставка, каждый этап которой будет приносить ценность, выбирайте адаптивный подход. Если ценность имеет только финальный результат проекта, ваш выбор - предиктивность.
  • Риск. Высокорискованные проекты могут требовать поэтапной адаптивной работы для эффективного управления. При небольших рисках или возможности их нейтрализовать заранее, подойдет предиктивный подход.
  • Требования к безопасности. Наличие строгих требований к безопасности почти всегда требует предиктивного подхода.
  • Нормативные акты. Проекты с сильным регуляторным надзором также требуют предиктивного подхода. к ним относится абсолютное большинство госпроектов.
  • Ограничения расписания. Если есть необходимость в ранней поставке даже сырого продукта, подойдет адаптивный подход. Если же критичен запуск всего функционала к определенной дате, например, мероприятию, остановитесь на предиктивном.
  • Финансирование. При неопределенном финансировании лучше подойдет адаптивный итеративный подход. Если же финансирование строго определено, эффективнее будет предиктивный подход.
  • Организационная структура. Предиктивный подход необходим при высоком уровне бюрократии, иначе могут быть простои команды. Если же есть возможность быстро принимать решения, подумайте об адаптивном подходе.
  • Размер команды. Гибкие методологии хорошо показывают себя для команд в 5-9 человек, которые находятся в одном физическом пространстве. Крупным командам лучше отдать предпочтение предиктивным методологиям.

Еще пара советов

Из своего опыта выделю еще пару практических советов.

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

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

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

Выводы

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

0
6 комментариев
Написать комментарий...
Алексей Пугачевич

Спасибо за статью, живо и интересно, прочитал с удовольствием)

Ответить
Развернуть ветку
Илья Ланкевич

Эх, вот за это я не люблю PMBoK.
Правда, на с. 236 указано 4 подхода.
Но тут важно другое, PMBoK задумывался как стандарт. Товарищи не выдержали жёсткой теоретической дискуссии с другими товарищами и согласились на guide.
Изначально PMBoK создавался на основе ОДНОГО подхода — waterfall. Который теперь криво называют «predictive». Хотя и то, и другое — stage-gate или state-transition.:)
Но времена требуют перемен, а товарищи не хотят отказываться от своих завоеваний — количества действительных сертификатов. Поэтому agile они как бы не замечают.
Но другие не такие:
https://uwaterloo.ca/ist-project-management-office/sites/ca.ist-project-management-office/files/styles/body-500px-wide/public/uploads/images/agile_systemsdevelopmentapproaches.jpg?itok=q0uFcYe4

Ответить
Развернуть ветку
Dmitry Balashov
Автор

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

Ответить
Развернуть ветку
Илья Ланкевич

Я не буду спорить, какой подход правильный для той или иной сферы. Имхо, само обобщение с попыткой классификации подходов несколько бесполезна.
Я несколько раз наблюдал agile в больших и маленьких ИТ проектах и был разочарован — инкрементальные улучшения с потерей концепции (целостности). Д.б. мне просто не повезло.
Наблюдал как буксует waterfall в госкорпорации, как тяжело даются незначительные изменения и как это приводит к убийственному увеличению сроков проекта.
О практике проектного управления в российском (очень крупном) строительстве совсем не хочется говорить, одна злость осталась.
Осознание подхода может помочь РПшнику проверить характерные риски и м.б. отказаться (или наоборот принять) некоторые методики, практики, например, то же директивное расписание и критпуть в agile или scrum в waterfall.
Как-то так…

Ответить
Развернуть ветку
Dmitry Balashov
Автор

Спасибо, очень рад!

Ответить
Развернуть ветку
Алексей Блх

Спасибо, помогли разобраться от чего зависит выбор подхода разработки.

Ответить
Развернуть ветку
3 комментария
Раскрывать всегда