Рассказываем о сочетании проектных методологий в софтовых проектах
Любой взгляд на проектное управление всегда субъективен. В этом тексте мы попытались отразить наше видение на управленческие методики в разработке, основанное на опыте нашей компании в реализации сложных проектов для клиентов разных сфер, бюджетов и структуры.
Методологий много - хорошо ли это?
Мир многогранен! И в разработке существует большое количество методологий управления проектам, но Им все мало, периодически появляются все новые и новые. При этом, даже специалист не всегда может различить нюансы. Что уж говорить о рядовых исполнителях :) Вам с пеной у рта будут доказывать, что скрам – это не канбан, аджайл – вовсе не методология, а путать ватерфол с V-моделью – верх непрофессионализма. Отчасти эти люди будут правы, так как у каждой школы есть свои уникальные особенности, а некоторые - имеют принципиальные различия. Однако, стоит учесть, что публикации новых методов управления проектами часто преследует цель популяризации автора и не всегда несет реальную смысловую ценность. Кроме того, внедрение новых, актуальных фреймворков стало модным среди топ-менеджмента российских компаний. Хотя, нередко речь идет только об использовании хайповых словечек, без каких-либо изменений принципов работы.
При этом, в практике реальных проектов основных методологий – две.
Можно использовать разные термины, но условно назовем их Классическая (Waterfall во всех проявлениях) и Гибкая (все итеративные методы). Главное различие кроется в подходе к процессу достижения конечного результата. В проектах, где он формализован и неизменен, обычно есть артефакт, фиксирующий и описывающий, каким этот результат должен быть - техническое задание, требования к функционалу, тех. проект и прочее. Это классика. Во всех остальных случаях – когда требования сложно формализовать и ориентирами зачастую служат метрики, клиентские пути и другие критерии, требуется проверка гипотез, логичнее использовать Гибкие методики.
То есть, как правило, Waterfall – для fix-price. Agile – для T&M.
Проектные подходы, в значительной степени зависят от формата договора, который вы заключаете с заказчиком. Если это типовой договор, с четким и детальным ТЗ и фиксированной ценой, то как ни крути, вас ожидает классический “Водопад”, где шаг влево или вправо грозит штрафом. Для такого варианта запрашиваются НМЦК (начальная максимальная цена контракта) и проводятся аукционы, тендеры и переторжки. Он ценен для решения конкретной задачи – автоматизации определенного процесса (или нескольких), рефакторинга легаси-систем, систематизации наборов данных и прочее.
Но мир сегодня очень динамичен, возможно, даже излишне)) И все чаще стали появляться рамочные договоры, где предметом торга становятся ставки ролевых исполнителей. А все потому, что заказчик не до конца понимает конечный результат (целевое состояние), находится в процессе частых изменений (M&A, смена руководства, рост бизнеса и т.п) или, интуитивно уловив тренд, создает новые цифровые продукты и сервисы. И тут нам на помощь приходит гибкость его Величества Agile!))
Продолжение следует...