Дисклеймер
Любой взгляд на проектное управление всегда субъективен. В этом тексте я попробовал сформировать комплексный взгляд на управленческие методики в разработке, основываясь на опыте реализации проектов в своей компании – для клиентов разных сфер, бюджетов и структур
Методологий много, т.к. это выгодно авторам
В современном мире разработки существует большое количество разных методологий управления проектами и периодически появляются новые. Вам с пеной у рта могут доказывать, что скрам – это не канбан, аджайл – вовсе не методология, а путать ватерфол с V-моделью – ̶з̶а̶ш̶к̶в̶а̶р̶ верх непрофессионализма. Отчасти эти люди будут правы, т. к. у каждой школы есть свои уникальные особенности, а некоторые различаются по своей сути. Однако, нельзя не отметить, что выход новых трудов на эту тему часто преследует цель заработать популярность для автора и не всегда несет реальную смысловую ценность.
Кроме того, внедрение новых, актуальных фреймворков является своеобразной модой среди топ-менеджмента российских компаний, и каждая новая методика прокатывается волной по корпоративному миру – сначала стартапы, потом бизнес покрупнее, затем большие корпорации и, наконец, гос.структуры. И нередко речь идет только о внедрении названий, без каких-либо изменений принципов работы.
По практике реальных проектов, основных методологий – две
При этом, исходя из реального опыта на проектах можно сказать, что в качестве основных используются два подхода. Можно использовать разные термины, но условно назовем их Классический (Waterfall во всех проявлениях) и Гибкий (все итеративные методы). Главное отличие их, в общем случае, кроется в понимании конечного результата. В проектах, где он формализован и неизменен, используется классический подход. В этом случае обычно есть артефакт, фиксирующий и описывающий, каким этот результат должен быть (техническое задание, требования к функционалу, тех. проект и прочее). Во всех остальных случаях – когда итог проекта сложно формализовать, логичнее использовать Гибкие методики. В таких проектах часто ориентирами служат метрики, клиентские пути, коммерческие показатели.
Waterfall – для B2G. Agile – для продукта
Условно можно считать, что из двух основных подходов первый больше подходит для проектов заказной разработки, для которых обычно устраивают тендеры и нанимают подрядчиков. Он ценен для выполнения конкретной задачи – автоматизации определенного процесса (или нескольких), рефакторинга легаси-систем, систематизации наборов данных. А второй гармонично смотрится в проектах продуктовой разработки, чаще реализуемых с помощью внутренней команды. Зачастую в таких проектах может не быть задач, а есть только направления, ориентиры в которых стоит двигаться в поисках коммерческого результата. Только не стоит считать гибкие методологии способом автоматизации хаоса. Эта задача лежит за пределами мира разработки и не решается ни одной из методологий 😊
Когда методы дружат
Однако, есть случаи, когда методы пересекаются, причем это пересечение может быть разным:
Пересечения инструментов и артефактов
Нередко классические подходы заимствуют инструментарий у гибких и наоборот.
Например, сложно представить традиционный waterfall-проект по разработке без ежедневных коротких статус-митингов и регулярных (раз в 2-3 недели) демонстраций функционала клиенту.
С другой стороны, зачастую в продуктовом итеративном проекте можно встретить план-график (в этом случае его могут стыдливо называть «планом спринтов») – основополагающий артефакт классического проектного управления. Стоит отметить, что в обоих случаях это всего лишь займ инструментов, общие принципы остаются незыблемыми.
Гибридная методология в рамках одного проекта
Случается, что в рамках одного проекта, одного контракта и одного заказчика (даже гос. заказчика) могут быть разные уровни зрелости бизнес-процессов. Например, для одного процесса есть определенная сложившаяся практика, нормативная база и легаси-система. А для другого есть только понимание его необходимости и больше ничего. При этом в ТЗ могут быть описаны общие требования к автоматизации, не детализированные до уровня конкретных шагов. В этом случае придется комбинировать подходы. И, возможно, даже в пределах одной команды вести управление разработкой разными способами. Для первого процесса иметь последовательной план-график формата «аналитика-разработка-тестирование», а для второго реализовывать быструю доставку промежуточных результатов заказчику, постоянно фиксируя обратную связь.
«Пожарная» смена методов.
Также нельзя отказывать менеджеру в праве кардинальной смены управленческих правил. При наличии понимания, что текущая парадигма не ведет к поставленной цели в нужный срок, это может быть оправдано.
Например, при работе по гибкой методологии, после определенного количества итераций появляется понимание конкретной цели, а также временных и ресурсных ограничений. Это может случиться по разным причинам – успех RnD, смена руководства, нехватка бюджета. Тогда для реализации того же проекта имеет смысл сменить гибкие методы на классические, чтобы прийти к скромному, но реальному результату. И наоборот – при реализации конкретного ТЗ вдруг выходят новые НПА, меняется стратегия компании или цель бизнес-процесса. В этом случае продолжение работы по календарному плану может оказаться бесполезным и переход на итеративную систему сильно повысит результативность
Резюме
Стандарты — это хорошо. Они дают возможность работать по шаблону, если не хватает опыта. Они помогают управлять большими проектными офисами. Они служат стержнем и ориентиром в нестандартных ситуациях на проекте. Но ключевая компетенция проектного менеджера – это умелая комбинация методологий, инструментов и подходов в зависимости от потребностей проекта. Именно поэтому важно не увлекаться следованием стандартам, а оценивать значимость разных конфигураций в режиме онлайн. Управляйте стандартами, а не позволяйте стандартам управлять вами!
