[Про автора: Богдан Онищенко — Senior Product Owner в Intellias, product-ентузіаст, викладач Lviv IT School, любитель брюховицьких чебуреків]
З agile я вперше познайомився у 2012, коли долучився до scrum-команди. Протягом 2 років працював розробником. 1,5 роки — на посаді scrum майстра; 4 останні — на позиціях product owner/product manager в Україні, Польщі, Німеччині. За цей час встиг переконатися, що в agile далеко не все залежить від професіоналізму та наполегливості людей, що його розвивають. У цій статті вирішив поділитися спостереженнями за вітчизняним ІТ-ринком. Маю надію, що вони будуть цікавими тим, хто щодня стикається з agile.
Для початку розставлю крапки над «і»:
- Agile працює і є дієвим набором інструментів для розробки продуктів чи управління проектами як в ІТ, так і в інших сферах. Це вже давно мейнстрім.
- Правильно впровадити agile, у будь-якій його формі, доволі складно, оскільки це вимагає єдиного розуміння та злагоджених дій практично усіх складових частин організації, починаючи з самої верхівки.
- Agile — не панацея. Він має обмежений діапазон дії та здатний завдати чималої шкоди, якщо недоречно його застосовувати чи невміло впроваджувати.
А тепер — поїхали.
Прозорість процесу розробки
Пам’ятаєте тренінги зі скраму? Transparency — Inspection — Adaptation. Для вдосконалення процесу розробки та збільшення продуктивності, усі елементи процесу мають бути прозорими, однаково зрозумілими та доступними для всіх учасників. Але чи настільки самі учасники в цьому зацікавлені?
Сьогодні більшість ІТ-компаній України працює за аутсорс-моделлю. І, щиро кажучи, в цих стосунках, типу Замовник — Підрядник, мало кому цікава прозорість.
Image Source: dilbert.com
Якщо розробник здатен виконати
Менеджменту характерні інші типи проблем: плани, що реалістичні лише в Power Point чи Excel, невраховані ризики, квола комунікація, через яку на розробку нікому не потрібних речей ідуть тижні. Такий менеджер не буде зацікавлений у тому, щоб його гріхи стали відомими широкому загалові.
Під лозунгами захисту розробників від зайвого стресу та політичних ігор менеджер не говорить розробникам всього, що чує від замовника, і навпаки, не інформує замовника про все, що трапляється з командою та планами. Під цими лозунгами заганяється черговий цвях у труну прозорості.
Image Source: dilbert.com
Деякі компанії грішать тим, що продають джуніорів за ціною сіньйорів або годину роботи розробника за ціною
На стороні замовника теж не завжди зустрічаються відповідальні професіонали. Боротися з проблемами, котрі ці люди спричиняють, складніше. Ми рідко бачимо повну картину речей на стороні замовника; людей на Заході захищає трудове законодавство, тому і найпроблемніших буває складно звільнити. Нерідко менеджмент ІТ-компанії використовує відмазки на кшталт: «Замовник завжди правий, бо він платить гроші». Шкода лише, що при цьому частенько забувають, що саме працівники, котрі більше інших страждають від такої поведінки, — це найцінніший ресурс будь-якої компанії.
Завдяки непрозорому/неефективному/відсутньому процесу доволі просто приховати проблеми, некомпетентність чи банальну лінь. І, якщо у ланцюжку від менеджменту замовника до розробників ІТ-компанії знайдеться принаймні декілька осіб, зацікавлених у саботажі процесу — вони знайдуть спосіб це зробити. Чим ширшими повноваженнями володітимуть ці люди — тим більш нищівні наслідки це матиме. На превеликий жаль, кінцевий ефект відчуватиме на собі здебільшого команда розробників у вигляді відсутності плану, овертаймів і постійного хаосу.
Специфіка проектів
Абсолютна більшість проектів, якими займається ІТ в Україні, — це легасі, шаблонки або стартапи. До того ж компанії рідко повноцінно працюють з продуктом, здебільшого — реалізують проекти.
Коли тривалий час колупаєшся в легасі-продукті, то основною твоєю задачею є підтримувати на плаву коричневий шматок коду незрозумілої консистенції, котрий якимось дивом і досі генерує прибуток. 80% часу ти витрачаєш на виправлення багів і допилювання милиць, а написання нових фічерів буває можливим хіба на Різдво чи Великдень. За таких умов середньостатистичну людину від розмов про ініціативність, інновації та agile починає цілком виправдано нудити.
Значна частина веб-розробки функціонує на шаблонах, що вже існують. Для реалізації невеликих проектів достатньо одного чи пари-трійки розробників. Додаткової складності у простий та ефективний процес ніхто з керівництва вносити не збирається. А розробники, що звикли до формошльопства і роками лишаються в таких компаніях, на жаль, не надто зацікавлені у змінах на краще.
Стартапи ж оперують в умовах високої невизначеності, коли невідомого більше, ніж відомого. Сьогоднішній план дій може кардинально різнитися зі вчорашнім. До того ж, коли основною метою є пошук власного сегмента ринку і боротьба за нього, то формалізувати процес розробки або накладати на нього якийсь фреймворк чи методологію — все одно, що пиляти гілку, на котру лише збираєшся сісти.
Відсутність конкуренції
Сьогодні на вітчизняному ринку клієнт переважно тримається однієї ІТ-компанії. Якщо справи йдуть кепсько, то малоймовірно, що замовник змінить компанію. Зазвичай відбуваються звільнення та заміна керівного складу з однієї чи обох сторін. Така взаємозалежність виникає через те, що чим довше замовник співпрацює з ІТ-компанією — тим потужніша в останньої акумуляція фахівців, досвіду у відповідних технологіях і доменних знань. Відтак розірвання замовником стосунків з ІТ-компанією і пошук нових партнерів відбувається лише у дійсно катастрофічних випадках.
Image Source: dilbert.com
При моделі взаємин Замовник — Підрядник, на стороні останнього рівень ініціативності та заангажованості з часом буде наближатися до 0. Бо навіть відверто халтурне виконання власних обов’язків не переважить ризиків, пов’язаних із розірванням взаємин, що склалися.
На противагу при моделі взаємин Партнер — Партнер до думок та зауважень формальних виконавців дослухаються. Коли виконавець отримує автономію та несе відповідальність за прийняті рішення, — то тенденція з ініціативністю буде прямо протилежною.
Очікування результатів уже й одразу
Agile-трансформація організації — надзвичайно складний процес. Вона має відбуватися з ініціативи/за згоди керівництва, що свідомо інвестує суттєві ресурси. Трансформація повинна проходити поетапно та під невпинним контролем, щоб не відхилитися від поставлених цілей, не втратити темпу чи не допустити регресу вже здобутих результатів; може тривати місяцями або й роками, залежно від розмірів організації.
Image Source: dilbert.com
На цьому тернистому шляху неминучі помилки та невдачі. Розв’язання певних проблем є часоплинним, що у свою чергу може вилитись у недовіру до змін, постійний скептицизм чи саботаж. Люди часто забувають, що суть agile — постійно розвиватися та вчитися, нехай і на помилках. Абсолютно нормально щодня припускатися помилок, за умови, що кожного разу це будуть нові помилки.
Нерідко agile-трансформації закінчуються крахом або зупиняються на півдорозі. Багато з тих, хто пробував і в кого не вийшло, тричі замислиться чи пробувати знов.
Що з цим робити
- Глобально — нічогісінько. Чекати, доки ринок не розвинеться самостійно і доросте до рівня, коли компанії, настільки ж сильно, як і розробники, будуть зацікавлені у роботі з цікавими, інноваційними продуктами. Зокрема, Centers of Excellence, котрі пропонують з ідеї та грошей замовника створити готовий продукт і розвивати його, є правильним кроком у цьому напрямку.
- Брати активну участь у житті української agile-спільноти. На сьогодні вона ще доволі слабо розвинена, порівнюючи з європейськими країнами з потужним ІТ-сектором. Конференції та мітапи — не лише хороша можливість для вивчення нового, нетворкінгу, а й нагода отримати інсайдерську інформацію про те, як насправді влаштовані процеси у компанії/на проекті, що вас цікавлять, від людей, котрі там працюють.
- Навіть якщо ваше робоче середовище не сприяє впровадженню жодного з agile-підходів, то навіть їхні окремі складові частини (щоденні стендапи, ітеративне планування, інкрементальна розробка тощо) можна використати собі на користь. Не бійтеся експериментувати, зробіть це для себе і для команди.
- Якщо процес для вас так само важливий, як і результат — то, можливо, варто почати шукати нову роботу, де буде цікавіше, буде більше можливостей реалізувати свій запал та здобути новий досвід.