Как я организовал процессы внутри мобильной команды
Благодаря своей инициативе я смог получить в "распоряжение" двух разработчиков и стать тимлидом на минималках… или не на минималках?
Для справки: я сотрудник компании с 2+ годами работы, участвую в продукте с самого старта и ранее был ведущим мобильным разработчиком.
Как же я организовал процессы мини-команды и какие проблемы прошлого учёл?
Дейли, как дополнение к вилки
Ранее (да и сейчас) в команде продукта практиковались викли-собрания дважды в неделю: в понедельник задачи ставились, а в пятницу проверялся их статус и закрывались. Проблема такого подхода очевидна — простой разработчика, если задачи закончились.
Для начала разберём минусы викли, которые вижу я:
- Если задачи закончились — сотрудник бездействует и скучает.
- Контроль качества слабый: задача может быть сделана в среду, а проверится только в понедельник.
- Релиз обычно в пятницу — а это.. я лучше промолчу.
Что же делает дейли:
- Задачи проверяются и ставятся ежедневно. Разработчик всегда знает, что делать.
- Качество выше: задача не ждёт неделями ревью.
- Релиз возможен в любой день (КРОМЕ ПЯТНИЦЫ!).
- Вопросы обсуждаются сразу, а не только по расписанию. Разработчиков не надо созывать в рандомный момент, ведь они готовы к дейли.
- Ежедневно видно состояние разработчика и можно регулировать нагрузку, если видно критический момент в его словах или поведении.
Когда-то я тоже считал дейли бесполезными, но практика показала обратное и я признал свою неправоту. Главное — длительность: не более получаса (максимум час в особых случаях).
Жизнь задачи
Раньше ЖЦ задачи был прост: Появление → Обсуждение на викли → Закрытие.
Нормально? - Абсолютно нет, это ужасно, а где аналитика? Минимальное описание? Да, она обсуждается, но таким образом не прорабатываются мелочи.
Что натворил я:
- Появление задачи.
Задачи приходят либо в Bugs, либо в Backlog. Для бэклога введены статусы: Пишется ТЗ, Согласование, Готова к реализации, Временно возвращено, Отменено. Так сразу видно, на какой стадии задача. и это сделано, чтобы я или тимлид продукта или руководство выше при открытии нашей доски сразу пониманило в какой стадии находится задача в бэклоге и не было мыслей, что про неё забыли. - Готова к реализации → В ожидании.
Означает, что задача описана и скоро будет выдана. Интересный факт - по этой колонке можно понять загруженность и скорость работы разработчиков. Если она пустая, то они работают достаточно быстро, иначе наоборот (но это не всегда 100% гарантия, могут просто закончиться баги, а от бизнеса ещё описывают). - В работе.
После дейлика разработчик получает задачу и создаёт ветку под её номер. - Ревью.
Сделанная задача попадает сюда и ждёт дейлика. Создаётся MR. - Тестирование.
Тестировщик проверяет и либо даёт approve, либо возвращает на доработку. - Слияние и утверждение.
После тестирования задача попадает в «Выполнено», затем я сливаю ветки и переношу её в «Утверждено».
Да, цикл длинный, но он даёт прозрачность и контроль. К тому же собирается статистика: сколько задач на каждом этапе, где задержки, что придаёт гибкости.
MR в руки или выстрел в колено?
На первом же дейлике я сказал -"Теперь мы следуем GitFlow", но что это означало?
- Каждая задача = отдельная ветка.
- Три основные ветки:
- dev — код у разработчиков;
- prod — опубликованный код;
- master — зеркало prod, обновляется после релиза.
Не самое классическое разделение, но рабочее. В будущем, возможно, добавлю test-ветку. Думаю, если рассказывать про GitFlow во всей красе, то лучше в отдельной статье.
И каково разработчикам ты подумал?
Да, я их спросил и им нравится! Получается, что процессы были не зря и не ухудшили работу, а наоборот улучшили и ускорили.
Как итог можно выделить несколько пунктов:
- Соблюдение адаптированного GitFlow.
- Конкретные дейли без «воды».
- Прозрачность: задачи проходят много стадий, статистика доступна всегда.
- Ежедневная возможность регулировать нагрузку.
Я часто акцентирую внимание на состоянии разработчика. Если он здоров, мотивирован и доволен — будет и код чище, и багов меньше. И наоборот: усталость рождает выгорание и бесконечные правки.
Да, кто-то скажет, что часть моментов формальны. Но это работает в реальном мире, где люди не обязаны гореть продуктом 24/7 и где процессы помогают делать работу предсказуемой и качественной.
Процессы нужны не для галочки, а для человека. Если разработчик доволен, то и результат будет лучше.