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

Нажав кнопку "Принять и продолжить", вы соглашаетесь с Политики конфиденциальности

Принять и продолжить

Закрыть

Сообщить об ошибке

Отменить
1413 38 3
Новости Читать 33 минуты 11 декабря 2019

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

что нового появилось в Serpstat за последний месяц
Максим Астахов
Максим Астахов
Product/Project manager at Serpstat
В нашем чате Любителей Серпстатить и группе на Facebook пользователи часто задают вопросы: почему мы внедряем ту или иную фичу, почему на это может уходить много времени. Весь процесс разработки долгожданного функционала, словно прикрыт завесой тайны, из-за чего оставляет еще больше вопросов.
Данная статья призвана ответить на следующие, часто задаваемые, вопросы:
Почему в приоритете находится тот или иной функционал?
Какие этапы проходит идея, прежде чем попадет на продакшн?
Какой размер команды и как работает каждая из них?
Как решается вопрос о фиксе того или иного бага?
Дополнительно расскажем чуть подробнее, как у нас построены процессы в целом.

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

Интро


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

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

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

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

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

Пример расписания:
Остальные пустые слоты используются под ответы на вопросы, незапланированные митинги, описание задач для будущих релизов, исследования конкурентов и т.д.
Распределение времени спринта
Время спринта опытным путем было распределено в следующих пропорциях:
40 часов на разработку фич;
20 часов на критические баги и обращения от пользователей с приоритетом (Critical & Blocker);
10 часов на митинги и текущие вопросы, в это время входят и незапланированные митинги;
10 часов на баги в невысоком приоритете, которые набираются в начале спринта (Low, Normal, High).

Project?→ Product?→ CEO?

Несколько слов о самих 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 есть несколько источников идей, которые могут дойти до этапа реализации и деплоя на продакшн или могут завернуться на одном из шагов:
Отзывы/ запросы от пользователей.
Анализ конкурентов и выбор интересных фич.
Бреиншторм — генерация идей членами команды.
идеи для разработки новых фич в Serpstat
Отзывы/ запросы от пользователей:
Как правило, есть два типа запросов: прямые и косвенные.

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

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

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

Источники таких отзывов:
Результаты демо для лидов.
Отзывы от отдела Customer support (при обсуждении потенциальных проблем с нашими пользователями).
Отзывы от отдела Sales/Customer success (при дообучении наших клиентов).
Прямые запросы от пользователей через наш «Чат любителей серпстатить».
Внутренние реквесты (запросы от других отделов, которые не связаны непосредственно с разработкой модуля).
Интервью, проводимые UX-дизайнером, а также PM-ами с клиентами.
Анализ конкурентов
Регулярно, PM каждого из модулей следит за новостями конкурентов о реализованном ими функционале. Каждый менеджер занимается анализом фич только своего модуля, это позволяет не распыляться по всему сервису и более детально изучить определенные фичи.
идеи для разработки новых фич в Serpstat
Все интересные, на взгляд PM-а, фичи заносятся в специальную форму, где в дальнейшем рассматриваются с тимлидом.

По каждой фиче заполняются следующие параметры:
Дата обнаружения.
Суть фичи (кратко).
Скриншот или скринкаст.
Есть у нас или нет (если есть, то почему привлекла внимание).
Комментарий, чем заинтересовала.
Решение делать или нет (принимается вместе с тимлидом).
Так проходит первичная валидация идей. Общее представление тимлида о продукте позволяет правильно распределить найденные фичи между модулями и командами.

Следующий этап — занесение в бэклог продукта, хранится он в Google таблицах с минимальной детализацией и фильтрами.
Генерация идей членами команды
Это идеи:
Которые генерирует PM команды.
Члены команды во время планирования и реализации функционала предлагают собственные решения той или иной проблемы (в данном случае, каждый разработчик имеет полное право предложить другой вариант реализации, если он видит это по-другому, и его предложение будет рассмотрено и оценено).
Во время тестирования функционала могут возникать дополнительные «удобные фичи», которые не сразу видны на этапе проектирования. Они тоже анализируются и внедряются либо сразу, либо планируются на одну из будущих итераций.

Валидация идеи, проектирование, продумывание деталей, дизайн

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

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

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

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

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

