Тому багато людей говорять про прийняття рішень на основі даних, KPI – це нова тенденція, проте багато компаній та організацій продовжують переживати почуття.
Я завжди хотів бути частиною компанії, яка вимірювала, як виглядає успіх. Ми всі бачили цитати, які звучать приблизно так: “Якщо ти не можеш виміряти, ти не можеш це покращити”. Тому, коли я почав працювати в DAIS, я вирішив, що хочу, щоб відділ технологій відстежував KPI, щоб ми могли вимірювати та вдосконалювати.
Просто починай це робити
Перша справа, яку ви можете зробити, щоб почати відстежувати KPI і стати керованим даними … просто починайте це робити! Є багато причин / виправдань, щоб не робити цього; це займає занадто багато часу, у нас немає інфраструктури, ми не можемо визначити кількісні показники тощо. Але насправді завжди є речі, які можна виміряти; користувачів, дохід, квитки на підтримку … дані є. Якщо ви хочете це відстежити, вам просто потрібно заскочити.
Для початку вам потрібно лише 2 речі
Список речей для відстеження
Я отримав потенційних клієнтів від наших різних відділів, разом із QA, Data, Engineering, Automation, Product, UX, DevOps та Customer Success, і я мав кожну із 3-6 метрик, які ми можемо відстежувати на дошці. Престо, ми не працювали, це було так просто.
Як вибрати правильні показники ефективності?
Думаю, можна написати цілу статтю про те, як вибрати, що слід відслідковувати, але мова йде про швидкий вихід з місця. Якщо ваша організація тільки починає використовувати KPI, я рекомендую просто вибрати кілька показників, які, як ви знаєте, можете відстежувати. Прислухайтеся до своїх потенційних клієнтів, виберіть KPI, на які ви не знаєте відповіді, KPI, за якими відділ хоче вимірювати. З часом ви можете прив’язати їх до OKR або побачити співвідношення ваших KPI зі значенням, яке вони приносять вашій організації. Виберіть кілька KPI, потім повторіть, повторіть, повторіть.
Місце для запису ваших показників
Це може бути просто, як аркуш паперу або аркуш Google. Ми зробили щось більш досконале, коли створили власні служби метрик. Ми витримали InfluxDB, додали підтримку протитиску та викрили деякі API. Усі наші додатки та конвеєри побудови тепер пишуть до нашої служби метрик, надаючи нам метрики в режимі реального часу, ідеально підходять для відстеження KPI. Ми застосували більш просунутий підхід, але ви можете використовувати що завгодно. Не дозволяйте досконалості заважати прогресу. Просто зробіть щось.
Те, що ми відстежували
За останні 6 місяців ми відстежили 36 KPI.
8 так і не зірвалися з місця, у нас не було засобів відстежити їх (про це пізніше).
Кожні 2 тижні на нашому щотижневому початковому етапі ми показували всі ключові показники ефективності всій компанії, і у нас був керівник відділу, який виховував принаймні одну тенденцію. Це було надзвичайно інформативно, компанія змогла побачити, як працюють відділи, і ми мали б обговорювати різні теми, наприклад, як зростає охоплення коду, як скорочується час підтримки клієнтів або чому повідомляється про збільшення кількості помилок. Потім ми використовували ці ключові показники ефективності для визначення галузей, які нам потрібно було вдосконалити.
Кілька речей, які ми зробили:
Ми покращили покриття нашого автоматизованого тестового коду на 40%. Ми помітили, що цей показник нам не сподобався, тому ми цілий спринт присвятили підвищенню покриття коду. Для деяких наших масштабніших зусиль виявилося корисним бути впевненими у змінах, які ми вносили.
Зобов’язання щодо швидкості спринту / Передбачувано зросли на 15% з 67% до 82%. Фактична швидкість команди може варіюватися в залежності від команди залежно від багатьох факторів (наприклад, розміру команди, розміру історій тощо), але для мене важливо те, наскільки точна і передбачувана команда. Найкращі команди – це передбачувані команди, вони здатні розбити проблеми і зрозуміти, що вони можуть отримати. Ми зрозуміли, що наші команди набирають занадто багато очок, навіть після того, як у нас була відома швидкість, ми дозволили командам брати більше. Побачивши ці цифри, ми посилили те, що дозволили взяти участь у спринті. Після внесення цих змін купа наших команд почала ставати майже на 100% передбачуваною. Це насправді допомогло нам оцінити наші проекти та дозволити нам покращити дорожні карти.
Час відгуку клієнтів на наших клієнтів тривав від 1 дня до 1 години. Ми помітили, що не реагуємо досить швидко на наших клієнтів. До того, як ми побачили ці номери, у нас було кілька людей, які відповідали за спілкування з нашими клієнтами. Ми зрозуміли, що для цього потрібна віддана людина, інакше легко проскочити крізь щілини. Одного разу, коли ми присвятили штатну людину, ми побачили значне покращення.
Оцінка задоволеності команди зросла з 60% до 82%. Ми виявили прогалини в процесі планування та вдосконалили ці процеси, створюючи історії з більшою ясністю, зрештою, даючи людям більш чітку роботу та цілі. Ми посилили акцент на залежностях та спілкуванні між нашими командами. Все це покращило робоче середовище.
Тож ми змогли підвищити довіру та якість нашого коду, зробили наших клієнтів щасливішими, а наших співробітників щасливішими. Непоганий результат.
Що ми дізналися
По-перше, ми дізналися цінну інформацію про наші відділи. Де ми досягали успіху, а де боролись. Ми також дізналися, що відстежували занадто багато речей. 36 KPI уперше було занадто багато речей, щоб піти за ними. Ми вибрали деякі ключові показники ефективності, які в даний час не мали засобів для відстеження, такі як причини збою побудови, а деякі ключові показники ефективності були навколо продукту, який ще не запущений. Якщо у вас немає засобів відслідковувати це, можливо, непогано поки що триматися подалі від нього і з’ясувати, яку роботу потрібно провести в наступному кварталі, щоб це зробити.
Крім того, ми дізналися, що це не зайняло стільки часу. Багато наших показників відстежувались автоматично в JIRA для ключових показників ефективності, таких як час підтримки клієнтів та кількість блокувальників, або в нашій службі показників (InfluxDB) для KPI, таких як охоплення коду. Але це вимагало невеликої ручної роботи, щоб зібрати їх усіх, щоб їх побачила вся компанія. У цілому розуміння, безумовно, коштувало витраченого часу. Вам потрібно змусити людей володіти своїми показниками та створювати цю культуру власності. Кожен керівник відділу був готовий отримати свої метрики, це також допомогло нам мати когось, хто координував і володів усіма зусиллями, для нас це була Джессі, наш спритний тренер. Вона мала безцінне значення для того, щоб цей проект працював.
Як ми вдосконалюємось
Ви не тільки використовуєте KPI, щоб впливати на те, як ви можете вдосконалитись, але вам також потрібно продовжувати вдосконалювати процес KPI. Ми знизили кількість KPI з 36 до 25. Ми вирішили відстежувати менше KPI, з більшим акцентом на ті, на які ми хочемо впливати безпосередньо. Я дуже радий нашим розробницьким KPI за рік. Ми використовуємо ідею з книги “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technologies Organisations”, вони провели дослідження про те, як відстежувати продуктивність розробників, я впевнений, що цікавить більшість інженерних управлінь. Вони зрозуміли, що найкращі команди часто відправляють код, доставляють його швидко, і завдяки цій постійній доставці відмінна команда не розбиває багато речей, і коли це робить, вона може це швидко виправити. отримати базову лінію, яку ми можемо потім покращити.
Ось наш стислий список, який ми відстежуємо в цьому кварталі:
Dev – Розгортання на день для кожного середовища
Dev – як швидко наш код надходить до наших клієнтів
Dev – Час між зеленими збірками
Dev – коефіцієнт проходження інтеграційного тестування в середовищі розробника
Автоматизація – Покриття коду
QA – # P1 та P2 кожного місяця для кожного товару
Agile – швидкість для всіх розробників
Agile – середній коефіцієнт влучень для команд
Agile – # заблоковані елементи
Спритний – Командне щастя
Продукт – коефіцієнт враження зовнішньої віхи для всіх продуктів
Продукт – історія часу виконання всіх продуктів
Продукт – обхват повзучості для всіх продуктів
Товар – кількість користувачів на товар
Товар – # транзакції за товар
DevOps – # запитів DevOps виконано
DevOps -% спринтерських робіт DevOps закінчено
DevOps – тривалість роботи програм
Підтримка – Загальна кількість поданих / відкритих квитків
Підтримка – загальна кількість вирішених квитків
Підтримка – Середній час початкового відгуку від служби підтримки DAIS (хв)
Підтримка – Середній час до вирішення (хв)
Підтримка – Активність користувачів на додаток
UX – час виконання історії
Продуктивність – GSD (Get Sh t Done) Прихильність% – Більше про це в наступному дописі
Просто почніть
Будучи частиною компанії, яка відстежує показники, можна постійно вдосконалюватися. Почавши відстежувати ключові показники ефективності, ви отримаєте базовий рівень того, як ви виконуєте та приносите цінність для своєї компанії. Ще однією перевагою наявності фреймворку для відстеження метрик є те, що ви завжди можете просто додати інший, якщо хтось хоче щось знати, ви можете просто почати його відстежувати, це так просто. Припиніть ходити по кишечнику, припиніть виправдання, чому ви не можете відстежувати KPI. Просто починай!
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/its-simple-become-kpi-driven-organization-start-making-goldstein/.
Michael Goldstein люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 