Как расставлялись приоритеты на последнем месте работы?

Как расставлялись приоритеты на последнем месте работы?

На моём последнем месте работы расставление приоритетов было организованным и структурированным процессом, основанным на матрице Эйзенхауэра и OKR методологии.

Процесс расставления приоритетов

1. Еженедельные планирования (Sprint Planning)

Каждый понедельник команда собиралась на планирование спринта. Мы:

• Анализировали требования от product-менеджера
• Обсуждали техдолг и архитектурные улучшения
• Определяли критичные баги и новые фичи
• Оценивали объём работы через story points
• Распределяли задачи на неделю с учётом пропускной способности команды

2. Матрица приоритизации

Мы использовали два критерия:

• Срочность (когда это нужно): срочно/не срочно
• Важность (какой это даёт результат): важно/не важно

Это давало четыре категории:

• Критичные (срочные + важные) → решаются сразу
• Стратегические (не срочные + важные) → планируются
• Срочные мелочи (срочные + не важные) → минимизируются
• Отвлекающие (не срочные + не важные) → откладываются

3. Критерии для новых фич

Для новых функций мы смотрели на:

• Impact — сколько пользователей это коснётся
• Effort — сколько времени потребуется на разработку
• Alignment — соответствие общим целям компании
• Dependency — зависит ли от других задач

Пример: Если новая фича даёт большой impact, но требует много effort, но она заблокирована другой задачей — мы сначала решаем блокирующую задачу.

4. Разбор багов

Для критических ошибок использовалась severity шкала:

• Critical (P0) — сервис упал, нет возможности пользоваться → решаем сейчас
• High (P1) — функция не работает для многих пользователей → в этот спринт
• Medium (P2) — функция работает, но с ошибками → в следующий спринт
• Low (P3) → когда будет время

5. Балансировка между задачами

Мы старались соблюдать баланс:

• 50% времени на delivery новых фич
• 30% на техдолг и рефакторинг
• 20% на срочные баги и оптимизацию

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

Инструменты и процессы

Jira для отслеживания

Каждая задача имела:

• Приоритет (Highest → Lowest)
• Story points для оценки сложности
• Метки (backend, frontend, performance, accessibility)
• Зависимости от других задач

Все видели доску и понимали, что в работе.

Daily Standup (15 минут)

Каждый день утром мы собирались и сообщали:

• Что вчера сделали
• Что сегодня делаем
• Есть ли блокеры

Это помогало быстро переориентироваться, если появлялась критичная задача.

Обслуживание production

В нашей команде был "on-call" инженер, который следил за production мониторингом. Если вдруг появлялась критичная ошибка в production:

• Мы сразу переключались на её решение
• Остальной спринт слегка сдвигался
• После исправления анализировали причину (post-mortem)

Взаимодействие с другими отделами

С Product Manager

PM предлагал новые идеи, но мы обсуждали:

• Сколько это займёт времени
• Какой это даст результат
• Можно ли сделать более простую версию

Ообще, техническая команда имела голос в решениях.

С дизайном и QA

• Дизайн передавал макеты заранее (минимум за день)
• QA готовился к тестированию, пока разработчик кодит
• Всё это ускоряло процесс

Примеры реальных ситуаций

Ситуация 1: Баланс между техдолгом и новыми фичами

Был критичный баг в системе кэширования, который замедлял приложение. Одновременно PM просил новую фичу на фильтрацию. Мы:

• Сказали, что сначала нужно исправить производительность
• Объяснили, что новая фича без оптимизации не даст пользе
• Оправдали это метриками (время загрузки упало на 40%)
• Потом спокойно добавили новую фичу

Ситуация 2: Срочный баг в production

В пятницу во второй половине дня сломалась система оплат. Мы:

• Срочно переключились (1-2 часа на разбор)
• Нашли и исправили баг (30 минут)
• Развернули хотфикс
• Провели анализ, почему это произошло
• Добавили мониторинг, чтобы не повторилось

Кейс с личным вкладом

Я предложил внедрить систему "tech health score" — метрику, которая показывает:

• Сколько багов в production
• Сколько deprecated кода
• Тесты coverage
• Время ответа API

Это помогло наглядно показать, когда техдолг критичен, и команда стала более внимательна к качеству кода. Приоритеты стали более data-driven.

Вывод

На моём последнем месте работы приоритеты расставлялись через:

1. Систематический процесс — еженедельное планирование
2. Ясные критерии — матрица важности/срочности
3. Гибкость — срочные баги в production могли сдвинуть планы
4. Баланс — между новыми фичами, техдолгом и поддержкой
5. Прозрачность — все видели, что и зачем делается
6. Data-driven — решения опирались на метрики

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