Что значат метрики для Agile команд?

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

Многие пытаются понять, что же такое «лучшая практика» в отрасли, и наложить её на свой продукт, чтобы улучшить свои собственные показатели. Некоторое время я размышлял над тем, существует ли такое универсальное и эффективное решение.

Организации склонны копировать «то, что сработало для других», даже не заботясь об ограничениях и условиях, в которых конкретная метрика работала на «других».

Тогда, что измерять? На мой взгляд, организации, которые поняли, что и сколько измерять в продукте, выжили и процветают до сих пор. Они в конечном итоге стали Agile-организациями. Когда у них несколько продуктов, у них разные подходы для каждого из них. Некоторым продуктам потребуется много статистики и данных, в то время как некоторым понадобиться лишь пара метрик!

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

Опять же, каждый должен определять свое «работающее» программное обеспечение по-разному. Поэтому очень важно иметь целостное представление о том, кем является заказчик, кто разработчик, кто спонсор и, кто управляет процессом. Попробуем рассмотреть процесс со стороны каждого из них.

Business/Product Owner/Product Manager

В функциональной Agile команде эта роль в первую очередь отвечает за понимание рынка и синтез данных. PO имеет «гипотезу» о том, что делает организацию прибыльной. Когда все что ты имеешь, — это гипотеза, то очень важно найти правильные метрики. Следующие показатели могут быть необходимыми:

1. Cost of Delay: это влияние времени на результаты, которые мы надеемся достичь. Это ответ на вопрос: «Что мы потеряем (что нам будет стоить), если сделаем это на 1 месяц позже». Или, «что мы получим, если сделаем это на 1 месяц раньше?»
2. Product/Market Fit (PMF): это соответствие продукта ожиданиям целевой аудитории. Когда у вас есть продукт, удовлетворяющий потребности конкретного рынка, и без которого ваша аудитория многое потеряет, это называется Product/Market Fit.
3. Riskiest Assumption Test (RAT): это тест наиболее рискованного допущения. Для его проведения нет необходимости делать что-то большее, чем требуется для проверки вашего самого большого риска. Не нужно совершенного кода или дизайна. Только проверка рискованного допущения с показателями. После его оценки принимается решение, а стоит ли продолжать проект.
4. Minimum Viable Product (MVP): версия нового продукта, которая позволяет команде удовлетворить максимальное количество потребностей клиента с наименьшими усилиями. Это продукт с достаточным количеством функций для удовлетворения ранних клиентов, для обеспечения обратной связи и для дальнейшего развития продукта.
5. Minimum Marketable Product (MMP): описывает продукт с наименьшим возможным набором функций, который удовлетворяет потребности первоначальных пользователей (новаторов и ранних пользователей) и, следовательно, может продаваться. MMP — это инструмент, позволяющий сократить время выхода на рынок: его можно запустить быстрее, чем насыщенный, многофункциональный продукт.
6. Cycle Time: время цикла — общее время с момента начала работы над новой фичей, таском, багом и до его завершения. Время цикла включает в себя время самого процесса и время задержки, в течение которого часть работы расходуется, ожидая выполнения следующего действия.

Группа «Product» должна иметь механизм для понимания и отслеживания показателей, которые важны для Спонсоров / Инвесторов. Это позволит убедиться, что цикл закрыт, и любое предложение «Pivot» обосновано.

Sponsor/Investor

Эту группу интересуют те же метрики, которые используют Business/Product Managers до запуска продукта. Следующие метрики наиболее важны во время и после запуска продукта:

