Мыслить нешаблонно! Часть 2

Рассказываем о сочетании проектных методологий в софтовых проектах

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

Однако, есть случаи, когда методы дружат, причем эта коллаборация может быть различной:

Заимствование инструментов и артефактов.
Например, сложно представить современный софтовый waterfall-проект без ежедневных коротких статус-митингов и регулярных (раз в 2-3 недели) демонстраций функционала клиенту. 

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

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

«Пожарная» смена методов.
Также нельзя отказывать менеджеру в праве кардинальной смены управленческих правил. Это может быть оправдано, когда текущая парадигма не ведет к поставленной цели в нужный срок. Например, при работе по гибкой методологии, после определенного количества итераций и взаимодействия с заказчиком появляется понимание ожидаемого результата, а также временных и ресурсных ограничений. Это может случиться по разным причинам – успех R&D, смена руководства, нехватка бюджета. Тогда для реализации того же проекта имеет смысл сменить гибкие методы на классические, чтобы прийти к скромному, но реальному результату. И наоборот – при реализации конкретного ТЗ вдруг выходят новые НПА (нормативно-правовые акты), меняется стратегия компании или  бизнес-цели. В этом случае продолжение работы по утвержденному план-графику может оказаться бесполезным и переход на итеративную систему сильно повысит результативность.

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



Group 36 Group 36 Group 16 ic_8 ic_9