Под капотом: как построены процессы
в отделе разработки

Данная статья призвана ответить на следующие, часто задаваемые, вопросы:

Дополнительно расскажем чуть подробнее, как у нас построены процессы в целом.

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

В Serpstat была принята длительность спринта/итерации — 10 рабочих дней = 80 рабочих часов на одного человека. Хотя в многих источниках вы можете встретить разные значения: от недели до месяца.

Начало спринта — вторник, конец спринта — понедельник. Смещение было выбрано для того, чтобы не заканчивать спринт в пятницу и не выливать релиз перед выходными, так как в случае проблем на продакшене их пришлось бы фиксить в субботу/воскресенье.

В моей команде четыре разработчика, два тестировщика. Еще есть два дизайнера, нагрузку и задачи которых мы делим между другими командами.

Цель спринта — выпуск минимум одной видимой фичи для пользователей + фикс багов и оптимизация работы сервиса.

Трудности, с которыми команда сталкивается на протяжении спринта: баги, обращения от пользователей, болезнь членов команды.

Время спринта опытным путем было распределено в следующих пропорциях:

Несколько слов о самих project/product менеджерах в Serpstat.

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

Каждый project/product manager в Serpstat — это кухонный комбайн, универсальный солдат, швейцарский нож, который управляет не просто командой разработчиков или отдельным модулем. Он ищет идеи или генерирует их сам, валидирует при помощи опросов и аналитики. Описывает в первом приближении, обсуждает с командой, взаимодействует с UX-дизайнером, чтобы получить максимально удобный и простой макет.

Достаточно много времени уходит на продумывание идеи, а также множества мелочей, которые связаны с остальной частью продукта. Соответственно и с другими командами. У нас нет отдельных technical writers, поэтому написание ТЗ и документации тоже лежит полностью на плечах менеджера. И, кроме этого всего, мониторинг самого спринта, встречи с разработчиками, поддержание боевого духа в команде, отчетность и еще 100500 пунктов из работы менеджера.

С осени 2018 года весь отдел разработки был разбит на микрокоманды. Текущая структура отдела выглядит следующим образом:

5 PM-ов и PM Teamlead. В каждой команде от 5 до 10 человек.

Каждый PM отвечает за свои модули в Serpstat. Основной задачей является полный цикл разработки, включая такие вопросы, как хранение данных, задачи на продвижение для отдела маркетинга, документация для отделов Customer support, демо и презентации отделу Sales & Customer success.

Зона моей ответственности — модуль Rank tracker (мониторинг позиций), который позволяет отслеживать позиции сайта в выдаче по ключевым запросам.

Дополнительно, на поддержке, находится функционал для снятия топов по ключевым запросам через API.

В Serpstat есть несколько источников идей, которые могут дойти до этапа реализации и деплоя на продакшн или могут завернуться на одном из шагов:

Как правило, есть два типа запросов: прямые и косвенные.

Прямой запрос: «Добавить сортировку по частотности в отчете Ключевые фразы мониторинга позиций».

Косвенный запрос: «Неудобно пользоваться отчетом из-за длинного названия региона, так как колонка занимает много места».

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

Источники таких отзывов:

Регулярно, PM каждого из модулей следит за новостями конкурентов о реализованном ими функционале. Каждый менеджер занимается анализом фич только своего модуля, это позволяет не распыляться по всему сервису и более детально изучить определенные фичи.

Все интересные, на взгляд PM-а, фичи заносятся в специальную форму, где в дальнейшем рассматриваются с тимлидом.

По каждой фиче заполняются следующие параметры:

Так проходит первичная валидация идей. Общее представление тимлида о продукте позволяет правильно распределить найденные фичи между модулями и командами.

Следующий этап — занесение в бэклог продукта, хранится он в Google таблицах с минимальной детализацией и фильтрами.

Идеи собираются в бэклог и проходят первоначальный отсев тимлидом.

Каждые две−три недели, в зависимости от скорости сбора таких запросов, на синхронизации PM-ов проводится оценка жизнеспособности идеи и простановка приоритетов в рамках продукта. Делается она не на глаз или по субъективному мнению одного человека, а всей командой PM-ов, включая тимлида.