1. Employee Satisfaction: более счастливые и мотивированные сотрудники, сами следят за тем, чтобы клиент был счастливым и был вовлечен в процесс. Удовлетворенность сотрудников — это терминология, используемая для описания того, довольны ли сотрудники и выполняют ли они свои желания и потребности на работе. Удовлетворенность сотрудников — это фактор мотивации сотрудников, достижение цели сотрудника и позитивный моральный дух сотрудников на рабочем месте.
2. Viral coefficient: это число, которое говорит вам, сколько клиентов каждый из ваших клиентов приводит к вам в бизнес. Таким образом, это означает, что если ваш вирусный коэффициент равен 2, то каждый ваш текущий клиент привлекает 2 клиента. Эта метрика вычисляет экспоненциальный цикл обращения, иногда называемый virality, который ускоряет рост компании. Virality является неотъемлемым стимулом для клиентов направлять друзей или коллег в вашу компанию.
3. Sunk Costs: в экономике и принятии бизнес-решений, Невозвратные издержки — это затраты, которые уже были понесены и не могут быть восстановлены. Невозвратные издержки иногда контрастируют с предполагаемыми расходами, которые представляют собой будущие затраты, которые могут быть понесены или изменены, если действие будет предпринято.
4. Viral Cycle Time: время вирусного цикла — это время, необходимое для завершения одного такого цикла. Другими словами, время вирусного цикла — это время, необходимое пользователю для приглашения другого пользователя.
5. Net Promoter Score: (NPS) — это инструмент управления, который можно использовать для оценки лояльности отношений с клиентами фирмы. Он служит альтернативой традиционным исследованиям удовлетворенности клиентов и утверждает, что они коррелируют с ростом доходов. Оценка Net Promoter рассчитывается на основе ответов на один вопрос: Насколько вероятно, что вы порекомендовали бы нашу компанию / продукт / услугу другу или коллеге? Скоринг для этого ответа чаще всего основан на шкале от 0 до 10. Те, кто отвечает с результатом от 9 до 10, называются промоутерами. Те, кто отвечает счетом от 0 до 6, помечены как «Detractors». Ответы 7 и 8 обозначаются пассивами, и их поведение встает в середине Промоутеров и Детракторов. Оценка Net Promoter рассчитывается путем вычитания процента клиентов, которые являются Детракторами, из процента клиентов, которые являются Промоутерами. В целях расчета показателя NPS пассивы учитываются в общем числе респондентов, тем самым уменьшая процент Детракторов и промоутеров и подталкивая чистый балл к 0.
6. Customer Happiness Index (CHI): вместо использования NPS организация также может создать собственный индекс счастья клиента, включая параметры, которые он хочет измерить. Такой подход имеет преимущество, поскольку организация должна «поговорить с клиентом» и может понять параметры, которые необходимы для его контекста.
7. % Paying Customers: понимание того, сколько людей использует платный продукт/услугу в общей клиентской базе, помогает нам лучше понять рынок.
8. Conversion Rate: суть воронки конверсии заключается в том, что вы начинаете с потенциальных клиентов, затем они проявляют интерес, а затем конвертируются в лидов, которые затем превращаются в продажи. Рассчитывается процентное преобразование на каждом шаге. Общий коэффициент конверсии воронки продаж определяется тем, что количество продаж делится на количество потенциальных клиентов и умножается на 100.
9. Customer Acquisition Cost: CAC можно рассчитать, просто разделив все затраты на приобретение большего количества клиентов (маркетинговые расходы) на количество клиентов, приобретенных за период, в течение которого были потрачены деньги. Например, если компания потратила 100 долларов на маркетинг в год и приобрела 100 клиентов в том же году, их CAC составляет 1 доллар.
10. Customer Stickiness. Липкость клиентов — это увеличенный шанс использовать тот же продукт или услугу, которые были куплены за последний период времени.

Developer / Builder

К сожалению, большинство пытается мерить продукт именно здесь. В то время как метрики и показатели здесь дают вам ответ на вопрос «разрабатываем ли мы продукт правильно?», и не гарантируют, что мы разрабатываем правильный продукт. Метрики, которые описаны в этом разделе всегда должны дополнять те показатели, о которых мы говорили в предыдущих разделах. Это те метрики, которые говорят, что мы правильно применили методологии Agile. Эта группа ориентирована на технологию и, следовательно, метрики носят более технический характер. Некоторые из показателей, которые могли бы помочь понять «правильно ли мы ведем разработку»:

