Разработка успешного продукта не кросс-функциональной командой

Меня зовут Екатерина Александрова, я продакт-менеджер решения EmplDocs.

Основной продукт компании - портал для автоматизации кадровых процессов и самообслуживания сотрудников с использованием КЭДО «EmplDocs». Причем со стороны бэкенда наше решение использует расширение 1С, поэтому бесшовно интегрируется с 1C:ЗУП и 1С:ERP, а со стороны фронта – веб-приложение на Angular.

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

 

Scrum или Kanban

 

 

Если вы думаете, что работаете по фремворку Scrum, то иногда вы можете ошибаться. Если в течении спринта ваш руководитель просит взять объемную задачу, потому что клиенту «очень нужно» – это не совсем Scrum. В Scrum, если спринт распланирован, в него нельзя добавлять задачи – вы уже взяли обязательства, и их нужно выполнить.

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

Вот чем кардинально отличаются методологии.

 

 

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

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

 

 

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

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

 

 

Важная особенность Kanban – любой процесс разделен на Discovery и Delivery.

В части Discovery по задаче принимаем решение: “готовы ли мы взять ее в работу?”, “несет ли она какую либо ценность для продукта,”зачем мы будем это делать?”.

Delivery - отражен сам процесс реализации задачи. При перемещении задачи с процесса Discovery в Delivery, команда берёт на себя обязательство, что сделает задачу как можно быстрее. В этот момент возникает «Точка принятия обязательств». Такое разделение позволяет максимально быстро выполнять обязательства и отдавать пользователю/бизнес-заказчику готовую функциональность.

На этом слайде показано, как выглядела левая часть нашей первоначальной доски.

 

А примерно так выглядела ее правая часть.

 

В дальнейшем после начала работы по Kanban мы обсуждали все пожелания к внешнему виду этой доски на совместных встречах-ретроспективах.

Например, когда к нашей команде присоединился новый коллега, с новой ролью– дизайнер, мы добавили на доску статус «Дизайн». Этот статус позволял после анализа требований ставить задачи на дизайнера. Точнее, дизайнер самостоятельно вытягивал задачи в работу, поскольку Kanban – это вытягивающая система.

Кроме того, на одной из ретроспектив мы выявили еще одну проблему. Поскольку наша команда не была кросс-функциональной, возникла необходимость сбалансировать загрузку между бэкенд и фронтенд-разработкой, потому что ранее единый статус «Разработка» не позволял определить, кто из разработчиков перегружен. На встрече было решено разделить этот статус на два: «Разработка Back» и «Разработка Front», добавив для каждого свои WIP-лимиты, чтобы ограничить объем задач, которые разработчики могли выполнять одновременно. Это решило проблему, когда, например, 1С-разработка (наши бэкенд-разработчики) простаивали, а фронтенд-разработка перегружена или ожидает задачи со стороны бэкендеров.

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

 

Как сейчас выглядит доска задач

 

На слайде показано, как доска задач выглядит сейчас – для управления задачами мы используем Jira.

На доске видно, что количество задач в статусах ANALYSES и FRONT IN PROGRESS превысило WIP-лимиты. Но, поскольку один человек в один момент времени может работать только над одной задачей, максимум над двумя – вторая может быть в блоке или в обратной связи, то при превышении лимитов, о которых вы договорились с командой ранее, необходимо провести анализ, почему это происходит.

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

 

Проведение Daily

 

 

Следующее, что было сделано при переходе на гибкие методологии – проведение дейли. Вначале проводили их раз в неделю, затем перешли на ежедневные встречи, в процессе которых мы отвечаем на три вопроса:

1. Что было сделано вчера?

2. Что будет сделано сегодня?

3. Есть ли какие-то блокировки в работе – сюда относятся те проблемы, которые возникают у команды, разработчиков, аналитиков, тестировщиков.

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

 

Ретро

 

 

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

 

 

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

Стараемся не обсуждать негатив – не обвинять условного «Васю», что он что-то не так сделал. Обсуждение ведется всегда в позитивном ключе.

 

 

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

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

• Далее анализируем, что было сделано по результатам прошлого ретро.

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