Ранее, основным показателем того, что ту или иную фичу необходимо реализовать, было только количество запросов из разных источников.

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

Несколько месяцев назад была взята за основу для оценивания система RICE, и наш тимлид адаптировал ее под реалии продукта, чтобы оценивать запросы наших пользователей. Расшифровка параметров может отличаться от источника к источнику, но мы нашли золотую середину для себя.

Суть системы — мы оцениваем фичу по 4 параметрам:

Когда идея прошла валидацию и получила зеленый свет, в дело вступает сбор первоначальных требований для ТЗ UX-дизайнеру.

Источниками требований могут быть детали из анализа конкурентов, непосредственные запросы от пользователей, которые часто можно объединить в общий функционал, результаты интервью. Менеджер модуля заранее расписывает будущее видение функционала и ставит задачу на дизайнера.

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

Для упрощения работы дизайнеров я составил чек-лист с best practices, что необходимо учитывать при дизайне/ Вот несколько примеров:

Когда готов черновик макета, он отдается на ознакомление, правки и комментарии от PM-а.

Далее PM проводит тест макета на поведенческие кейсы. Часто, добавление даже одного поля или кнопки влечет за собой много нюансов и состояний, которые необходимо отобразить в дизайне.

Чаще всего проверяются моменты:

Далее, у задачи есть несколько путей:

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

Во время ознакомления с задачами перед оценкой каждый член команды отписывает свои вопросы или предложения. Потенциальный исполнитель + девмастер команды должны описать предполагаемый алгоритм разработки и именно он будет оцениваться.

После того как задача оценена по сложности и у нее утвердился исполнитель, следующим этапом идет разбиение на подзадачи-tasks, которые оцениваются в часах.

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

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

Если Story или Duty оказывается сильно большой по размеру, то PM пересматривает функционал и разделяет на несколько задач поменьше.

После начала спринта разработчики берутся за задачи в порядке приоритетов. Выполняются все подзадачи в рамках Story и Duty. Как только все задачи выполнены, разработчик перепроверяет разработанный функционал на тестовом сервере и отправляет на код ревью на другого разработчика.

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

После того как задача упала на тимлида отдела тестирования, ее берет в работу освободившийся тестировщик из команды модуля, по приоритету, указанному в задаче.

Тестировщик проверяет функционал на соответствие описанию, проходит все положительные кейсы использования и тестирует самые распространенные негативные. С тестирования задача может вернуться на уточнение нового открывшегося кейса, который не был продуман, на фикс найденных багов или может быть переведена в статус «Готово».

Каждый последний четверг спринта, тимлид отдела разработки собирает все задачи, которые были переведены в статус «Готово». Они собираются в отдельную релизную ветку GitLab на сервере и тестируются повторно, чтобы убедиться, что не возникает проблем при работе всех вместе разработанных фич.

Четверг, пятница, понедельник выделяется на тестирование этих задач, а также багов, которые фиксятся в это время.

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

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

Все Blocker и Critical баги идут в работу в текущий спринт, остальная разработка приостанавливается. Баги ниже по приоритету планируются в рамках спринтов и фиксятся после сборки релизной ветки (набор функционала который тестируется отдельно и станет доступным пользователям после релиза).

Если в спринт запланированы баги ниже по приоритету, чем те, которые были обнаружены во время итерации, то они заменяются и вытесняются.

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

Количество багов превышает доступное время в рамках спринта, или существует несколько Critical и Blocker багов, или модуль не работает? В команду привлекаются разработчики из других команд. Любая текучка и митинги уходят на второй план. Обязательным митингом остается только Daily meeting, для синхронизации ресурсов. В команде или отделе объявляется военное положение, которое контролирует СTO. При помощи специального канала в телеграмме PM держит CEO и руководителей других отделов в курсе событий и обновляет статусы.

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

С отделом маркетинга отдел разработки связывают несколько основных задач:

Отделу Sales предоставляется информация о выпущенных новых фичах и закрытии запросов определенных пользователей. Часто это становится отправной точкой для повторного созвона с лидом, чтобы закрыть приобретение плана, так как необходимый функционал становится доступен.

Отделу Customer success информация дает возможность записать вебинар или обучить наших пользователей кейсам, которые можно решить при помощи появившегося функционала.

