Як це ― коли каскадний менеджмент змінюється на аджайл
Це переклад чудового матеріалу Стіва Бланка. Його автор ― позаштатний викладач у Стенфордському університеті, старший викладач у Колумбійському університеті, викладач Каліфорнійського університету в Берклі.
Він був співзасновником та одним із перших працівників у восьми хайтек-стартапах, допомагав у заснуванні National Science Foundation Innovation Corps, програм Hacking for Defense і Hacking for.
Agile Fall (аджайл-провал) ― іронічна назва менеджменту програмного забезпечення, де ви намагаєтесь досягти аджайлу, не припиняючи користуватися каскадними методами керівництва.
Зазвичай результат чимось нагадує суміш воску для підлоги із топінгом для морозива. Ні підлогу не намастиш, ні морозиво не поллєш 🙂
До справи. Ось вам реальний кейс.
Якось на мітингу проджект-менеджерів компанії Fortune 10 я вперше побачив на власні очі, як відбувається AgileFall. Наша команда допомагала Fortune 10 трансформувати каскадний проджект-менеджмент в аджайл-процеси на одній із основних продуктових ліній.
Клієнтом був їхній директор виробництва, людина розумна, вмотивована й відкрита до нового. Коли його компанія зіткнулась із серйозною конкуренцією, він зрозумів, що якщо і проблема, і рішення містять багато невідомих, традиційні каскадні методи розробки не підходять. І звернувся до нас.
Отож, продуктова лінія містила 60 проєктів, якими керували 15 проджект-менеджерів. За кілька місяців до моменту, який описуємо, ми навчили команди проєктів базовим цінностям Lean (частини філософії аджайлу).
Усі проєкти належали до категорії Horizon 1 (створення нових характеристик для вже існуючих продуктів, спрямованих на наявних замовників) або 2 (адаптація існуючих продуктів, інструментів і методів до потреб нових замовників).
Зараз їхні команди створюють МФП ― мінімально функціональні продукти, виходять з офісу і розмовляють зі справжніми користувачами й іншими зацікавленими сторонами, більш-менш вільно вносять зміни до плану в процесі розробки тощо. Тобто, мають усе, що можна отримати з базового Lean.
На момент зустрічі команди раз на три місяці з’являлися на формальну звірку розкладу. І ось на останній зустрічі я зрозумів, що незважаючи на все, чого ми досягли разом, директор досі керує проджект-менеджерами, використовуючи каскадні процеси.
Як це було
Наш клієнт розповів, що люди скаржаться на кількість паперової роботи, яку потрібно готувати для цих квартальних звітів. Якість звітності його також не влаштовувала: таке враження, наче більшість команд готували ці звіти на коліні під столом уночі перед зустріччю. Та що ж робити? Як досягти вищої продуктивності і якісної, своєчасної звітності проджектів?
Спершу мені здалося: що ж такого поганого в тому, що клієнт хоче мати більше інформації? Хіба ж ми прагнемо не одного й того ж ― приймати рішення на основі фактів? Я майже ступив на слизьку доріжку й уже зібрався пропонувати клієнту більше засобів підвищення ефективності команд, як раптом… Раптом усвідомив, що клієнт досі вимірює успішність команд не результатами, а звітами. І це ― лінійний, покроковий каскадний менеджмент.
(Чесно кажучи, ця команда є єдиним острівцем Lean у компанії, де домінує каскадний менеджмент. І хоч його група змінила і мислення, і підхід усієї організації, та досі знаходяться ті, кому бракує паперового підтвердження.)
Під час зустрічі ми домовились про шляхи управління процесами через використання кількох принципів Lean/Agile проджект-менеджменту (навіть не згадуючи слів Lean і Agile).
- Цінність дарують люди, а не процедури і звіти.
- Утім, процедури і звіти досі важливі для тих, хто сидить кріслом вище.
- Мати команди, що розробляють інкрементальні й ітеративні МФП, важливіше, ніж мати вчасно зроблену документацію та звітність.
- Дуже важливо ― дозволяти командам використовувати інформацію, яку вони виявили через спілкування з користувачами, замість сліпо слідувати плану, створеному ще в перший день роботи над проєктом.
- Рух до результатів (вирішення проблеми/відповідність продукту місії) ― нелінійний процес, не всі команди прогресують з однаковою швидкістю.
Знадобилося не так уже й багато часу, щоб переконати клієнта: квартальні звіти можна замінити щотижневою розмовою керівної команди з чотирма-п’ятьма продакт-менеджерами й поверхневим оглядом 16-20 проєктів. Ітеративний цикл зменшився із трьох місяців до одного.
У таких бесідах ми вирішили концентруватися на результатах, а не на звітах. Таким чином, матимемо більше вербальної комунікації і менше зіпсованого паперу. Огляди торкатимуться частоти постачань, інкрементальної розробки й того, як лідер може усунути перешкоди, що заважають команді створювати щось нове. Окрім того, команда нашого клієнта продовжить ділитися звітами про свій прогрес з іншими командами, щоб ті могли безперешкодно навчатися одне в одного.
Радикальність ідеї полягала в тому, що директор виробництва не став використовувати жодних методів задля підвищення якості заповнення звітності. Натомість, ми вирішили підсилити орієнтацію на результат, яка, у свою чергу, підвищить якість усієї роботи (в тому числі й заповнення звітів).
Для команд це було просто чудово, а от на директора ліг додатковий обов’язок звітувати перед керівництвом за старими правилами ― так, як “нагорі” хотіли це бачити.
І ось настав кінець зустрічі. Клієнт запитує команду: “Забігаючи вперед, які члени команди потрібні для управління каскадними процесами, а які ― для Lean-менеджменту?” І вуаля!
У короткому обговоренні команда виявляє, що хаотичному збіговиську людей, що постійно навчаються за методами Lean, потрібно менше керівників, ніж стабільним і врегульованим каскадним процесам.
Ніяк не дочекаюся наступної зустрічі 🙂
Джерело (перекл. з англ.): https://hbr.org