• Далее команда накидывает идеи – какие мысли или инсайты им пришли в течение месяца.

• И в конце мы принимаем решение, что наша команда может сделать лучше к следующему ретро.

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

 

Встречи по наполнению

 

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

 

 

Для встреч по наполнению мы тоже используем доски, но это доски не для задач типа Task, а доски для задач типа UserStory.

 

Вот так выглядит процесс работы с UserStory – здесь также есть доски Discovery и Delivery, и переход между ними также является точкой принятия обязательств.

На встречах по наполнению мы решаем:

• какие UserStory нам необходимо доисследовать к следующей встрече по наполнению;

• а также решаем, что будем делать в текущей каденции с точки зрения разработки.

 

Примерно так выглядит карточка UserStory – на слайде скриншот из Jira.

Каждая UserStory несёт ключевую клиентскую ценность – без ценности будет сложно продать продукт бизнесу:

• Во-первых, стейкхолдерам, которые верят в ваш продукт.

• А во-вторых, клиентам – потому что если вы работаете с клиентами, вы должны заранее подумать, какую ключевую ценность будете им нести.

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

Например: в UserStory «Создание заявок по авансовым отчётам из ЛКС» у нас описано:

КАК СОТРУДНИК
ХОЧУ регистрировать все свои расходы в командировке через сервис ЛКС
ЧТОБЫ отчитаться по всем расходам в командировке и вернуть свои деньги.

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

Кроме клиентской ценности важно определиться с критериями готовности этой UserStory – когда будет считаться внутри вашей команды, что она выполнена. Критерии готовности по-другому называются Definition of Done, DoD. Причем на ретроспективах вы можете эти критерии готовности пересматривать вместе с командой.

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

 

 

Расскажу, как процесс наполнения для UserStory у нас организован в Jira.

 

 

В Jira настроены отдельные доски для процессов Discovery и Delivery.

Причем изначально на доске Discovery свимлайны change и run были настроены в разрезе всех продуктов, которые у нас есть:

• В свимлайн change попадали все UserStory, которые несут клиентскую ценность – то, что можно попробовать и пощупать.

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

 

 

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

Плюс продуктов стало больше – появился «Портал кандидата», мобильное приложение и Cloud-версия. Поэтому приняли решение сменить свимлайны change и run на продуктовые направления: EmplDocs, Portal, Mobile, Cloud. Таким образом сформировали понимание, что мы делаем по тому или иному продукту.

Еще один момент – когда разделяли UserStory только на свимлайны change и run, не всегда получалось продать бизнесу идею, зачем нужно что-то улучшать с технической точки зрения. При переходе на продукты это стало намного проще, потому что так получается лучше описывать ключевую пользовательскую ценность, которую бизнес может в итоге оценить. А поскольку бизнес всегда все оценивает в цифрах, это можно и подсчитать.

 

 

На слайде – скриншот еще одной доски EmplDocs_integrarion, которая у нас появилась совсем недавно.

Так как мы сейчас активно наращиваем клиентскую базу и в рамках продукта есть некоторые кастомные решения, которые дорабатываем именно с точки зрения продуктового развития, мы дополнительно настроили доску EmplDocs_integrarion, куда относим UserStory, касающиеся:

• пресейлов при работе с клиентами;

• интеграций;

• задач по подключению сервиса;

• и вынесли туда же техподдержку.

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

 

 

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

Причем есть варианты расчета Team Capacity в рамках трудочасов или в стори-поинтах.

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

 

Поэтому мы отказались от оценки трудочасах и перешли на Story Points – они намного проще в оценке.

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

В результате сейчас планирование тех UserStory, которые мы берём на встрече по наполнению, стало намного проще и прозрачнее.

Когда я показывала доску EmplDocs_Integration, вы могли видеть на ней UserStory, которая относится к поддержке продукта – на каждый спринт мы эту UserStory оцениваем в определенном количестве стори-поинтов.

 

 

На слайде показаны таски на доске тасков, которые мы и делаем в в рамках этой UserStory по техподдержке. Сюда относим:

• таски, которые приходят к нам на доску от первой линии поддержки с темами «БЛОК» или «КОНС» (ошибка или консультация) – привязываем эти задачки к UserStory по техподдержке;

