Привет!
В Skyeng мы стремимся принимать решения на основе данных. Если в управлении продуктами этот подход широко распространен – проведение А/В тестов, сбор продуктовых метрик, исследование клиентов и т.д., то в разработке дела обстоят иначе)
Пока удалось интегрировать этот подход в следующих аспектах:
📌 Прогнозировать стоимость инфраструктуры, чтобы, с одной стороны, обеспечить необходимые мощности для роста бизнеса, с другой, – не тратить лишних денег.
📌 Оптимизировать процессы внутри компании для достижения баланса между скоростью и качеством разработки
📌 Настроить поиск и анализ причин текучки сотрудников через сбор объективных и субъективных метрик
Однако, любое упоминание о метриках в среде разработчиков вызывает у коллег тревожность. Дескать, если начали собирать метрики, то они попадут в личные KPI, а стало быть придется ломать голову над достижением “красивых” цифр в отчете.
Например, недавно мы собрали метрику Lead Time – время от создания до решения задачи. Главное возражение коллег было в том, что им невыгодно закрывать старые задачи, т.к. метрика будет портиться. Но ведь метрики не тождественны KPI, они помогают оцифровывать любой процесс с разных сторон – управляемости, предсказуемости, динамики и т.д.
Ключевое слово здесь оценивать, т.к. любая метрика никогда не будет точной на 100%. То, что при закрытии старых задач у какой-то команды вырастет Lead Time не говорит о том, плохо это или хорошо. Она лишь объективно показывает ситуацию в команде, а уже тимлид будет решать, стоит ли что-то менять в процессах или нет.
Одним словом, не бойтесь собирать метрики, они помогают объективно оценивать вашу зону ответственности и принимать качественные решения. При этом в KPI целесообразно ставить только те метрики, которые хорошо провалидированы и с высокой точностью оценивают процесс, его пороговые значения, а сам процесс хорошо управляем.
Лично мне поменять майндсет в этом направлении помогли эти книги:
1. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе
2. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта
Надеюсь, и вам пригодится 💪
В Skyeng мы стремимся принимать решения на основе данных. Если в управлении продуктами этот подход широко распространен – проведение А/В тестов, сбор продуктовых метрик, исследование клиентов и т.д., то в разработке дела обстоят иначе)
Пока удалось интегрировать этот подход в следующих аспектах:
📌 Прогнозировать стоимость инфраструктуры, чтобы, с одной стороны, обеспечить необходимые мощности для роста бизнеса, с другой, – не тратить лишних денег.
📌 Оптимизировать процессы внутри компании для достижения баланса между скоростью и качеством разработки
📌 Настроить поиск и анализ причин текучки сотрудников через сбор объективных и субъективных метрик
Однако, любое упоминание о метриках в среде разработчиков вызывает у коллег тревожность. Дескать, если начали собирать метрики, то они попадут в личные KPI, а стало быть придется ломать голову над достижением “красивых” цифр в отчете.
Например, недавно мы собрали метрику Lead Time – время от создания до решения задачи. Главное возражение коллег было в том, что им невыгодно закрывать старые задачи, т.к. метрика будет портиться. Но ведь метрики не тождественны KPI, они помогают оцифровывать любой процесс с разных сторон – управляемости, предсказуемости, динамики и т.д.
Ключевое слово здесь оценивать, т.к. любая метрика никогда не будет точной на 100%. То, что при закрытии старых задач у какой-то команды вырастет Lead Time не говорит о том, плохо это или хорошо. Она лишь объективно показывает ситуацию в команде, а уже тимлид будет решать, стоит ли что-то менять в процессах или нет.
Одним словом, не бойтесь собирать метрики, они помогают объективно оценивать вашу зону ответственности и принимать качественные решения. При этом в KPI целесообразно ставить только те метрики, которые хорошо провалидированы и с высокой точностью оценивают процесс, его пороговые значения, а сам процесс хорошо управляем.
Лично мне поменять майндсет в этом направлении помогли эти книги:
1. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе
2. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта
Надеюсь, и вам пригодится 💪