Серия «Аналитика в разработке»

После предыдущей статьи я получил массу хейта и фразы типа:

"Да что там делать? Кнопка за десять минут."

И знаете что? Они абсолютно правы. Но только если речь идет не о продуктовом проекте.

Представьте 2 проекта

Проект №1

Есть лендинг и задача "Добавить кнопку" это всего лишь:
1 Сверстать
2 Запушить
3 Готово

Ну сколько на это все надо времени - час максимум, если еще сходить кофейку попить.

Проект №2

1. Есть продукт на котором 100 тысяч пользователей.

2. Работают 40 разработчиков.

3. На проекте 18 микросервисов.

4. Три мобильных клиента.

5. Личный кабинет.

6. API.

7. BI.

8. Яндекс Метрика.

9. Prometheus.

10. Grafana.

11. ClickHouse.

12. PostgreSQL.

13. Redis.

14. RabbitMQ.

15. Интеграции.

16. A/B-тесты.

17. Роли.

18. Логи.

19. Фича-флаги.

И приходит задача.

Добавить кнопку "Скачать отчёт".

И вот здесь-то и начинается самое интересное )

Что такое "кнопка" в продуктовом проекте?

Она должна...

• отображаться только нужным пользователям;

• учитывать тариф;

• учитывать права;

• попасть в аудит действий;

• отправить событие в аналитику;

• попасть в Яндекс Метрику;

• попасть в Google Analytics (если используется);

• записаться в ClickHouse;

• обновить дашборд продукта;

• не сломать мобильное приложение;

• не ухудшить Core Web Vitals;

• работать через API Gateway;

• попасть в документацию;

• покрыться тестами;

• пройти ревью;

• пройти CI;

• пройти staging;

• попасть в production.

• вроде все перечислил )))

И только потом пользователь нажимает кнопку.

И тут конечно вы спросите меня а зачем это все?

Потому что бизнес хотел узнать:

• сколько раз скачивают отчет;

• кто скачивает;

• пользователи какого тарифа скачивают;

• после какого действия скачивают;

• сколько времени проводят перед скачиванием;

• влияет ли новая кнопка на конверсию;

• не падает ли производительность.

И внезапно выяснилось, что стоимость самой кнопки составила процентов пять от всей задачи.

Ну и как резюме: Продукт — это не код.

Продукт — это постоянные ответы на вопросы.

Кнопку нажали?

Хорошо.

А теперь скажите:

• кто?

• сколько?

• когда?

• зачем?

• после какого сценария?

• какая конверсия?

• стало лучше или хуже?

• сколько денег это принесло?

И если вы не можете ответить на эти вопросы...

...значит, вы не сделали продуктовую разработку.

Вы просто написали код ))

Хейтерам - картинки сгенерированы, текст мой )

Наверное, каждый разработчик хотя бы раз слышал эту фразу.

— Да там же небольшое изменение.
— Это буквально на пять минут.
— Просто кнопку добавить.

И почти всегда после этих слов начинается история, которая заканчивается совсем не через пять минут.

"Всего лишь кнопку"

Однажды приходит задача.

Нужно добавить кнопку "Скачать".

Звучит действительно просто. Разработчик открывает проект. Оказывается, дизайн для новой кнопки не готов. Пишет дизайнеру.

Пока ждёт — замечает, что компонент кнопок используется ещё в десяти местах.После обновления дизайна выясняется, что на мобильной версии новая кнопка ломает вёрстку.

Исправили.

Теперь оказывается, что скачивать нечего — API не отдаёт нужный файл. Добавили новый метод.

Потом выясняется, что у некоторых пользователей нет прав на скачивание. Добавили проверку доступа.

После этого QA находит проблему. Если пользователь открывает страницу из закладок, кнопка исчезает.

Исправили.

Затем деплой и уже в продакшене оказывается, что в Safari всё работает иначе.

И конечно же кнопка появилась, но прошёл ДЕНЬ, хотя сама кнопка действительно писалась минут пять.

Код редко занимает большую часть времени

Есть интересное наблюдение.

Когда люди говорят:

"Сделать задачу"

Они представляют именно написание кода. Хотя на практике код — это зачастую лишь небольшая часть всей работы.

Остальное время уходит на:

• понимание задачи;

• поиск нужного места в проекте;

• анализ существующей логики;

• обсуждения;

• изменения API;

• тестирование;

• исправление найденных ошибок;

• код-ревью;

• деплой;

• проверку в продакшене.

Иногда написание самого решения занимает всего 10–20% времени.

Чем старше проект, тем меньше в нём "пятиминутных" задач

На новом проекте действительно можно быстро что-то добавить.

Но когда системе несколько лет...

...любое изменение начинает цеплять другие части.

Добавили одно поле и сломались отчёты.

Исправили отчёты и перестали проходить интеграционные тесты.