Support через обновление документации получает четкое представление о том, какой функционал есть на данный момент и как он должен работать. В таком случае любое девиантное поведение может расцениваться как баг и при помощи саппорта будет отправлено в отдел проверки качества QA. Где по нему будет заведен баг.

Цель:
Засинхронизировать всех членов команды касательно текущего статуса задач и их плана на день.

Дейли проводится дважды. Вначале менеджер принимается участие на внутрикомандном дейли. После этого он приходит на дейли межкомандное, где принимают участие тимлиды и все PM-ы.

Формат дейли подразумевает собой ответы на три главные вопроса:

Цель:
Утвердить свое видение спринта у руководителей, а также получить комментарии, правки или рекомендации по плану на спринт.

Все задачи, планируемые на спринт, проходят дополнительную проверку/утверждение у VP of Product (на данный момент это касается модулей Поисковая аналитика, Мониторинг позиций и Аудит)
Эта встреча обязательная и назначается не позже трех дней до начала спринта.

Сделано это с тем расчетом, что должно остаться время на внесение правок, а также ознакомление команды с задачами и их оценку.

Технически сложные и важные задачи, которые могут затронуть работу других модулей или связанные с переносом данных, а также временной остановкой работы модуля — проходят консультацию и утверждение у CTO. Задачи остальных команд и менее критичные проходят подтверждение у Lead product manager.

Цель:
Оценить все задачи по показателю сложности в SP (Story points) и засинхронизироваться в том, что планируется делать в следующем спринте.

Когда все члены команд уже ознакомились с задачами на оценку, они собираются в отдельный список и импортируются в сервис planitpoker. Он простой, удобный, гибко настраиваемый. Полностью покрывает все наши потребности на данном этапе.

Story и Duty уже часто распределены между разработчиками, так как есть первоначальное представление о сложности задачи и, соответственно, кто ее будет делать. Если такого понимания нет, то они висят на PMе до конца покера.

Шкала сложности измеряется в Story Points по шкале: 1,2,3,5 или ?, где

1sp — небольшие изменения стилей.
2sp — изменения в формате данных, переделка компонентов.
3sp — написание процедуры с 0 или создание нового компонента.
5sp — создание отдельных страниц на фронте, написание нескольких процедура или их существенная переделка.
? — по описанию есть вопросы — не могу оценить.

Оценка задачи состоит из нескольких процессов:

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

Дополнительно проверяется шаблон чеклиста, что необходимо будет сделать по задаче, например:

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

Весной 2019 года был добавлен еще один тип митинга, на котором происходит синхронизация PM-ов, распределение задач между дизайнерами, так как они являются общим ресурсом, а также оценка фич, описанная в разделе.

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

В связи с переходом веб части сервиса на React, у нас появилась возможность выносить похожий функционал в отдельные компоненты и переиспользовать их в других командах с минимальными трудо- и времязатратами (примеры компонентов: календарь, фильтр, пагинация).

Цель:
Выяснить отношение члена команды к другим, оценить его эмоциональное и моральное состояние, выявить недовольство в рабочих моментах.

Регулярно, не реже раза в месяц с каждым членом команды проводится 1-to-1 митинг, который позволяет узнать состояние человека на данный момент (только если он готов говорить о проблемах).

Такая встреча обязательно проводится за рамками офиса, для того, чтобы можно было максимально расслабиться. Провести может не только PM, но и любой тимлид или топ менеджер.

Сделано это для того, чтобы член команды мог говорить с каждым о том, что ему важно. Вряд ли разработчик захочет рассказать про проблемы в коде PM-у и при этом охотно поделится этим с лидом. Так как ныть нужно не просто в пустоту, а тому, кто в состоянии решить вопрос или повлиять на ситуацию.

Формат встречи не регламентирован, хотя есть рекомендуемые темы, которые необходимо обсудить.

1-to-1 — это не встреча для обсуждения задач или проекта. На этом митинге можно поделиться своими переживаниями, задать те вопросы, которые интересуют. Можно обсудить отпуск, досуг и вообще все то, что волнует на данный момент. Если того требует ситуация можно обсудить и конкретный рабочий момент. Запись не ведется.

