Про связь технических задач и бизнеса

В прошлом посте я писал про то, как полезно менеджеру строить связь между техническими задачами и бизнес-метриками. Такая связь нужна, как минимум, для:
1. Прозрачности пользы, которую приносит продукт/команда
2. Вдохновения команды - люди лучше понимают свой вклад
3. Приоритезации в условиях ограниченных ресурсов - проще сфокусироваться на наиболее полезных задачах.
В этом посте поговорим про то, как именно строить такую связь.

Условно "идеальным" мерилом важности задачи являются деньги. Чем больше задача позволяет зарабатывать или экономить в конечном итоге, тем она важнее и срочнее. Однако в большинстве технических задач влияние на деньги неочевидно, мягко говоря. Нельзя просто взять и оценить сколько рублей нам принесёт, например, переделка фреймворка для автотестов или ускорение ответа от веб-сервиса на 300 мс. Да и оценивать все задачи в деньгах довольно утомительно, если это делать хотя бы с какой-то точностью.

Однако отсутствие денежной оценки не делает задачу бесполезной т.к. понятно, что она приносит пользу другим способом. И у этой пользы с большой вероятностью есть какая-то метрика, которая позволяет более объективно заценить пользу.

Для примера давайте возьмём пример с переделкой фреймворка автотестов для какой-то системы.
Какая польза от этой задачи? На кой её вообще делать? Если сказать по-простому, то, например:
1. Чтоб тесты быстрее проходили
2. Чтобы код был более понятным
3. Чтобы проще был расширять функционал.

Неплохо, цели благие. Но какие метрики могут быть у этих целей? Другими словами, на какие метрики непосредственно влияет выполнение этих целей?
1. Чтоб тесты быстрее проходили -> Сокращается время прогона тестов
2. Чтобы код был более понятным -> Сокращается время онбординга новых QA в проект + сокращается кол-во багов в тестах
3. Чтобы проще был расширять функционал -> Сокращается время время написания новых автотестов.

Так. Становится понятнее? Теперь мы знаем, какие метрики объективно покажут пользу от этой задачи (или бесполезность). Но где тут бизнес-метрики? Где тут денежки?

И вот тут основной переход: вам не обязательно строить связь этих метрик прямо до каких-то рублей. Достаточно достроить связь с какой-то понятной бизнесу метрики и вся дальнейшая цепока будет основываться именно на ней.
Это как оценивать вклад мощности строительнго миксера при постройке дома. Сложно оценить напрямую экономию от мощного миксера, но вы можете прикинуть пользу через экономию на времени рабочего и, вуаля, вы уже примерно понимаете сколько денег вам сэкономит миксер. Понятно, что пример утрированный, но, надеюсь, суть понятна.

Так вот, возвращаясь к нашему примеру с фреймворком автотестов. Как видно, все они влияют на время, которое входит в общее время цикла разработки. Т.е. с этими автотестами разработка должна ускориться. И в этом главная ценность этой задачи!
Для измерения времени разработки давно существует метрика Lead Time и её старшая сестра TTM (Time to Market, но она больше про общее время выпуска фичи, не только про разработку).

Таким образом, переделка фреймворка тестирования сделает разработку быстрее, и это будет видно на метриках Lead Time и TTM. С этими метриками бизнесу работать уже намного проще т.к. стоимость времени разработки, как правило, понятна и её сокращение можно посчитать. Через эти метрики можно обсуждать приоритет с "бизнесменами".

Естественно, приведенный пример не идеален, как и разбор всей этой цепочки, но я надеюсь, что у меня получилось показать принцип построения связи технических- и бизнес-метрик. В моем примере задача помогает экономить на времени разработки.