Agile чи ні: чи підходять вам гнучкі методи управління і роботи

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

У 2001 році відомі розробники ІТ-систем зібралися разом, щоб описати, як правильно створювати нові продукти в галузі. Результатом цієї зустрічі став Agile Manifesto, текст якого був переведений на більш ніж 50 мов і отримав глобальне поширення в ІТ-сфері. У ньому сформульовано 4 базові принципи і 12 правил роботи з Agile, які багато команд програмістів взяли на озброєння.

У маніфесті дається обтічне визначення Agile, хоча прочитати цей історичний документ безумовно варто. Чим більше розумних людей збираються в одній кімнаті, тим складніше їм домовитися про речі глобальні, філософських і фундаментальних (згадую свій досвід по розробці російських національних стандартів проектного управління): створити якийсь єдиний і універсальних для всіх чіткий підхід, загальну методологію, не вийшло .

Маніфест - то, в чому всі ці люди змогли максимально зійтися.

Для методологів проектного управління Agile ділиться на:

Mindset, образ мислення - установки, парадигми, погляди людини, націлені на швидку реакцію.

4 базові принципи і 12 правил - філософська основа Agile.

Набір практик: що робити і як вибудовувати роботу, щоб образ мислення і принципи маніфесту природно поєднувалися.

Американські гірки продуктивності

Будь-яка технологія або підхід переживають різні стадії: від популярності і чарівності, до марності і забуття. Компанія Gartner, знаменита своїми дослідженнями ІТ-ринку, описала цю динаміку циклами хайпа - Hype cycle.

Перша стадія: спочатку ніхто про технології не знає, але поступово про неї починають говорити - хайп починає рости.

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

Далі з'ясовується, що вона працює не завжди, не скрізь, не у всіх.

Потім настає розчарування.

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

Остання стадія, наступна за цим розумінням, - вихід на плато продуктивності.

Ці цикли добре ілюструє приклад з блокчейном. Технологія існує з 2008 року, але тоді про неї практично ніхто не чув. Два роки тому технологія досягла піку завищених очікувань. Експерти віщували, що все перейде виключно на блокчейн і він повністю змінить світ. Те ж відбувалося і з появою кіно, доповненої реальності, інтернету, електромобіля. Пам'ятайте класичне: «Взагалі з часом телебачення переверне життя всього людства. Нічого не буде. Ні кіно, ні театру, ні книг, ні газет, одне суцільне телебачення! »? Це той же цикл.

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

Agile для бренду або результату

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

Навіщо Agile Ощадбанку? На мій погляд, Сбербанк впроваджував Agile, тому що керівництво хотіло позиціонувати себе як інноваційну, передову ІТ-компанію, а не як традиційний і консервативний банк. Вони переконали багатьох, що стрімко рухаються в бік цифровізації та технологізації.

Впорядкованість і заплутаність

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

Одна з найвідоміших - модель Дейва Сноудена ( «Кіневін») CYNEFIN. Модель Кіневін говорить про системи в широкому сенсі, як про набір елементів і зв'язків між ними. Відносно бізнесу проект - це система, підрозділ - система, окрема команда - теж система. Всі системи бувають:

Впорядковані прості, зі зрозумілою причинно-наслідковим зв'язком. Табуретка на 4 ніжках. Відпиляли дві ніжки - табуретка впаде. Велосипед. Крутиш педалі - їде. Все зрозуміло;

Впорядковані складні, умовний автомобіль. Треба витратити час, щоб розібратися самому в системі, а ще краще залучити експерта, який пояснить, як все працює;

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

Хаотичні. Що б не робили - незрозуміло, як це влаштовано.

Уявімо, що потрібно випустити брошуру до конференції, а співробітники ніколи не займалися видавництвом або публікаціями? Це складна система, але ми проаналізували її етапи і залучили експертів, які підказали як потрібно. Інший рівень - потрібно випустити журнал з використанням віртуальної реальності для тих, у кого є окуляри доповненої реальності. Вони зможуть в 3D-форматі взаємодіяти зі статтями. Технічно це можна зробити, але абсолютно незрозуміло, як все це буде працювати і чи потрібно комусь. Експертів покликати не можна, тому що їх просто немає. Це і є Agile, адже потрібно експериментувати. Якраз для таких заплутаних і комплексних історій він підходить найкраще.

Ми проводимо невеликі експерименти, створюємо продукт, який нам вдається зібрати на свій страх і ризик. Цей продукт в Agile називається MVP (minimal viable product) або мінімально життєздатний продукт. MVP швидко виявляється на ринку, і можна протестувати наскільки ефективно він допомагає вирішувати проблеми цільової аудиторії, отримати зворотній зв'язок і доопрацювати продукт надалі, економлячи кошти.

Agile або НЕ Agile?

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

Варто застосовувати Agile, коли існують:

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

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

Необхідність постійної демонстрації успіхів. Потрібно регулярно показувати керівництву і замовникам працюючий продукт.

Недоцільно застосовувати Agile, коли існують:

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

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

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

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

Чек-лист готовності

Якщо Agile варто застосовувати у вашій компанії і для вашого проекту, залишається оцінити, чи готові ви і ваша команда до нової організації процесів. Це найважливіший і вирішальний момент. Може виявитися, що ситуація сприяє застосуванню Agile, але команда і керівництво не можуть адекватно використовувати нововведення.

Що потрібно перевірити до початку роботи по Agile.

Команда і стейкхолдери готові прийняти принципи і правила Agile-підходу. Принципи і правила прописані в маніфесті, в безлічі книг і статей. Найскладнішим для нашої ментальності є «право на помилку». Для невизначеності помилки - це нормально. Аgile - це і є інституалізовані методи проб, помилок, експериментів. Робимо, дивимося, що виходить, що ні, швидко переробляємо. Працює принцип «fail fast, fail safe» (помиляйся швидко, помиляйся безпечно). Неважливо, що помилився, важливо, що помилку виявили, розпізнали і швидко виправили. Це один з дуже серйозних бар'єрів на шляху впровадження Agile в Росії, де у багатьох залишилося сприйняття, що «у кожної аварії є ім'я, прізвище та по батькові». Якщо команда зробила щось неправильно, не повинно бути «розстрілів».

Є Agile-команда. Agile-команда - це непроста команда. У ній повинні поєднуватися ряд характеристик:

· Вона повинна бути компактна: 7 співробітників плюс-мінус 2 людини. Її ще називають «2 pizza team», команда, яку можна нагодувати двома піцами. Тобто зовсім невелика. Техніки масштабування Agile на великі команди існують, але вони дуже і дуже нетривіальні. Починати з них точно не варто;

· У команді мають бути присутніми співробітники, що володіють компетенціями, необхідними для розробки продукту і представляють всі підрозділи, які необхідні для розробки продукту;

· У співробітників повинно бути достатньо часу для роботи в команді. Вкрай бажано, щоб вони весь свій час присвячували роботі над проектом, принцип «100 на 0» - 100% залучення;

· Вкрай бажано, щоб всі сиділи разом, в одному приміщенні;

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

· Є власник продукту (замовник), який:

· уповноважений одноосібно визначати всі вимоги до продукту і пріоритетність завдань.

У нашій російської або «візантійської» системі управління отримати таке право непросто;

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

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

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

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

Agile довів свою ефективність вже не в одній індустрії. Практики Agile використовуються в російському Центробанку, на металургійних заводах, при цифровізації нафтових компаній, в НДДКР фармацевтичних компаній. Є кейс, коли по Agile проектували атомну електростанцію.

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

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

Про автора. Павло Алфьоров - професор бізнес-практики Московської школи управління «Сколково».