Налаживаем процессы в продуктовой команде

preview

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

Общая стратегия:

1. Определите точку А – это состояние команды на сегодняшний день. Какие есть проблемы у команды?
Здесь нужно провести брейншторм всей командой, следить, чтобы каждый высказался. Записываем все идеи на стикеры. Составляем из стикеров «дерево проблем». Делим все проблемы на несколько «ветвей», определяя смежные по областям. Проблемы с мотивацией сотрудников – одна ветвь, регламентированием обязанностей – другая и т.д. Определяем связи между проблемами: практика показывает, что одна проблема часто является следствием другой. Таким образом, решив «корневую проблему», можно нивелировать вред всей ветви, в то время как решение побочной проблемы  - не более чем решение побочной проблемы.

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

3. Связываем п.1 и п.2.: составляем бэклог улучшений, т.е. создаем список мер, направленных на решение проблем, улучшение процесса разработки и распределяем задачи по работникам. Сразу закладываем на это немалые сроки, т.к. нововведения будут действовать тогда, когда приживутся и станут не нововведениями, а ежедневными ритуалами. Такие деформации даются команде нелегко.

Налаживаем процессы в продуктовой команде

4. Проводим улучшения по циклу Деминга.

  • Планирование: раскрываем проблему и планируем меры решения.
  • Осуществление: моделирование созданной концепции в тестовом пространстве. Этого должно быть достаточно для проверки, но не достаточно для внедрения.
  • Контроль. Если на предыдущем этапе получен ожидаемый результат, его необходимо тщательно проверить. Насколько смоделированная ситуация соответствует оригинальной: возможно, выборка была не достаточно репрезентативной и в масштабах проекта все будет работать иначе?
  • Внедрение. Если п. 1-3 пройдены успешно, можно приступать к внедрению меры. Результаты постоянно документируются и проверяются на соблюдения. При необходимости,  методика корректируется.

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

Внутри компании

1. Четкое определение ролей в компании.
Чтобы система работала эффективно, необходимо грамотно распределить ответственность. Это значит, что в совокупности выработанное распределение должно быть совместно исчерпывающим (т.е. покрывать все этапы работы, чтобы в процессе не приходилось перераспределять обязанность) и взаимоисключающим (зоны ответственности не должны дублироваться, за исключением редких случаев).

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

2. Формирование базы знаний.
Мы создаем внутреннюю базу знаний, основанную на приобретенном опыте. Там прописываем решенные кейсы, делимся ссылками на полезные сервисы, проходим курсы. Такая система позволяет взрастить экспертную, кроссфункциональную, саморазвивающуюся команду. Кроме того, это мотивирует сотрудников развиваться внутри компании.

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

До начала проекта

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

Процесс

1. Используем метрики и визуализируем.
Для измерения эффективности полезно использовать критерий velocity —  отношение трудозатрат команды на выполнение скоупа к продолжительности работы команды над этим скоупом. Единицы измерения трудозатрат подбираем под себя: это могут быть человеко-часы, количество выполненных задач — то, что отражает конкретный процесс.

Допустим, нужно получить velocity всей команды за спринт. Метрикой трудозатрат будут закрытые эффективные часы на проекте. В таск-трекере ведем учет таких часов.  Если для одного человека: средняя выработка backend-разработчика за двухнедельный спринт — 60 часов. При восьми-часовом рабочем дне рабочее время разработчика составит 80 часов. Делим одно на другое — получаем velocity за спринт 0,75 (75 %). Производя такие нехитрые подсчеты на каждой итерации, можем наглядно прослеживать эффективность работы команды и корректировать её.

По velocity можно строить диаграмму производительности. Можно воспользоваться  Burnup/burndown chart. Это диаграммы, показывающие какой скоуп работ осталось на спринт. Этих инструментов должно хватить, чтобы наглядно и в цифрах определить эффективность работы команды, на каких этапах она падает, на каких – возрастает.  Исходя из полученных результатов проводим ретроперспективу.

Диаграмма производительности по velocity

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

3. Регламентация.
Все таски должны быть внесены в бэклог, четко распределены между всеми участниками команды, расставлены по приоритетности. Прежде чем ставить задачу, убедитесь, что она понятна. Полезно иногда проверять их по SMARTу:

  • Specific — конкретная
  • Measurable — измеримая
  • Achievable — достижимая
  • Relevant — значимая
  • Time bound – ограниченная  во времени. Обязательно регламентируем дедлайн

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

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

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

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

Видимость всего бэклога

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