×Закрыть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: ESI International Survey

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

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

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

Что делать

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

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

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

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

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

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

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

Выводы

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

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

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

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

LinkedIn

42 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Смысл статьи в том, что прежде чем ответить на вопрос Как? Нужно найти ответ на вопрос Что?

Статья ни о чем. Как выбрать методологию — Cynefin Девида Сноудена. Если вкратце — если знаем что делаем и как — good или best practices ака вотерфолл. Если продуктовый беклог — набор продуктовых гипотез, и мы не всегда знаем что делаем и как — Scrum. Ну и да, методология не спасет, а здравый смысл спасет. А еще бюджет, риски, команда, стейкхолдеры... говорю же, статья — ни о чем.

Спасибо, интересная статья.
Методология не спасёт ваш проект сама по себе, потому что смысл их изобретения, изучения, использования и комбинирования в достижении определенных целей, в том числе, проектных целей, но чаще важнее — целей компании, целей клиента, целей команды, ну и Ваших личных профессиональных целей.
Знание и опыт применения методологий даёт представление, как этих целей можно достичь не тратя лишних ресурсов, как эффективнее превышать ожидания при различной степени неопределенности требований, например.

«Успішний» — це зданий вчасно чи product/market fit?

Когда к Вам приходят с новым проектом. Спасибо.

Эх, и снова мой любимый аутсорсинг головного мозга. Убери «заказчик» и «требования» — и от статьи вообще ничего не останется...

Приветствую, Алексей. Замените «заказчик» на «внутренний клиент» и вернёте себе веру в жизнь.

Что за внутренний клиент? И что там насчет требований?

www.google.com/...​&sourceid=chrome&ie=UTF-8

Требования зачем убирать? «Нас никому не сбить с пути, нам все равно, куда идти.»?

Требования они как бы от «требовать». Какие требования у молодого продукта, выходящего на рынок? Одни гипотезы да предположения...

Что-то подозрительно часто стали появляться статьи на тему адекватного менеджмента). Ремарка от себя: любой повторяющийся кейс должен быть поставлен на процесс и закрыт ответственным человеком, а не ждать, пока «командная работа» © будет с очень переменным успехом разруливать текучку, размазывая либо ответственность за всё подряд тонким слоем по толпе людей в зависимости от фазы Луны, либо размазывая кого-то одного из команды тонким слоем по процессам. В общем, столько разговоров о мифической бюрократии, а на деле процессы банально не закрыты (упоминание про семью и BA — боль бгг).

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

Неверный выбор методологии входит в 65% этих причин, судя по диаграмме. Именно на степени ясности входящих Requirement Definition и Scope Definition и базируется выбор методологии разработки.

Понятные готовые требования с жестко фиксированным скоупом — waterfall.
Требования на уровне общей идеи (в стартапе, например) — agile с частыми короткими циклами разработки, в процессе которых проясняются требования и скоуп.

Заменить agile на waterfall в стартапе — и он проест почти любые деньги, не родившись.

Добрый день, Николай. Так все-таки, сначала понимание требований — потом методология. От того, что кто-то waterfall выбрал требования сами собой не появятся, ясное дело.

Нет, Максим. «Сначала понимание требований» — это waterfall. Это когда нужно запустить спутник в 30-летнее путешествие. Когда же нужно выпустить продукт для массового пользования, и фаундеры здраво понимают, что картинка у них в голове не факт, что в этом именно виде и нужна пользователям (как в большинстве проектов сейчас) — тогда приходится иметь дело с теми требованиями, что есть, отбрасывая идеализм в сторону, и создавать что-либо короткими итерациями, сверяя изначальные требования и планы с обратной связью от реальности.

Если Вы изучали когда-либо основные базовые «Алгоритмы и структуры данных» — Вы могли обратить внимание, что они ВСЕГДА идут неразрывно вместе и обуславливают друг друга — вид/тип данных и наиболее удобные и эффективные для них типы/видов операций над ними — алгоритмы. Здесь у вас данные — требования, алгоритмы — методологии.

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

Так ты сам и отвечаешь на вопрос Николая верно — все, что есть на том пайчарте, и есть вопрос выбора интеграционного подхода (давайте всё-таки избегать слова методология, которое неверно в данном контексте). То, как ПМ управляет проектом в целом (область знаний — интеграция) и продиктует и работу с рисками, и требованиями, и всем остальным. И, разумеется, эти подходы должны меняться иногда даже в одном проекте, исходя из среды и контекста проекта.

менеджером проектов в аутстафе и аутсорсе, сейчас тружусь операционным менеджером в продукте, до IT занимался проектами в реальном секторе экономики

Окей, Вікіпедія, що таке «реальний сектор економіки»?

The real economy concerns the flow of goods and services (like oil, bread and labor hours)

Тобто створення «відпрацьованих годин», якщо вони були продані замовнику — це також реальний сектор економіки.

Добрый день, Владимир. Реальный — это когда тебя директор овощебазы везет в морозильную камеру на переговоры.

Вы правы, правильнее было бы сказать материальный. Спасибо за комментарий.

директор овощебазы везет в морозильную камеру на переговоры

экскурсия к самой большой печке на бандитском мет.комбинате также добавляет опыта и впечатлений, инфа сотка

Макс, привет! Статью читал еще в блоге, но актуальности она не потеряла, годная!

Привет, Кирилл) Спасибо, тут со времен блога добавилось смысла, уменьшилось матюков)

А мне статейка понравилоась. Без лишнего балшита. Хотя детализации маловато.
Вот ты спрашиваешь про табличку риски/веротяность.
А большинство вообще не понимает что есть риски, не говоря о вероятностях.

Отличная метафора по поводу ПМ-а. Сразу видится не офисный планктон, а вольный матрос с «проектом в каждом порту», и в каждом его любят и ждут)

О каждой статье на доу, в которой упоминается Канбан метод, где-то плачет один Девид Андерсон.

Мне одному режет слух «серебряная пуля» в речи?

Добрый день, Дима. Давайте вместе подумаем, чем заменить можно) Можно над формой поработать, можно над содержанием))

А что тут думать? Если сам не знаешь — идешь в словарь: www.multitran.com/...​l1=1&l2=2&s=silver bullet

Так на что менять будем?)

То есть даже словарь не помог? Печально...
Ну, лично я бы использовал «панацея».

Дмитрий, заменили, приятного чтения. Спасибо.

На осиновые колы и чеснок тоже проверили. Теперь безопасно.

А где «мы создавали эту программу»? Где про скорые помощи коммуникации?

Привет) Та тут же, на ДОУ, про программу — dou.ua/...​create-intership-program , про коммуникации — dou.ua/...​each-team-to-communicate

Адекватно, хотя и ничего нового. Методологии и фреймворки — это инструменты и только так к ним и надо относиться. Этому миру вообще не хватает прагматизма. Куда не взгляни, кругом упоротые фанатики: скрам, экология, веганы, права разнообразных групп и меньшинств и т.д. Просто нет ни времени ни места для трезвого, рационального подхода.

Привет, Сергей. В точку)

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

ну так это, спор теперь начинаем со ссылки на статью)

Отличная статья! Чувствуется практический опыт автора в разных окружениях.

С одной стороны, можно просто подождать, когда автор повзрослеет.

С другой стороны — зачем?

Ну так что решили?)

Подписаться на комментарии