Суть системы — мы оцениваем фичу по 4 параметрам:
Reach — оценка доли активных пользователей, которые будут пользоваться данной фичей:
5 — все пользователи;
4 — пользователи трех и более модулей, но не всех;
3 — пользователи двух модулей;
2 — все пользователи одного модуля;
1 — отдельные пользователи одного модуля.

Проставляется lead product manager — при добавлении фичи в бэклог.
Impact — оценка количества запросов от пользователей:
5 — >10;
4 — 8−9;
3 — 6−7;
2 — 4−5;
1 — 3.

Проставляется и обновляется lead product manager при анализе вкладки, куда заносится весь фидбек от пользователей.
Confidence — оценка после покера с РМ:
5 — уверены;
4 — скорее уверены;
3 — 50/50;
2 — скорее не уверены;
1 — не уверены.

Проставляется ведущим покер после оценки, с помощью сервиса — planitpoker.

Этот параметр показывает насколько каждый ПМ считает фичу полезной для продукта на данном этапе при существующем уровне реализации.
Effort — оценка количества спринтов на реализацию (1 спринт=10 рабочих дней):
5 — >3;
4 — 3;
3 — 2;
2 — 1;
1 — <1.

Каждый PM оценивает со своей командой приблизительное количество спринтов, необходимых для реализации. Иногда для того, чтобы оценить время на реализацию, необходимо поставить предварительный ресерч, чтобы более точно определить возможность. Часто в несложных фичах PM сам может оценить время. Сюда входят все этапы от проектирования и дизайна до финального тестирования и выливки на продакшн сервер.
Проектирование, продумывание деталей и дизайн
Когда идея прошла валидацию и получила зеленый свет, в дело вступает сбор первоначальных требований для ТЗ UX-дизайнеру.

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

Во время работы над задачей первичное видение обрастает деталями, которые призваны улучшить пользовательское восприятие: подсказки, валидация полей и вводимых данных, алерты с важной информацией и т.д.
идеи для разработки новых фич в Serpstat
Для упрощения работы дизайнеров я составил чек-лист с best practices, что необходимо учитывать при дизайне/ Вот несколько примеров:
дизайн проверяется на низкой яркости монитора;
макет проходит проверку не только на дисплеях с Retina, но и на совсем простых;
все поля должны иметь подпись и плейсхолдер с подсказкой;
все кнопки должны показывать несколько состояний: нажатое, неактивное, при наведении и т.д.
Когда готов черновик макета, он отдается на ознакомление, правки и комментарии от PM-а.

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

Чаще всего проверяются моменты:
А что будет если нет данных за выбранную дату?
А что если применить одновременно и фильтр и сортировку?
Как отразится текущий функционал на экспорте?
Как пользователь узнает о произошедших изменениях?
Далее, у задачи есть несколько путей:
Сбор дополнительной информации о, использовании того или иного функционала.
Возвращение на дизайнера с комментариями на доработку.
Особо важные задачи обсуждаются с тимлидом или PO of Serpstat.
Задача передается на UI дизайнера, который по макетам воссоздает интерфейс в его конечном виде со всеми стилями.

Подготовка задач и планирование спринта

Подготовка задач к оценке
Для того, чтобы подготовить задачу к оценке и дальнейшему взятию в спринт, она должна пройти несколько обязательных этапов.
1
Задачу описывает PM, максимально подробно, при этом, если будет задействован и фронтенд и бекенд, то описание разделяется на две группы, чтобы не смешивать требования и избавить от путаницы.
2
Дополнительно к пошаговому описанию прилагается ссылка на макет/дизайн.
3
PM добавляет ключи переводов, которые в дальнейшем будут использоваться под видимые пользователям тексты.
4
Параллельно с этим задействуется отдел маркетинга, который вносит свои правки по текстам и вычитывает их на предмет ошибок и правильной формулировки. Этот пункт является обязательным при релизе новых отчетов и модулей.
5
После этого задачи проходят этап кросс-вычитки другими PM-ами, что позволяет отсечь первую волну упущенных деталей или неточностей.
6
После этого происходит ознакомление команды с Story и Duty, корректировка и уточнение описания. Обычно на это достаточно один−два дня.

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

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

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

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