Исправили тесты.

Поменялась сериализация и упал мобильный клиент.

Каждый опытный разработчик знает эффект:

маленьких изменений почти не бывает.

Почему разработчики так не любят фразу "на пять минут"

Не потому что ленятся.

А потому что знают, что оценивается только видимая часть задачи.

Никто заранее не видит:

• старые зависимости;

• забытый код десятилетней давности;

• неожиданное поведение;

• сторонние сервисы;

• особенности браузеров;

• ограничения архитектуры.

Это как попросить строителя:

"Да просто стену передвинь."

Пока не начнёшь двигать — не узнаешь, что она несущая.

Как лучше ставить задачи

Вместо:

Это на пять минут.

Лучше сказать:

Посмотри, пожалуйста, насколько это действительно сложно.

Кажется мелочью, но психологически это совершенно другой разговор.

Разработчик перестаёт оправдываться и начинает искать решение.

Самое интересное

За годы работы я заметил одну закономерность.

Когда руководитель начинает использовать выражение:

"Ну это же быстро..."

почти всегда именно эта задача неожиданно становится самой дорогой в спринте.

И не потому что кто-то плохо работает. А потому что сложность разработки редко находится в самом коде.

Она скрывается вокруг него.

Код пишется быстро. Долго приходится разбираться со всем, что этот код затрагивает.

Если вам интересны темы управления разработкой, предсказуемости спринтов и инженерных процессов — иногда пишу об этом здесь. Ещё больше материалов собираю на sprint-intelligence.ru

Когда я был разработчиком и писал свои проекты, для меня всё было просто. Написал код. Проверил. Смёржил. Всё, задача готова. Потом стал тимлидом.

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

Пока продукт посмотрит и скажет: «Я вообще не это имел в виду».

И самое интересное — разработчик в этот момент уже считает задачу завершённой.

Из-за этого почти в каждой команде возникает одна и та же проблема.

Разработчики говорят:

Мы сделали 20 задач.

Менеджер отвечает:

А пользователи получили только 12.

И ведь оба правы.

С тех пор я перестал считать задачей то, что лежит в колонке "На ревью".

И даже "Готово к тестированию" — ещё не готово.

Для меня задача заканчивается только тогда, когда её можно показать пользователю без слов:

«Тут есть пара нюансов...»

Смешно, но именно эта разница чаще всего и объясняет, почему команда уверена, что всё идёт по плану, а бизнес — что разработка постоянно задерживается.

Они просто по-разному понимают слово «готово».

А у вас в команде когда задача считается завершённой?

• После merge?

• После тестирования?

• После выкладки?

• Или только после того, как ей реально начали пользоваться?

P.S. Если вам интересны темы про управление разработкой без корпоративной мишуры — иногда пишу об этом и делаю сервис Sprint Intelligence для команд разработки.

Начинается вторая неделя спринта, утренний дейли и тут я слышу фразу:

• У нас все под контролем
  И я ловлю себя на мысли, что именно после таких слов обычно начинается самое интересное.

Когда я много лет назад начинал работать разработчиком, я думал что мой руководитель знает все. Он же руководитель, он видит все ситуации со всех сторон. И он понимает полную картину.
А потом я сам стал руководителем разработки и оказалось что большая часть информации о проекте приходит не из системы а из разговоров.
Звоню фронтендеру:

• Саш, что у тебя по задаче?

• Почти готова, немного осталось.

• Когда закончишь?

• Думаю, завтра.

• Помощь нужна?

• Пока нет.

На следующий день выясняется что задача уперлась в бэкенд, потом в ревью, через день узнаю что задача уперлась в аналитика. Еще через 2 дня оказывается что проблема вообще в инфраструктуре.
И ведь никто не соврал, каждый видел свой маленький кусочек проекта и все искренне считали, что "все под контролем".

Как в старом фильме:

К пуговицам претензии есть?

К пуговицам претензий нет — пришиты насмерть.

Но со временем я начал замечать некоторую закономерность.
Чем чаще на проекте звучит фраза «У нас всё под контролем», тем меньше там объективных данных.

Потому что если действительно все под контролем, то за пару минут это можно показать цифрами:

• сколько задач сейчас в работе;

• где появились очереди;

• что тормозит релиз;

• какие задачи уже выходят за ожидаемые сроки;

• где перегружена команда.

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

И вот именно из таких ситуаций и родилась идея Sprint Intelligence. И мне совсем не хотелось делать еще один сервис.
Мне хотелось открыть одну страницу и за минуту понять, что происходит с разработкой на самом деле, без десятка сообщений в чате и бесконечных уточнений.

Если вам тоже не хватает прозрачности в работе команды, посмотрите демо

Буду рад любой обратной связи — проект еще развивается, и многие идеи появляются именно из таких обсуждений.