Dev Easy Notes

Только вернулся из отпуска – и сразу наткнулся на процесс ревью: отзывы, результаты задач и всё такое. Вообще, это интересный период, чем-то напоминает сессию в универе или школьное сочинение "Как я провёл лето".

С результатами задач у меня часто возникают проблемы, потому что порой очень сложно придумать метрику, которая реально показывает, насколько наша работа была полезной. В фича-командах этим обычно занимаются отдельные люди (аналитики), а в техкомандах приходится думать самим.

Бизнес обожает метрики и цифры. Нужно всегда показывать: "до задачи было X, а после стало 3X". И никого не волнует, что иногда эти цифры вообще ничего не значат для реальности.

В корпоративном мире есть забавный парадокс: если провести достаточно времени в Grafana или другой системе метрик, всегда найдёшь показатели, по которым у команды всё офигенно, и такие, по которым вас вот-вот уволят, а отдел расформируют к херам.

В итоге получаем две крайности:

👉 Мы не собираем никаких метрик и вообще не понимаем, делаем ли мы лучше или только вредим.
👉 Мы собираем всё подряд и в итоге сами себя путаем.

Я нашел несколько советов, которые помогают не отрываться от реальности и вообще выжить в корпоративном мире:

👉 Думать о метриках ещё до старта задачи. Желательно уже на этапе проектирования спросить себя: "Как мы поймём, что не сделали фигню?" Совет банальный, но на практике это, пожалуй, самая сложная часть. Зато потом проще на всяких ревью.

👉 Использовать научный метод. Сначала выдвигаем гипотезу, а потом проверяем её данными. В IT часто делают наоборот: собирают тонны данных через A/B-тесты, а потом из этого хаоса что-то пытаются понять.

👉 Пробовать опровергнуть себя. Когда получаешь данные, очень хочется их "подогнать" под хороший результат. Но полезнее наоборот – попытаться найти слабые места и раскритиковать себя. Если не выходит – значит гипотеза реально рабочая.

236❤1🤔1

www.tgoop.com/dev_easy_notes/512

2.28K viewsedited  Aug 28 at 09:36

Только вернулся из отпуска – и сразу наткнулся на процесс ревью: отзывы, результаты задач и всё такое. Вообще, это интересный период, чем-то напоминает сессию в универе или школьное сочинение "Как я провёл лето".

С результатами задач у меня часто возникают проблемы, потому что порой очень сложно придумать метрику, которая реально показывает, насколько наша работа была полезной. В фича-командах этим обычно занимаются отдельные люди (аналитики), а в техкомандах приходится думать самим.

Бизнес обожает метрики и цифры. Нужно всегда показывать: "до задачи было X, а после стало 3X". И никого не волнует, что иногда эти цифры вообще ничего не значат для реальности.

В корпоративном мире есть забавный парадокс: если провести достаточно времени в Grafana или другой системе метрик, всегда найдёшь показатели, по которым у команды всё офигенно, и такие, по которым вас вот-вот уволят, а отдел расформируют к херам.

В итоге получаем две крайности:

👉 Мы не собираем никаких метрик и вообще не понимаем, делаем ли мы лучше или только вредим.
👉 Мы собираем всё подряд и в итоге сами себя путаем.

Я нашел несколько советов, которые помогают не отрываться от реальности и вообще выжить в корпоративном мире:

👉 Думать о метриках ещё до старта задачи. Желательно уже на этапе проектирования спросить себя: "Как мы поймём, что не сделали фигню?" Совет банальный, но на практике это, пожалуй, самая сложная часть. Зато потом проще на всяких ревью.

👉 Использовать научный метод. Сначала выдвигаем гипотезу, а потом проверяем её данными. В IT часто делают наоборот: собирают тонны данных через A/B-тесты, а потом из этого хаоса что-то пытаются понять.

👉 Пробовать опровергнуть себя. Когда получаешь данные, очень хочется их "подогнать" под хороший результат. Но полезнее наоборот – попытаться найти слабые места и раскритиковать себя. Если не выходит – значит гипотеза реально рабочая.

BY Dev Easy Notes