Разработка, тестирование, релиз

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

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

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

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

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

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

Баги, проблемы, обращения пользователей

Система расстановки приоритетов по багам и «военное положение»
1
Blocker — не работает функционал и из-за этого не работает другая часть сервиса (пример: отправка email, sms, не работает генератор отчетов, регистрация, авторизация).
2
Critical — не позволяет массово потенциальным платным пользователям воспользоваться функционалом или одному с MRR более 500 у.е. (пример: невозможно воспользоваться API, экспортом, нельзя оплатить, воспользоваться реферальной программой и так далее, везде не работает Интерком). Или дыра в системе безопасности, или пользователь тратит денег больше, чем должен.
3
High — не позволяет воспользоваться нескольким нашим платным пользователям или потенциальным платным пользователям функционалом (например, подписаться на рассылку, прочитать статью на блоге), и нельзя решить проблему с помощью другой точки входа.
4
Normal — не позволяет воспользоваться нашим платным пользователям или потенциальным платным пользователям функционалом, и можно решить проблему с помощью другой точки входа (пример: не загружается Интерком на одной странице).
5
Low — мелкие визуальные проблемы (сдвиги, пиксели, не загрузилась картинка, кнопка не того цвета, съехавшая кнопка и так далее), которые не мешают основному функционалу страниц.
Курица или яйцо?
Кроме запланированных фичей и задач технического долга, в спринт берутся и баги.

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

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

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

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

Взаимодействие с другими отделами: (marketing, sales & customer success, support)

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

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

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

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

Текучка, митинги

идеи для разработки новых фич в Serpstat
Daily (10-15 минут)
Цель:
Засинхронизировать всех членов команды касательно текущего статуса задач и их плана на день.

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

Формат дейли подразумевает собой ответы на три главные вопроса:
1
Что я делал вчера? (только то, что может коснуться еще кого-то)
2
С какими трудностями столкнулся? (даже если они уже решены, все равно озвучиваем)
3
Чем планирую заниматься сегодня?
Утверждение задач на спринт у Lead product manager, CTO, VP of product (15-30 минут)
Цель:
Утвердить свое видение спринта у руководителей, а также получить комментарии, правки или рекомендации по плану на спринт.

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

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

Технически сложные и важные задачи, которые могут затронуть работу других модулей или связанные с переносом данных, а также временной остановкой работы модуля — проходят консультацию и утверждение у CTO. Задачи остальных команд и менее критичные проходят подтверждение у Lead product manager.
Poker planning (60-90 минут)
идеи для разработки новых фич в Serpstat
Цель:
Оценить все задачи по показателю сложности в SP (Story points) и засинхронизироваться в том, что планируется делать в следующем спринте.

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

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

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

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

Оценка задачи состоит из нескольких процессов:
1
Быстрое освежение в голове сути задачи.
2
Первичное голосование.
3
Если предыдущее оценивание дает единогласно оценку — переходим к следующей задаче.
4
Если оценки разняться или кто-то проголосовал за знак вопроса, то начинается обсуждение.
5
Сначала опрашивается тот, кто проголосовал за «?».
6
Далее опрашиваются те, кто проголосовал выше или ниже средней оценки.
7
Результаты сбрасываются, и задача проходит второй раунд оценивания.
8
Выбирается среднее арифметическое число или округляется в большую сторону.
После того как выяснили сложность, в задаче проставляются специальные метки, которые упрощают ориентирование при деплое задачи на тест сервер или продакшн-сервер.

Дополнительно проверяется шаблон чеклиста, что необходимо будет сделать по задаче, например:
PM добавляет контекст и ключи для будущих переводов.
PM добавляет ссылку на дизайн.
PM добавляет задачу и ссылку на Хвики, где необходимо описать техническую документацию.
PM на покере добавил метки, по которым можно понять какие части ветки необходимо вылить: backend, microservice, react, python.
PM описал работу функционала в пользовательской документации.
Разработчик добавил мерджреквест.
Разработчик описал как тестить фичу.
Если задача подразумевает собой создание нового отчета, то должны быть прописаны метатеги для страницы.
PM добавил фичу в функционал для отслеживания User scoring и т.д.
Синхронизация PM-ов и дизайнеров + оценка фичей по RICE (60−90 минут)
Цель:
Распределить нагрузку между дизайнерами и понять какие задачи запланированы на следующие спринты в каждой из команд, так как функционал чаще всего пересекается — это позволяет не делать двойную работу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контроль спринта, сбор статистики

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

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

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

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

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

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

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

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

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

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

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

