Сначала стоит рассказать, как вообще устроено планирование разработки в бюро. Представьте бассейн с двумя дорожками, это большая и малая итерации. И ещё есть две особые дорожки: фоновые задачи и критические проблемы.

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

Дорожка с фоновыми задачами вечно чем‑то заполнена. Это разные полезные мелочи, оптимизации и незначительные улучшения. Разработчики закрывают задачи с этой дорожки в фоновом режиме, а если фоном не получается — вытаскивают в итерацию, планируют и приоритизируют.

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

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

Чтобы добавить большую или малую итерацию, постановщик присылает письмо с задачей на почту или рассказывает о задаче на встрече. Ведущий разработчик примерно оценивает продолжительность итерации и вносит её в календарь разработки на ближайший свободный слот. Конечно, дизайнеры и разработчики обсуждают оценку, сроки и приоритеты и могут что‑то скорректировать.

Формат передачи задачи в итерацию — это утверждённый Гугль‑документ понимания задачи дизайнером и макеты в Фигме, если они нужны.

Затем уже разработчики пишут своё понимание задачи — спецификацию, как задача будет решена технически. Все документы обсуждаются в комментариях Гугль‑дока или по почте.

Если задача не тянет на итерацию, она попадёт на фоновую дорожку. Такие небольшие задачи приносят разработчикам на почту, говорят устно на встречах или даже присылают в чатик Телеграма. Устная задача и задача в чатике — опасные манёвры, её легко потерять, забыть и не сделать. Так что если решите ставить задачи устно или в чатике, советую убедиться, что исполнитель понял, принял и записал себе задачу, назвал срок сделывания.

С критическими задачами всё строго: если случается что‑то серьёзное, то прийти с этим к разработчику могут по любым доступным каналам. А для всех важных систем в бюро настроены автоматические оповещения о сбоях: если упал сайт или книги, техподдержка и дежурный разработчик получат оповещения об этом по всем каналам, вплоть до СМС‑сообщений и автоматических звонков.