Ленсіоні навиворіт, або Методи побудови високопродуктивної команди
Мене звати Кирило Білобородько, я співпрацюю з ЕРАМ як Software Engineering Manager. Наразі відповідаю за успішне делівері та розвиток відносин з клієнтом Epic Games і тримаю в полі зору роботу понад 150 експертів по всій Україні. Протягом
Передусім пропоную дати визначення високопродуктивної команди. Версія, яка стосується сфери розробки програмного забезпечення та сподобалася мені найбільше, така: високопродуктивна команда — це та, яка працює в одному складі нескінченно довго. Визначення дуже умовне, але в ньому є здоровий глузд. В ІТ високопродуктивна команда працює над корисним для ринку та клієнта продуктом, який постійно оновлюється та зазнає позитивних змін. Якщо вона робить це нескінченно довго, значить змогла створити хороші відносини з клієнтом і є достатньо продуктивною.
Теорія
Коли говоримо про побудову команди, мені подобається класичний підхід Патріка Ленсіоні, який використовують у багатьох тренінгах. У книзі «П’ять вад у роботі команди» він наводить таку піраміду:
Ленсіоні рекомендує починати роботу з командою з першого щабля та поступово йти вгору, тобто від побудови довіри до відповідальності за результати. Адже, на його думку, члени колективу спочатку не довіряють одне одному, не хочуть демонструвати свої слабкі сторони та співпрацювати. Далі, коли робоча група вийшла на новий рівень, люди мають перестороги щодо висловлення своєї думки. Згодом є ризик, що спеціалісти не будуть брати відповідальність за виконання роботи. Пізніше треба перебороти невимогливість до результатів у кожного члена команди. Відтак упевнитись, що фахівцям не байдуже, який буде кінцевий результат.
Але що, коли ми трансформуємо стандартний підхід? Скажімо, подивимося на піраміду навиворіт. Ось так:
Ідея перевернути піраміду спала мені на думку тому, що на практиці старт проєкту настільки швидкий, що команда не встигає пройти всі стадії розвитку за класичним підходом. Вона береться за розв’язання питань недовіри та страху конфлікту значно пізніше. Саме таку парадигму я частіше бачу на проєктах. Поясню докладніше.
Уявімо, що ми плануємо створити продукт для цифрової трансформації клієнта. Є конкретна мета, якої ми прагнемо досягти. Найголовнішою вадою для команди в цьому сенсі буде байдужість до результатів. Але припустимо, що завдяки вдалому менеджменту її вдалося нівелювати на старті. Це можна зробити, якщо ставити для команди чітку мету та візію проєкту:
- роз’яснювати, чого саме клієнт прагне досягти завдяки реалізації цього проєкту;
- яку бізнес-проблему вирішує;
- що будет, якщо проєкт не буде реалізовано.
То що далі? Як позбутися інших проблем заради продуктивності?
Невимогливість. Вимоги — це класичний підхід, адже будь-яка бізнес-ціль передбачає функціональні та нефункціональні вимоги, очікування від клієнта, проєкту й менеджера. Однак це й про принципи. Скажімо, менеджер відразу декларує: я поважаю чесність, відкритість, взаємодопомогу. Мовляв, сповідую сам і очікую цього ж від команди. Чіткі вимоги керівника до колективу формують вимогливість і в самих його учасників. Це важливий фактор для продуктивної роботи.
Безвідповідальність. Щоб позбутися її, треба донести до кожного члена команди цінність його частини завдань. Коли спеціаліст розуміє, які ризики може спричинити недбале ставлення до проєкту, він відчуває важливість своєї ролі та відповідальність за результат.
Страх конфлікту. Цей щабель я розглядаю дещо інакше, ніж Ленсіоні. Пропоную дивитись на нього з погляду відповідальності. Повсякчас люди бояться опинитися на «чужій території»: мовляв, візьму не своє — розлючу колегу. Через це продуктивність може страждати. Менеджеру важливо розвивати та заохочувати культуру допомоги одне одному. Тоді цю хибу можна оминути.
Недовіра. Так, до неї приходимо в самому кінці. Коли всі чотири щаблі сформовані й виставлені чіткі вимоги з боку клієнта, люди починають працювати на один результат і поступово формують довіру. Команда стає продуктивною та ефективною, а спеціалісти з часом дізнаються одне про одного більше, ніж просто межі ролі чи повні обов’язки.
На мою думку, цей підхід найближчий до органічної побудови компанії. Адже спочатку підприємець формує місію, стратегічне бачення та головну мету бізнесу й набагато пізніше замислюється про довіру в команді. Все-таки початкова мета створення будь-якої робочої групи — досягнення певного результату.
Що на практиці?
Загалом я впевнений, що з кожної групи людей можна створити високопродуктивну команду. Це питання часу та найбільш вдалого співвідношення навичок і персональних якостей.
За 2020 рік я стартував
Мій досвід доводить, що для виходу на високу продуктивність команді з 10 професіоналів потрібно близько місяця. Відповідно, коли ми стартували проєкт на 50 інженерів, закладали на це
Один з важливих факторів, який варто мати на увазі: збалансований склад з погляду професійного рівня й досвіду. Бувають команди, де є
- досвідчені експерти, які беруть лідерські ролі, передають досвід і вчаться вирощувати нове покоління професіоналів;
- спеціалісти середнього рівня, які водночас стають менторами для новачків і вчаться у більш досвідчених колег. До того ж вони можуть випробувати себе у нових ролях;
- Junior-інженери, які в сильній команді професіоналів скоріше зростають технічно й особистісно.
Якщо нехтувати цією рекомендацією, ризикуємо мати кризу лідерства (коли сеньйори прагнутимуть очолити роботу та проявити свої риси), незбалансовану (якщо в ній тільки Middle-спеціалісти) або вкрай незрілу (якщо маємо справу лише з новачками) команду.
Щодо ситуації, коли замовник просить сформувати команду з самих лише Senior-спеціалістів. Це можливо, якщо клієнт звертається до компанії вперше. Обидві сторони все ще вибудовують довіру, а клієнту найімовірніше вкрай потрібні додаткові сили, щоб реалізувати проєкти. У компанії, яка надає послуги розробки ПЗ, повинні розуміти, що такій команді буде складно функціонувати довгий час, адже в ІТ-індустрії вектор розвитку Senior-спеціаліста найчастіше проходить через етап Lead-інженера. В останнього має з’явитися досвід координування робочої групи. Але це майже неможливо, коли в проєктній команді
Отже, як ми в ЕРАМ вирішуємо схожі ситуації? Якщо одразу бачимо, що взаємодія з новим клієнтом має потенціал, та плануємо, що команда буде співпрацювати з ним більше ніж пів року, то беремо на себе відповідальність на певному етапі забрати з нього додаткові турботи. Поясню: скажімо, на початку нового проєкту робочою групою наших Senior-інженерів опікується менеджер на боці замовника. Для нього це непросто, адже він має свою команду, а тепер ще й займається спеціалістами з боку вендора. Не раз у своїй практиці я бачив, що з часом такому управлінцю стає все складніше виконувати операційну роботу.
Коли це стає помітно, на одній з регулярних зустрічей з людиною, що ухвалює рішення на боці замовника, ми пропонуємо трансформацію. Мовляв, зараз твій працівник ставить завдання, контролює роботу та перевіряє код
З мого досвіду така стадія у відносинах з клієнтом настає через три місяці співпраці. Ще через три ми повністю завершуємо цю трансформацію.
Як вимірювати прогрес?
Тут є різні підходи. Мені найбільше імпонує модель з трьох складників: мотивації команди, швидкості обробки однієї середньої задачі та передбачуваності. Щоб просканувати їхній рівень, я ставлю собі такі запитання:
1. Чи отримує задоволення від роботи команда?
Задоволення від роботи ми в ЕРАМ перевіряємо за допомогою спеціального пульс-опитування. Воно міститься у вигляді віджету у внутрішніх системах. Завдяки цьому інструменту кожен спеціаліст з певною регулярністю відповідає на запитання щодо свого настрою та стану. Менеджер з People-партнером на базі цих відповідей можуть проаналізувати динаміку, настрої команди та позитивно вплинути на них, якщо необхідно.
Інший спосіб — масштабне опитування серед людей, які співпрацюють з компанією. Інформація, яку ми отримуємо, трансформується в якісну аналітику та допомагає в роботі. У нас такі великі дослідження відбуваються двічі на рік. У проміжках між ними ми проводимо опитування в межах проєктів для Epic Games.
2. Як швидко й наскільки якісно ми можемо виконувати завдання від клієнта або джерела вимог?
Цей показник виміряємо за допомогою так званого lead time: проміжку між тим, коли задача потрапила в систему, і тим, коли вона повністю виконана. Також чудові інструменти пропонує Kanban, як-от lead time distribution chart. Цей графік демонструє, з якою вірогідністю команда зробить завдання у визначені терміни (скажімо, якщо ми бачимо, що 80% завдань виконуємо за 5 днів, 15% — за
Для перевірки якості можна використовувати інструмент Defect Density, тобто щільність дефектів. Можемо виміряти, скільки дефектів маємо в один спринт/велику ітерацію тощо. Метрика гнучка, це її велика перевага.
Ще одна гарна метрика — Defect Containment. Вона демонструє, скільки дефектів знайшла команда розробки й тестування порівняно із загальною кількістю дефектів. Добре, коли ми знайшли значно більше, ніж наш клієнт або користувачі. Умовно, якщо зі 100 дефектів у системі ми знайшли 95, а решту — люди зовні, то цей показник у нас 95%, або 0,95. Залежно від проєкту ми можемо вважати його позитивним.
Остання метрика — це співвідношення виправлених дефектів до відкритих. Ми дивимось на динаміку та аналізуємо, скільки дефектів у нас залишаються постійно відкритими. І якщо беклог хиб стає більшим, ніж для нас прийнятно з погляду кількості та пріоритетності, це тривожна тенденція, можливо, щось не так (беремо забагато завдань, команда демотивована тощо).
3. Чи можемо ми прогнозувати результати ітерації (або який обсяг роботи здатні виконати за певний проміжок часу)?
Відома метрика, яку ми беремо зі Scrum — це velocity. За її допомогою розуміємо, скільки сторі-поінтів (або інших одиниць ) виконуємо за один спринт, і відповідно прогнозуємо час, який знадобиться на те чи інше завдання.
Інший спосіб прогнозування теж пов’язаний з velocity, це committed vs completed. Метрика дає змогу оцінити, наскільки ми можемо спиратись на те, що команда виконає всі задачі, які бере на себе за ітерацію. Тобто, якщо ми кажемо, що плануємо зробити 100 сторі-поінтів за певний час, але фактично робимо 90, то ця метрика становить 90%, або 0,9. Цей показник може бути для нас прийнятним або неприйнятним. Загалом прийнятним рівнем вважають від 90 до 100%. Якщо маємо показник
Те, наскільки збігається наша перша оцінка з фактичним виконанням завдань, говорить про рівень передбачуваності робочої групи. Це вкрай потрібно, адже насправді для кожного клієнта не така важлива швидкість, як передбачуваність команди. Тобто нехай краще команда зробить те, що обіцяла в конкретну дату, ніж буде супершвидкою, але нестабільною.
Проте самих відповідей на питання замало. Менеджеру стануть у пригоді спеціальні інструменти та трекери. Контроль делівері на проєкті має щонайменше три рівні.
Перший: знаємо актуальний статус розробки, постійно спостерігаємо прогрес, ведемо підрахунки та робимо прогнози на папірці (умовно).
Другий: маємо певні артефакти, які дають змогу упевнитися менеджеру та, можливо, аудитору проєкту, що за розробкою стежать і контролюють процеси.
Третій: ми фокусуємося на data-driven підході, коли метрики охоплюють різні напрями розробки на проєкті (якість продукту, безпеку, ефективність команди, навіть настрій людей, які працюють віддалено тощо). Це вже вищий пілотаж, який дає поле як для суб’єктивних спостережень керівника, так і неупереджених автоматизованих розрахунків.
Епамівцям, зокрема, в цьому сенсі простіше. Окрім довідкової інформації, ми маємо багато зручних внутрішніх ресурсів для роботи з делівері, різноманітними показниками та метриками. Наприклад, є система Delivery Central. Менеджер може регулярно вносити в неї інформацію про стан справ, а відомий «світлофор» спрацює автоматично: покаже, у якій зоні проєкт — у червоній, жовтій чи зеленій. Для калькуляції використовують перелік обов’язкових і необов’язкових показників з внутрішніх систем та полів для власного заповнення (їхній перелік керівник обирає на свій розсуд). Завдяки цій та іншим системам ми поступово переходимо у зону data-driven делівері.
Якщо у вашій компанії такого інструмента немає — не страшно. Відстежувати продуктивність команд і проєктів можна навіть в Excel. Але важливо придумати внутрішню систему, яку візьме в роботу вся компанія. Тоді файл із замальованими у різні кольори проєктами буде дієвим інструментом, щоб бачити ефективність роботи та оновлювати статуси проєктів.
Зауважте: у будь-якому разі важлива культура. Не треба звинувачувати менеджера або команду за певний статус. Краще дивитися на це як на ситуацію, що потребує особливої уваги. Те саме варто транслювати командам. Червоний (або будь-який інший) статус — це не предмет колективного засудження.
Як я вже зазначав, я відповідаю за успіх проєктів і розвиток відносин Epic Games з EPAM Ukraine. Наші команди працюють переважно за Agile і Scrum, а в цих методологіях передбачений механізм ретроспективи. Він дає змогу команді бути продуктивною та вносити корективи, коли це необхідно. Останній рік ми звикли проводити ці зустрічі в онлайн-форматі. Іноді я додаю ретроспективам динаміки завдяки ідеям на сайтах retromat.org, management30 тощо. До речі, для маленьких команд люблю використовувати техніку personal maps (її теж беру на сайті management30).
Щоправда, я вже деякий час зосереджуюся на більш високорівневих завданнях, намагаюся синхронізувати offshore та onsite команди. Знайти вдалий час для ретроспектив та інших зустрічей людям з кардинально різних часових поясів — той ще виклик. Наразі в offshore та onsite команд різні ретро. Лише після них ключові люди з робочих груп збираються на загальну зустріч. Ми вибудовуємо досить складну систему обміну відгуками та рекомендаціями для поліпшення результатів, але, на мій погляд, наближаємось до майже ідеального процесу.
Корисна література
- Патрик Ленсиони «Пять пороков команды»;
- Лисса Адкинс «Коучинг agile-команд»;
- Эндрю Стеллман и Дженнифер Грин «Постигая Agile»;
- Марк Лоффлер «Ретроспектива в Agile»;
- Илан Голдштейн «Scrum без ошибок»;
- Дэвид Андерсон «Канбан»;
- Зузана Шохова «Путь скрам-мастера»;
- Джей Джей Сазерленд «Scrum на практике»;
- Стивен Деннинг «Эпоха Agile».
