Чому методологія не врятує ваш проект

Привіт, я Макс. Встиг попрацювати менеджером проектів в аутстафе і аутсорсе, зараз працюю операційним менеджером в продукті, до IT займався проектами в реальному секторі економіки. Ця стаття про те, чому методології, якими ми користуємося в розробці, не стали срібною кулею, допомагає успішно закривати проекти. Вона стане у нагоді як менеджерам-початківцям, так і тим, хто вибрав для себе комфортну методологію і не хоче з нею розлучатися. Інженерам ця стаття допоможе відповісти на питання, чому ніяк не настане холакратия і менеджерів не відправлять займатися цією роботою.

В будь-якій темі є помилкові стереотипи, і їх легше всього виявити по гучних гасел, які озвучують інструктори, коучі та інші євангелісти, які їй навчають. В автомобільній темі це «навчимо екстремального водіння», в кулінарії — «готувати стейки», в SEO — «чорним технікам просування», в управлінні проектами — «аджайл-методологій», ясна річ. Вчаться такому самі фахівці і їхні клієнти. І ось ви їдете в машині з водієм, який освоїв поліцейський розворот, але нічого не знає про паралельній парковці, готові віддати будь-які гроші за тарілку смачного маминого борщу, тому що у вас гастрит від смаженого м'яса, а ще від того, що не можете вивести свій сайт з бана пошуковиків, зате на проекті аджайл. Виходить, що методологія не є первинною. Але чому і що з цим робити?

Помилка вижив

Не перестаю дивуватися тому, якою цікавою може бути історія. Вона, як нормальна куртизанка, легко навчить пацана життя.
Друга світова війна перевалив за свій екватор. Союзники щосили використовують важкі літаки для бомбардування і несуть відчутні втрати. Це недобре, це проблема. Проблему потрібно вирішувати. Будь-яке рішення починається зі збору інформації. У стислі строки дані про попаданнях в різні частини літаків зібрані і готові для аналізу. Ось вони.

Найбільше страждають крила, фюзеляж і хвіст. Відповідно, потрібно зміцнювати саме їх. Це логічно. Це перше, що приходить в голову. І це називається «помилкою вижив».

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

Дослідники могли вивчити отвори від куль тільки на тих літаках, які повернулися на базу. Але ж літаки, загиблі в бою, отримували пошкодження в інших місцях, а значить, саме такі ушкодження критичні. Броню слід зміцнювати не там, де більше всього пробоїн, а там, де вижили літаках їх немає зовсім. А місця на вижили літаках, які отримали сильні пошкодження, не потребують зміцнення, вони і так гарні.

Але при чому тут методології та проекти?

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

Помилка вижив і історія методологій

Шлях методологій у розробці почався в 70-х з появою «водоспаду». Трохи пізніше з'явилися банківські проекти — тоді почали відходити від варіацій на тему ватерфола і приходити до інкрементною або ітеративним підходам. З 1995-го по 2001-й ріс бульбашка доткомів з цінностями в дусі «раз-два і продакшен», тут кувався аджайл. Бандити від розробки, що долетіли до аеродромів, створили успішні продукти і не лопнули, поділилися заснованими на помилку вижив рецептами успіху у вигляді маніфесту. Один чарівний побічний ефект все ж стався. Зміст менеджменту в чотири функції: планування, організації, мотивації і контролі. Відміну гнучких методологій від негнучких в тому, що в негнучких функції менеджменту виконує проектний менеджер, а в гнучких — сама методологія. Проблема в тому, що дотримання методології вимагає серйозної дисципліни або досвіду. Досвід є не у всіх, тому з'являються коучі за канбан-піці та майстри скраму.

«Чому нікуди не поділися менеджери IT?» — задаються питанням нормальні пацани — кодери, адже минуло 20 років після маніфесту? Та тому, що вибір методології раніше не впливає на успіх проекту і хтось повинен вибивати з клієнта вимоги, розуміти, скільки це грошей і часу, думати про ризики і спілкуватися з керівництвом, замовником і командою. Круто, чарівно, чудово, якщо це робить команда, дотримуючись методології.

Вибір методології

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

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

Відповідно, сили і енергію варто витратити на розуміння того, куди ми хочемо поїхати, а відповідь на запитання «на що?» виявиться на поверхні.

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

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

Впливає чи невірний вибір методології на провал проекту?

Опубліковано: 31/01/20 @ 08:00
Розділ Різне

SEO Блог