Кнуты и пряники

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

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

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

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

Послевкусие

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

Важные моменты и болючие шишки, которые мы набили за это время:
1
Эксперименты. Для того, чтобы закрывать дыры во флоу надо проводить эксперименты по устранению ошибок. Постоянно. Ошибаться не страшно, страшно знать, что делаешь что-то неправильно и продолжать работать как есть, без попыток что-то изменить.
2
Масштабирование. Проводить эксперименты желательно не на всех, а на малой группе людей или одной команде. Это поможет снизить последствия от неверных решений, которые могут быть приняты, плюс таким образом вносить изменения — проще.
3
Документация. Важно постоянно вести документацию не только технического кода или пользовательского поведения той или иной фичи, но и самих процессов, правил. Эта информация должна храниться в письменном виде в актуальном состоянии, чтобы в любой момент можно было ввести в курс дела нового человека или команду, без дополнительной траты времени на объяснения. Также это уберет возможность того, что члены разных команд запутаются, где экспериментальный флоу или правило, а где действующее.
4
Гибкость. Надо не забывать, что любой флоу или правило являются таковыми до тех пор, пока они работают при текущих условиях. Если что-то не работает по каким-то причинам, то это не повод не соблюдать это. Необходимо вносить изменения. Флоу и правила должны быть максимально гибкими, понятными и автоматизированными. Если кто-то не до конца понимает для чего выполняется тот или иной пункт, то необходимо обсудить его, так как работа сделанная для галочки — это неэффективно и хуже несделанной работы.
Надеюсь, данный лонгрид, помог понять, что происходит за стенами нашей компании. Как мы расставляем приоритеты, что делаем при неработающих процессах и с какими трудностями сталкиваемся. На нераскрытые вопросы, с радостью отвечу в комментариях — ниже.
Чтобы быть в курсе всех новостей нашего блога подписывайтесь на рассылку Serpstat. У вас есть целых 11 причин, чтобы это сделать ;)
Почему четверть миллиона интернет-маркетологов подписались на рассылку Serpstat?
А также вступайте в чат любителей Серпстатить и подписывайтесь на наш канал в Telegram.

Сэкономьте время на изучении Serpstat

Хотите получить персональную демонстрацию сервиса, тестовый период или эффективные кейсы использования Serpstat?

Оставьте заявку и мы свяжемся с вами ;)

Оцените статью по 5-бальной шкале

4.95 из 5 на основе 18 оценок
Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Поделитесь статьей с вашими друзьями

Войти Регистрация

Вы исчерпали лимит запросов.

Или email
Забыли пароль?
Или email
Back To Login

Не волнуйтесь! Напишите свой электронный адрес и мы пришлем вам новый пароль.

Вы уверены?

Awesome!

To complete your registration you need to enter your phone number

Назад

Мы отправили код подтверждения на ваш номер телефона

Your phone Resend code Осталось запросов

Что-то пошло не так.

Свяжитесь с нашей службой поддержки
Или подтвердите регистрацию с помощью Телеграм бота Перейдите по этой ссылке
Выберите один из проектов

Знакомство с сервисом

Ознакомьтесь с основными возможностями Serpstat удобным способом!

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

Имя

Email

Телефон

Будем рады вашему комментарию
Увеличить лимиты

Улучшить тариф

Экспорт недоступен для вашего тарифного плана. Вам необходимо улучшить свой тариф до Lite или выше, чтобы получить доступ к инструменту Подробнее

Зарегистрироваться

Спасибо, мы с вами свяжемся в ближайшее время

Пригласить
Просмотр Редактирование

E-mail
Сообщение
необязательно
E-mail
Сообщение
необязательно

У вас закончились лимиты

Вы достигли лимита на количество созданных проектов и больше не можете создавать новые проекты. Увеличьте лимиты или удалите существующие проекты.

Я хочу больше лимитов