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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аgile-підхід каже: давайте швидше почнемо, швидше помилимось і швидше навчимось

Аgile-підхід каже: давайте швидше почнемо, швидше помилимось і швидше навчимось

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

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

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

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

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

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

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

У традиційному управлінні проектами є логіка “почати раніше”, в Аgile – “закінчити раніше”

У традиційному управлінні проектами є логіка “почати раніше”, в Аgile – “закінчити раніше”

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

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

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

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

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

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

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

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

Про те, чим agile відрізняється від традиційного управління проектами, і кому буде корисним цей підхід, – читайте в іншій статті Артема Сердюка.

Автор: Артем Сердюк, співзасновник effectcup.com та edumeter.com.ua, викладач kmbs