1. Health of CI/CD pipeline: правильны ли сборки? Являются ли они достаточно быстрыми, чтобы команды могла с ними поэкспериментировать?
2. Number of Green builds per day/week: Дисциплина в команде, ежедневная проверка кода, и частота сборки. Команда может работать небольшими группами, поскольку они знают, что последний логический фрагмент кода, который они отправили, работает.
3. % of green builds: важно не только количество сборок, но и сколько из них были качественными. Хороший разработчик не хочет, чтобы другие застревали из-за него.
4. Unit Test Coverage: соблюдение Agile Test Pyramid — единственный способ оказаться в быстрой зоне разработки продукта. Unit tests должны составлять ~ 80% всех тестов.
5. Code Coverage: охват кода — это термин для описания того, какой код, выполняется приложением. Чтобы понять, какой код востребован, а какой нет.
6. Non-Functional Test Coverage. Важно понимать нефункциональные требования, часто называемые «ility tests» (юзабилити, доступность, надежность и т. д.), поскольку рынок или клиент на прямую не будут спрашивать нас о нефункциональных требованиях.
7. Benchmarking of NFR’s: бенчмаркинг — важная часть понимания того, чего мы можем достичь. Обычно за образец принимают «лучшую» продукцию и маркетинговый процесс, используемые прямыми конкурентами и фирмами, работающими в других подобных областях, для выявления фирмой возможных способов совершенствования её собственных продуктов и методов работы.
8. Defects found per unit of Unit/Functional/Integration Test: хотя количество дефектов может не указывать на что-либо существенное, они замедляют нас при разработке.
9. Number of defects per feature from Production/UAT/Customer: в большинстве случаев Фича является тем, за что клиент платит. Понимание важных функций и уверенность в том, что они построены с качеством, заставляет разработчиков системы больше сосредоточиться на том, где это действительно важно.
10. Defects that can be lived with: Не все дефекты критичны! Обратите внимание на самые важные и проводите как можно меньше времени с другими. Часто важен именно работающий релиз и совершенствование не всегда является правильным решением.
11. Rework: мы проводим много времени на доработку, времени которое может быть использовано для «работы». Такие практики, как Split-testing, Pair Work (например, Dev-Test, Test-Documentation и т. д.), отдельные среды, тестирование и исправление разработчиком, могут помочь командам избежать затрат на исправления последующих дефектов.

Customer/User

Человек, для которого мы создаем решение, также является частью системы. Клиенты могут понять и могут не понять какие-либо цифры, измерения и метрики. Они хотят, чтобы их проблемы решались легко, и сами не хотят сильно вникать в этот процесс. Мы не должны создавать им стресс. Организации или предприниматели, которые понимают вышенаписанное заявление и работают над ним наиболее успешны!

Резюме:

В реальном мире мы можем разграничивать разные роли, как я это сделал здесь, а можем и не разграничивать. Необходимо проявлять осторожность, чтобы понимать «что», «когда» и «сколько» и всегда учитывать обстоятельства и ограничения в которых работает продукт. Большинство метрик говорили о том, что важно быть связанным с клиентом, и крайне важно, чтобы мы приняли эту точку зрения с первого шага, который мы предпринимаем для создания продукта или услуги.

Об авторе:

Ashwinee Kalkura's qualifications include SPC4, PMP, CSM, CSP, SA, SASM, SSM, ICP-ACC and SSGB professional certifications. He has a progressive experience of 16 years in Networking, Mobile and Retail industry and multiple methodologies. Ashwinee is currently working as Head of Agile & SAFe consulting at KnowledgeHut. He has delivered SAFe training for 450+ candidates in APAC region.