Міфи в Agile

Автор: Артем Сердюк
Джерело: innovations

Часто при впровадженні Agile ми стикаємось із запереченнями, корінь яких — невірні уявлення людей про те, що собою являє цей підхід. Далі ми поговоримо про деякі з них, і те, наскільки вони обґрунтовані.

Артем Сердюк

Найчастіше я чую від менеджерів, які знайомляться з Agile, що "Без менеджера ніхто не буде працювати".

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

Agile — це зовсім не відсутність контролю чи управління. Навпаки, контроль та мотивація людей вбудовані у самий процес. Виконавці отримують велику свободу вибору при виконанні задач, вони самі планують свою роботу, але натомість отримують частий и жорсткий контроль за результатами.

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

Тому часто люди, які працюють в Agile-проектах, відмічають: вони починають працювати інтенсивніше, у них менше перерв, і їм це подобається! А менеджери відчувають, що краще контролюють проект завдяки частій перевірці результатів, хоча начебто дали підлеглим "повну свободу".

Друге заперечення звучить таким чином: «це працює лише з програмістами, бо вони розумні, а в мене — зовсім інші люди, яким не можна давати свободу».

Особисто я робив agile-проекти із 17-річними студентами, а ви самі знаєте, як у них з дисципліною і відповідальністю. Завдяки вбудованому в процес контролю та мотивації вони працювали дуже напружено, і проекти в цілому були успішні.

Якщо це працює зі студентами, які вчаться, роблять проекти і гуляють, то напевно працюватиме й з людьми, яких ви відбирали. Це той випадок, коли середовище «робить» людину. Коли воно стимулює пошук виправдань і максимальної безпеки, не варто очікувати від людей сміливості, відповідальності та перевершення сподівань. А якщо середовище стимулює творчість, сміливість, взаємодопомогу — проявляються ці якості.

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

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

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

Тому Agile-підхід каже: не варто витрачати багато часу та зусиль на складання детального плану "від початку до кінця". Давайте швидше почнемо, швидше помилимось і швидше навчимось. Ми можемо починати проект з візією та детальним планом тільки для першого кроку. Зробивши його, ми подивимось, де опинились, чи правильним шляхом йдемо, і тільки тоді сплануємо наступний крок.

У підсумку може виявитись, що в рамках Agile-проекту ми витратили на планування стільки ж часу, а то й більше, ніж у традиційному проекті. Зате перші результати ми отримали значно раніше, бо не довелось чекати, поки великий план буде готовий та усіма затверджений.

Оскільки в Agile ми детально плануємо тільки наступний крок, це по силам навіть виконавцям. Не всі можуть скласти план усієї компанії на рік, а от запланувати роботу чотирьох людей на тиждень зможуть навіть самі ці люди! І це також перевага: менеджер перестає бути вузьким місцем, на яке всі чекають.

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

Четвертий розповсюджений міф про Agile: «Це неефективно!».

Люди міркують так: працівники повинні бути зайняті кожну хвилину. Оце і є ефективність. Тому якщо в них немає раптом роботи за поточним проектом, треба їм щось докинути.

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

А в Agile-підході пропонується виділити команду, яка буде працювати лише над одним проектом, і посадити їх разом. За рахунок відсутності переключень команда буде працювати в рази краще, а проект закінчиться раніше.

У традиційному управлінні проектами є логіка «треба почати раніше», щоб клієнт бачив, що робота пішла. В Agile логіка інша: ми хочемо закінчити раніше. А для цього важливо не вести проекти паралельно. Тоді, як це не дивно звучить, перші закінчені проекти з’являться раніше, а останній — в той же час (чи трохи раніше), ніж при паралельному виконанні. І все це — завдяки фокусу і відсутності переключень.

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

Тут існує два нюанси. По-перше, це стосується не менеджерів, а "творців" — людей, які щось створюють, і тому повинні бути "у потоці", бажано без відволікань. А по-друге, ми часто залежимо від когось назовні, у нас є зовнішні тригери. І якщо їх багато, і вся робота зав’язана на них, то описаний підхід втілити буде складно.

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

П’яте заперечення: «це все працює лише для маленьких інтернет-проектів».

Справді, у невеликих ІТ-компаніях Agile працює класно. У великих компаніях структура та відносини всередині набагато складніші, і впровадити будь-який новий процес роботи доволі складно, незалежно від того, це Agile-процес чи якийсь інший.

У великих компаніях Agile може протирічити корпоративним цінностям, які звучать як "все має буди задокументовано", "ви не можете порушити інструкцію, інакше будете покарані". В цьому випадку він дійсно працювати не буде. Але якщо цінності у бізнесу інші, впровадження Agile відбувається доволі швидко, і результати вражаючі. Я бачив подібні компанії, де більшість підрозділів працюють за Agile — і дуже задоволені.

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

Згоден, інструменти в Agile-процесах дійсно класні. Але якщо ви візьмете лише дошку, не варто сподіватись на wow-ефект.

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

Про автора:

Артем Сердюк, менеджер проектів в ISM Ukraine, викладач управління проектами kmbs.