Я перестал закрывать тикеты. Стал закрывать риски.
Три года назад я мог с гордостью показать 40 закрытых тикетов за спринт. Клиент всё равно был недоволен.
Не потому что я плохо работал. Потому что я решал не те проблемы.
Тикеты — это задачи, которые кто-то сформулировал вчера. Риски — это то, что убьёт проект послезавтра. Первые хорошо считаются в Jira. Вторые там почти не живут.
Это разница в мышлении — то, что принято называть owner mindset разработчика.
Иллюзия продуктивности
В большинстве команд производительность измеряется через velocity: сколько story points закрыто, сколько задач переместилось в Done. Это не плохая метрика — она помогает планировать. Но она ничего не говорит о том, двигаешься ли ты в правильном направлении.
Представь: за неделю закрываешь 15 тикетов из backlog'а. Все они про UI-правки, переименование полей и рефакторинг роутов. В это время на проде тихо накапливается проблема: кэш не инвалидируется при обновлении товара. Через три месяца покупатели видят устаревшие цены. Никто не написал тикет на это.
Velocity была отличная. Результат — плохой.
Что такое риск для инженера — без PMBoK
Я специально говорю «без PMBoK». Формальные фреймворки управления рисками полезны на больших корпоративных проектах. На реальной работе senior-разработчика они избыточны.
Мой рабочий вариант: риск — это любое обстоятельство, которое может сделать нас неспособными выполнить обещание. Клиенту. Команде. Или просто себе — что не сдашь код, который сам боишься трогать.
Риски выглядят по-разному:
- Зависимость от внешнего API без fallback.
- Разработчик, который единственный понимает модуль интеграции.
- Дата релиза, привязанная к маркетинговой кампании, без буфера.
- Схема БД, которая не позволит добавить мультивалютность без полного рефактора.
Ни одно из этих обстоятельств не появляется само по себе в тикете. Их нужно видеть.
Три вопроса, которые я задаю до начала спринта
Перед тем, как мы начинаем разбирать backlog, я задаю три вопроса — себе или на планировании.
Первое — что может не дать нам задеплоить в конце спринта? Это технические зависимости, нерешённые вопросы по доступам, неготовые данные от третьей стороны. Если есть хоть один такой блокер — он важнее любых фич из backlog'а.
Второе — что мы сейчас не знаем, что критично знать до конца итерации? Это зоны неопределённости: не баги, не фичи, а незнание. Иногда правильный ответ — сделать маленький proof-of-concept или поговорить с клиентом, прежде чем писать код.
Третье — если мы выкатим это на прод и что-то пойдёт не так, как мы откатимся? Это вопрос про rollback и observability. Если ответа нет — сначала добавляем мониторинг, потом деплоим.
Эти три вопроса занимают 10–15 минут. Они не замещают backlog — они фильтруют его.
Риск, которого не было в тикете
На одном из проектов мы разрабатывали крупный каталог — больше 28 тысяч SKU, высокая нагрузка, кэширование через Redis. Все текущие задачи шли по плану.
За две недели до релиза я задал второй вопрос из списка выше: что мы не знаем, что критично? Выяснилось: мы не тестировали инвалидацию кэша при массовом обновлении цен через импорт. Никто не думал про этот сценарий как про риск — задачи по импорту были выполнены, тесты проходили.
Мы воспроизвели ситуацию на staging. Импорт 5000 товаров вызвал состояние, при котором часть страниц продолжала отдавать старые цены ещё 40 минут. Для интернет-магазина это прямой ущерб: покупатели видят одну цену, оформляют заказ, потом получают корректировку.
На исправление ушло три дня. Если бы нашли на проде — две недели и испорченные отношения с клиентом.
Этого тикета не существовало. Но риск существовал.
Когда owner mindset мешает
Переключение с «закрыть тикет» на «закрыть риск» требует контекста. Нужно понимать бизнес-логику продукта, знать что клиент обещал своим пользователям. Это не всегда написано в тикетах.
Это менеджерская работа. Когда разработчик берёт её на себя, он тратит время не на код.
Это реальный trade-off. Я не говорю, что каждый senior должен думать как product owner 100% времени. Но несколько часов в неделю на понимание контекста — это инвестиция, которая окупается в момент, когда видишь риск до того, как он стал инцидентом.
Есть и другая сторона: если в команде есть менеджер проекта, который уже думает про риски, дублировать его работу не нужно. Owner mindset не значит «делать всё за всех». Значит не быть слепым к тому, что происходит за пределами твоего тикета.
Что изменилось в разговорах с клиентами
Самое заметное изменение — не в скорости или качестве кода. В разговорах.
Раньше на статус-коллах я отчитывался: «закрыли 12 тикетов, в работе ещё 8». Теперь говорю: «на прошлой неделе нашли риск с cache invalidation — убрали потенциальную проблему с ценами перед запуском».
Клиент слышит разные вещи. В первом случае — прогресс по задачам, который ему сложно оценить. Во втором — защиту его бизнеса от конкретной проблемы.
Доверие строится на втором.
Если вы узнали себя в тех 40 тикетах — попробуйте добавить три вопроса выше в начало следующего планирования. Посмотрите, что всплывёт.
Если у вас похожий опыт, или принципиально другой — напишите в DM.