Почему методология не спасет ваш проект

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

В любой теме есть ошибочные стереотипы, и легче всего их выявить по громким лозунгам, которые озвучивают инструкторы, коучи и прочие евангелисты, которые ей учат. В автомобильной теме это «научим экстремальному вождению», в кулинарии — «готовить стейки», в SEO — «черным техникам продвижения», в управлении проектами — «аджайл-методологиям», ясное дело. Учатся такому сами специалисты и их клиенты. И вот вы едете в машине с водителем, который освоил полицейский разворот, но ничего не знает о параллельной парковке, готовы отдать любые деньги за тарелку вкусного маминого борща, потому что у вас гастрит от жареного мяса, а еще от того, что не можете вывести свой сайт из бана поисковиков, зато на проекте аджайл. Выходит, что методология не первична. Но почему и что с этим делать?

Ошибка выжившего

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

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

Систематическая ошибка выжившего (англ. survivorship bias) — разновидность систематической ошибки отбора, когда об одной группе («выживших») есть много данных, а о другой («погибших») данных практически нет. Так что исследователи пытаются искать общие черты среди «выживших» и упускают из виду, что не менее важная информация скрывается среди «погибших». © Википедия

Исследователи могли изучить отверстия от пуль только на тех самолетах, которые вернулись на базу. Но ведь самолеты, погибшие в бою, получали повреждения в других местах, а значит, именно такие повреждения критичны. Броню следует укреплять не там, где больше всего пробоин, а там, где на выживших самолетах их нет вовсе. А места на выживших самолетах, которые получили сильнейшие повреждения, не нуждаются в укреплении, они и так хороши.

Но при чем здесь методологии и проекты?

Огромное внимание в управлении проектами уделяют методологиям. Тысячи статей, сотни успешных кейсов, видеозаписи, которые можно смотреть месяцами, десятки книг — информация качественная, легкая для восприятия, полезная. Так как пространства для маневра остается все меньше и меряться знаниями реально тяжело, фокус обсуждения смещается к сюрреалистичным темам: «Канбан — это методология или инструмент?», «Доколе вы будете называть скрам методологией, если это фреймворк?» и всеми любимой «Увеличение эффективности ежедневного стендапа с использованием планочек». Мы уверенно продолжаем укреплять крылья своих самолетов вместо моторов.

Ошибка выжившего и история методологий

Путь методологий в разработке начался в 70-х с появлением «водопада». Немного позже появились банковские проекты — тогда начали отходить от вариаций на тему ватерфола и приходить к инкрементным или итеративным подходам. С 1995-го по 2001-й рос пузырь доткомов с ценностями в духе «раз-два и в продакшен», тут и ковался аджайл. Бандиты от разработки, что долетели до аэродромов, создали успешные продукты и не лопнули, поделились основанными на ошибке выжившего рецептами успеха в виде манифеста. Один волшебный побочный эффект все же случился. Смысл менеджмента в четырех функциях: планировании, организации, мотивации и контроле. Отличие гибких методологий от негибких в том, что в негибких функции менеджмента выполняет проектный менеджер, а в гибких — сама методология. Проблема в том, что следование методологии требует серьезной дисциплины или опыта. Опыт есть не у всех, поэтому появляются коучи по канбан-пицце и мастера по скраму.

«Почему никуда не делись менеджеры в IT?» — задаются вопросом нормальные пацаны — кодеры, ведь прошло 20 лет после манифеста? Да потому, что выбор методологии по-прежнему не влияет на успех проекта и кто-то должен выбивать из клиента требования, понимать, сколько это денег и времени, думать о рисках и общаться с руководством, заказчиком и командой. Круто, волшебно, восхитительно, если это делает команда, следуя методологии.

Выбор методологии

Методологию можно сравнить с автомобилем. SDLC и вытекающий из нее Waterfall — Toyota Land Cruiser 105 в мире подходов к разработке: железный, надежный, много жрет, сейчас на нем ездят бывшие бандиты, генералы, банкиры. Kanban — Toyota Camry: востребованная, комфортная, подходит почти для всего. Scrum — Toyota Prius: была модная у хипстеров, но все больше на ней ездят домохозяйки — машина-мем. Сходство методологии с автомобилем неслучайно: выкинь запчасть — и машина будет ехать не так, а может и вообще не завестись. Дисциплина нужна, чтобы не выкидывать запчасти, опыт — чтобы избавляться от ненужного, но ехать дальше. Соответственно, методологию и уровень следования ей нужно выбирать, как машину. На дачу можно съездить на старых «жигулях», а вот везти девушку на Лазурный берег лучше на чем-то более быстром и надежном.

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

Соответственно, силы и энергию стоит потратить на понимание того, куда мы хотим поехать, а ответ на вопрос «на чем?» окажется на поверхности.

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

В противоположной ситуации даже верно подобранная методология не поможет нам закончить проект. Банальный пример: сделали прототип приложения на коленке, оно взлетело, начали его дорабатывать, вместо того чтобы рядом поднимать нормальное решение, через год появились проблемы с производительностью, начали рефакторинг, перестали вести разработку, отстали от конкурентов — проект сдулся.

Влияет ли неверный выбор методологии на провал проекта?

Неверный выбор методологии входит в 1% причин, по которым проваливаются проекты. Давайте глубже посмотрим на то, почему выбор методологии не влияет на успех проекта.

Стержень, вокруг которого строится любая методология, — SDLC. Знаешь SDLC — знаешь любую другую методологию.

Какую методологию ни выбери — этапы, функции и результат те же. Отличие в том, как команда добивается результата.

Что делать

Давайте вернемся к диаграмме. Каковы наши настоящие проблемы? Плохо описали требования? Окей, со всеми бывает. За этим тянется «плохо поняли скоуп». А как его поймешь-то без требований? Давайте пока остановимся на этом.

Требования — это, по сути, проблема заказчика, а в счастливых и полных семьях еще и бизнес-аналитика, но мы-то знаем, что каждая семья несчастна по-своему. Есть «проектные семьи», в которых вообще только разработчик да проектный менеджер, у которого таких семей о-го-го — в каждом порту. Что делать будем? Какую методологию ни приложи, не получится. Поэтому учимся общаться, выясняем требования, понимаем скоуп. О том, как общаться и учить этому команду, я уже писал.

Едем дальше. Батюшки, да тут же риски! В негибких методологиях обработке рисков посвящено достаточно много времени. В гибких, как правило, нет. Тут можно и костылем подпихнуть. Заводим отдельную доску для рисков. Кто хоть раз делал такое? Пишите в комментах.

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

Дальше коммуникация. На нее жаловаться поздно: пока мы разбирались с требованиями и скоупом, уже успели эту проблему решить.

Потом недостаток квалифицированных ресурсов в рамках 3% статистической погрешности. Тут у проектного менеджера два пути: доводить рекрутеров до слез и не поддаваться на провокации со стороны руководства. Если не прокатило, уходить. Это нормально. За джунов по рейту сеньоров отвечаете вы, а не владелец компании.

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

Выводы

Давайте подведем итог. Негибкие методологии основаны на SDLC, сформулированном в 70-х, и включают его этапы. Гибкие методологии включают в себя этапы SDLC и функции менеджмента.

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

А как вы подходите к выбору методологии?

Всем отличного года!

Темы: Agile, project management, Scrum, команда, менеджмент