НОУ ІНТУІТ, Лекція, Оцінка

9.2. Перехід від оцінки до зобов'язань

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

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

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

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

Scrum-команда та сучасні організації повинні вміти відокремлювати оцінки від зобов'язань. Оцінка завжди первинна, а вже після, ґрунтуючись на мірі впевненості, досвіді, навичках, ми можемо перетворити її на певне зобов'язання.

Але без надійної початкової оцінки будь-яке зобов'язання команди буде позбавлене будь-якого сенсу. Щоб отримати надійну оцінку, власник і Scrum-команда повинні мати всі необхідні для цього дані:

обсяг роботи, яку належить виконати;
фактори, що впливають на темп виконання командою роботи, і, як наслідок, динаміка виконання завдань у спринті.

Спочатку при впровадженні Scrum практикується оцінка у вигляді діапазону, потім, у міру зрілості, команда зможе перейти до точкової оцінки, яка використовуватиметься як зобов'язання.

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

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

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

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

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

9.3. Збалансована система показників Scrum-команди

Варіант комплексного погляду процеси сучасної компанії призвів до створення збалансованої системи показників ( ССП ).

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

Мета ССП полягає в аналізі не стільки фінансових метрик функціонування підприємства, скільки у розгляді чотирьох процесних напрямів (фінанси, клієнти, процеси, навчання та зростання), що сукупно представляють основу діяльності кожного підприємства.

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

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

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

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

Операційна досконалість:

Створення продукту з максимальною продуктивністю.

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

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

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

Слід зазначити три основні переваги, які дає збір показників:

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

Збалансована система показників повинна бути не "мертвою" системою показників, а живою та динамічною процесною framework, результати якої, накопичені у вигляді масиву інформації, дозволять прогнозувати з високою ймовірністю точні результати діяльності команди, залежно від певної кількості наявних ресурсів.

9.4. Напрацьована статистика результатів - фундамент прогнозування та перемог

Висока швидкість роботи команди має скластися відповідно до історичних передумов роботи команди.

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

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

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

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

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

9.5. Короткі висновки

Вміння складати ефективні плани – дуже важлива якість для будь-якої Scrum-команди. У цьому розділі ми розглянули способи, за допомогою яких команда, яка освоїла основи планування та оцінки трудомісткості спринтів, може покращити свої результати. Крім того, ми дійшли висновку про те, що поняття оцінки та зобов'язань, що надаються командою та сприймаються менеджментом компанії, відрізняються ступенем відповідальності. Усі команди, які досягли потрібного рівня зрілості та самоорганізації, повинні прагнути давати обґрунтовані зобов'язання і надалі дотримуватися їх.

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

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