Привет, Кирилл!
Разработчики бюро получают задачи по‑разному, всё зависит от размера и сложности задачи. Главное — чтобы задача не потерялась и разработчик правильно её понял.
Планирование разработки
Сначала стоит рассказать, как вообще устроено планирование разработки в бюро. Представьте бассейн с двумя дорожками, это большая и малая итерации. И ещё есть две особые дорожки: фоновые задачи и критические проблемы.
Над большими и малыми итерациями работают параллельно, для этого разработчики делятся на две команды. Исключение — огромные задачи, где требуется участие всех разработчиков
В большую и малую итерации попадают задачи, которые заранее запланировали в календаре разработки. Большая итерация — это крупные фичи, двигающие бюро вперёд: интерфейс отмены подписки или перевод школ бюро на круглогодичный набор. Малая итерация — это важные, но не самые большие задачи: система напоминаний о школьных дедлайнах или новый функционал книжного движка.
Над большими и малыми итерациями работают параллельно, для этого разработчики делятся на две команды. Исключение — огромные задачи, где требуется участие всех разработчиков
Дорожка с фоновыми задачами вечно чем‑то заполнена. Это разные полезные мелочи, оптимизации и незначительные улучшения. Разработчики закрывают задачи с этой дорожки в фоновом режиме, а если фоном не получается — вытаскивают в итерацию, планируют и приоритизируют.
Дорожка для критических проблем в идеале всегда должна оставаться пустой. Всё, что туда попадает, становится приоритетным. Это любые серьёзные проблемы, вроде отвалившихся картинок в книгах или сбоя приёма оплаты. Остальные задачи в этот момент отходят на второй план.
Получение задач
Варианты получения задач вытекают из описанного выше подхода к планированию. Чтобы задачу взяли в работу, нужно поместить её на одну из дорожек: большую, малую, фоновую или критическую.
Чтобы добавить большую или малую итерацию, постановщик присылает письмо с задачей на почту или рассказывает о задаче на встрече. Ведущий разработчик примерно оценивает продолжительность итерации и вносит её в календарь разработки на ближайший свободный слот. Конечно, дизайнеры и разработчики обсуждают оценку, сроки и приоритеты и могут что‑то скорректировать.
Формат передачи задачи в итерацию — это утверждённый Гугль‑документ понимания задачи дизайнером и макеты в Фигме, если они нужны.
Затем уже разработчики пишут своё понимание задачи — спецификацию, как задача будет решена технически. Все документы обсуждаются в комментариях Гугль‑дока или по почте.
Если задача не тянет на итерацию, она попадёт на фоновую дорожку. Такие небольшие задачи приносят разработчикам на почту, говорят устно на встречах или даже присылают в чатик Телеграма. Устная задача и задача в чатике — опасные манёвры, её легко потерять, забыть и не сделать. Так что если решите ставить задачи устно или в чатике, советую убедиться, что исполнитель понял, принял и записал себе задачу, назвал срок сделывания.
С критическими задачами всё строго: если случается что‑то серьёзное, то прийти с этим к разработчику могут по любым доступным каналам. А для всех важных систем в бюро настроены автоматические оповещения о сбоях: если упал сайт или книги, техподдержка и дежурный разработчик получат оповещения об этом по всем каналам, вплоть до СМС‑сообщений и автоматических звонков.
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.