Можно делать заметки, чтобы решить конкретные вопросы или поставить задачи.

Цель:
Оценить, что было исправлено с прошлого спринта. Проверить успеваемость команды, и дать рекомендации. Разобраться с причинами провала спринта.

Ретроспектива спринта происходит на следующий день после релиза спринта.

Митинг разбивается на три основные части:

Провалы целей спринта
Менеджер подготавливает список задач, которые по тем или иным причинам не были завершены в рамках спринта. Рассматривается каждая перенесенная задача. В такие моменты лог работы над задачей, а также комментарии помогают определить на каком этапе произошло подвисание. У каждого участника команды есть возможность высказать свою точку зрения на причины провала задачи. Эти комментарии записываются напротив каждой задачи и по ним менеджер обязан предпринять необходимые действия для предотвращения повторения ситуации.

Разбор KPI команды
В Serpstat у каждого разработчика, так же как и у команды, есть система KPI. По результатам системы выбирается лучший разработчик месяца и лучшая команда квартала. Во время спринта у каждого члена команды открыт доступ к результатам, чтобы отслеживать свои позиции и обращать внимание на просадки в показателях. На ретроспективе менеджер проходит по показателям каждого члена команды и, если требуется, дает рекомендации на что стоит обратить внимание.

Личные отзывы
На протяжении всего спринта у команды есть доступ к форме ретроспективы, где каждый может анонимно оставить комментарий по одной из следующих категорий:

В данной части подводятся итоги по предыдущим задачам, связанным с процессами.

В качестве основного инструмента мы используем open-source инструмент Redmine.

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

В редмайне мы храним заведенные баги и расписанные задачи на несколько спринтов.

Специальный фильтр, который позволяет в один взгляд понять, что происходит со спринтом и в каком состоянии находятся задачи.

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

В Serpstat есть инструкция, которую используют ПМ или любой из членов команды для получения уведомления об изменениях в задачах.

Синхронизация настраивается через Redmine c привязкой телеграм канала.

В итоге, при изменении параметров задачи, например: исполнитель, статус, номер спринта — приходит короткое сообщение в Телеграм.

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

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

Показатель позволяет соревноваться как разным командам, так и PM-ам. Также учитывается в системе стимулирования PM-ов и влияет непосредственно на бонусы, получаемые в конце месяца.

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

На каждого PM-а в конце месяца автоматически ставится задача-напоминание по сбору статистики использования модуля за месяц.

У каждого модуля свои метрики, которые отображаются как в абсолютных, так и относительных показателях. Информация сбрасывается в общий канал компании для максимального информирования всех отделов об использовании модулей и состоянии дел.

Кроме этого тимлид PM-ов делится информацией об общей средней успеваемости всех команд и графиком, на котором можно увидеть динамику.

Комфортабельные условия работы зависят от множества факторов. Начиная от рабочего места и освещения, команды и заканчивая возможностью получить бонус и продвинутся по карьерной лестнице. Каждый руководствуется своими приоритетами и прилагает усилия.

В Serpstat настроена гибкая система, по которой менеджер работает над своими показателями, влияющими не только на бонус в короткой перспективе, но и на рост по карьерной лестнице в долгую.

Первая метрика — MRR компании.
Вторая метрика — оценка от команды и руководителей отделов.
Третья метрика — стабильность работы модуля
Четвертая метрика — соблюдение целей, поставленных на квартал.

Весной 2019 года была также внедрена система показателей для разработчиков, которая позволяет делать выводы о развитии сотрудника на конкретных цифрах и графиках, а не на субъективном мнении. Дополнительно эта система позволяет увидеть общую производительность всей команды.

В личном KPI учитывается много факторов:

Мы только начали срабатываться по налаженному флоу. В процессах все еще существуют недостатки, над устранением которых работает каждый член команды.

Важные моменты и болючие шишки, которые мы набили за это время:

Надеюсь, данный лонгрид, помог понять, что происходит за стенами нашей компании. Как мы расставляем приоритеты, что делаем при неработающих процессах и с какими трудностями сталкиваемся. На нераскрытые вопросы, с радостью отвечу в комментариях — ниже.

А также вступайте в чат любителей Серпстатить и подписывайтесь на наш канал в Telegram.