• и идеи, которые приходят от клиентов – их мы аккумулируем в рамках этой же доски тасков и рассматриваем на дополнительных встречах, решая, что будет отдельной UserStory, а что нет. Например, если это небольшая задача до 8 часов, мы протягиваем эту задачу в рамках нашей поддержки. Если же это большая задача, на которую требуется несколько недель, то, конечно, такие таски у нас превращаются в отдельные UserStory.

 

 

Ранее упоминала, что Kanban - это вытягивающая система, поэтому на встречах по наполнению мы вытягиваем задачи из статуса BACKLOG в Очередь, которые планируем делать в следующуюу каденцию. С этой целью у нас хитро настроена доска Delivery.
В Jira, которую мы используем в качестве трекер-системы, для доски Delivery в разделе Column management включили переключатель «Epic panel».

В этом случае становится активной вкладка «Kanban backlog» – в ее рамках можно настраивать те статусы, из которых вы будете наполняться.

В данном случае здесь один статус – BACKLOG, но можно перетащить сюда и другие статусы.

 

 

После выполнения такой настройки доска управления UserStory приобретает вид, как на слайде.

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

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

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

 

Подготовка к релизу: встречи по обзору, подготовка документации, сборка

 

 

В конце каденции вместе с командой и бизнесом проводим встречу по обзору.

 

 

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

Выступают не только аналитики, но и разработчики. И это очень хорошая практика.

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

Но поскольку у нас продукт сложный и с нюансами, заранее подготовить релиз к встрече получается не всегда. Поэтому используем формат встречи по обзору – в виде демонстрации, по результатам которой уже перетаскиваем то, что у нас было реализовано, из «Разработки» (статус IN PROGRESS) в «Релиз» (статус IN RELEASE).

 

 

После встречи по обзору начинаем готовиться к релизу – в рамках этого этапа мы уделяем особое внимание меткам и приоритетам на доске задач.

Например, в релиз максимально попадают задачи с первым приоритетом.

При этом разработчики обращают внимание на метки Current или LTS, потому что у нас есть две версии продукта – LTS и Current:

• LTS – это версия с более длительной поддержкой, где мы правим только баги.

• а Current – это версия с новой функциональностью.

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

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

 

 

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

• Фичи мы привязываем к UserStory.

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

Еще один момент – привязываем к фиче не только UserStory, но и инструкции.

 

 

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

Это полностью открытый ресурс, где можно посмотреть, как устроен наш продукт – мы ничего не скрываем.

В рамках релизов мы также публикуем официальные релизноты.

Если в Confluence мы пишем черновые заготовки, то в GitBook мы пишем реально то, что отдадим клиентам и нашим пользователям с точки зрения ролей, которые представлены в продукте:

• сотрудникам и руководителям;

• кадровому специалисту;

• и техническим специалистам.

 

 

Важно: в Jira есть бесплатный плагин по выпуску релизов – Releases.

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

 

 

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

 

 

И второй нюанс-неудобство – приходилось к каждой версии прикреплять те задачи и UserStory, которые выпускаем в рамках релиза. Это вообще неудобно.

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

 

Что важно при переходе на продуктовый подход?

 

 

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

1. Укомплектовать команду – без команды продукт не будет разработан.

2. Определиться со статусами, которые планируются использовать на доске задач. Статусы следует согласовать с командой и, в случае возникновения вопросов, обсуждать их на ретроспективах. Так команда становится намного более открытой и сплоченной.

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

4. Начать проводить дейли и ретроспективы.

5. Подключать команду к встречам по обзору – так команда будет гордиться тем, что она сделала, становится сплоченнее и понимает ответственность, что она делает продукт для пользователей.

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

 

Вопросы и ответы

 

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

Например, те обязательства, которые мы подсветили на ретроспективе, мы закрепляем в командном чате Telegram. И каждую неделю по понедельникам к ним возвращаемся.

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

А если это техническая идея, у нас есть CTO продукта – мы с ним также встречаемся каждую неделю и обсуждаем технические проблемы, которые у нас возникают.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.