Меня зовут Александр Винницкий, я СТО и co-founder компаний Svitsoft и AdSaver.
Этот материал будет полезен продуктовым командам, которые ищут варианты оптимальной организации работы над новыми фичами, стремятся минимизировать технический долг, поддерживая высокую скорость разработки и при этом не теряя в качестве.
Наш продукт имеет широкий спектр применения — это и CRM, и аналитическая система, и телефония, и колл-центр. Поэтому существует множество векторов его развития. В то же время ресурсы не бесконечны, выбор приоритетов критически важен. Мы хотим, чтобы каждый час разработки был максимально эффективен, и ключ к этому видим в качественной работе с бэклогом.
Бэклог продукта — это упорядоченный список всего, над чем команда должна работать; единственный источник требований, относящихся к фичам, которые будет иметь продукт. Элементы бэклога — это User Stories. От громоздкой документации сторис отличаются тем, что доходчиво и на языке пользователя описывают требования. Да и сам бэклог у нас заполняется простым и доступным языком без сложных технических спецификаций для того, чтобы он был понятен каждому в команде. Все элементы в нем сгруппированы в зависимости от их веса для бизнеса. Чем он больше, тем быстрее элемент отправиться в разработку.
Чаще всего в нашем бэклоге встречаются задачи, которые начинаются со слов «доработка», «добавление», «улучшение». Например, доработка функциональности календаря, добавление новых признаков для фильтрации по данным источников, улучшение скорости передачи данных в сторонние системы и многое другое. Зачастую они и реализовываются быстро. Но вот когда дело доходит до более-менее нового функционала, тут мы уже формулируем задачу в общих чертах, после чего она разрастается до полноценной фичи.
Например, описание задачи из бэклога с названием «Массовые действия над сущностями»: суть задачи состоит в том, чтобы «у пользователей была возможность выбрать 2 и более сущностей из списка и реализовать с ними стандартное одинаковое действие вроде смены ответственного, установки общего дедлайна или перенесение сделок на нужный этап для упрощения рутинной работы менеджеров». Описание весьма короткое, но команде уже ясно, о каких массовых действиях идет речь, и специалисты уже могут предлагать свои варианты реализации.
Бэклог продукта обладает определенными свойствами:
Из-за разной трудоемкости фич, их меняющейся важности и внезапных пожеланий клиентов, на которые нужно быстро реагировать, мы поняли, что Аgile и спринты нам не подходят. Поэтому мы работаем по более гибкому канбану, так как для нас важно, чтобы каждый элемент, которым занимаемся, как можно быстрее дошел до финальной стадии.
Мы не смотрим, что войдет в следующий релиз, а смотрим на то, как ту или иную фичу быстрее зарелизить клиенту. К тому же часто в процессе выполнения можем передумать и поменять подход к реализации, а если фиксировать все в спринтах, менять что-то становится уже проблематично. Для операционных команд с постоянно меняющимися приоритетами, которые ведут непрерывную поставку продукта, канбан подходит идеально.
Мы детально прорабатываем каждую фичу, и нередко работа над постановкой задачи по ней может занять время, сопоставимое с реализацией. Поэтому для планирования у нас отдельный борд. За каждым типом работ закреплен ответственный специалист, у которого есть своя производительность и своя колонка в бэклоге. Ответственность проджект-менеджера — следить за тем, чтобы производительность людей на разных колонках была сопоставима.
Для наглядности давайте посмотрим на то, какой процесс проходит заявка от идеи до передачи к разработчику.
То есть описание необходимости с использованием параметров Value и Efforts. Первая показывает, какую бизнес-ценность может принести продукт. Вторая измеряет ресурсы, которые нужны для реализации задачи.
Если это запрос от клиента или пожелания по доработке, придумываем, какой функционал системы будет полезен нам, чтобы мы могли использовать его в дальнейшем и при этом он покрывал клиентский запрос. У нас есть опросник, в рамках которого выясняем, например, какому количеству пользователей это полезно? Как эта задача скажется на конечной стоимости продукта? Удешевит ли она поддержку? И так далее. В результате ответов получаем какое-то количество баллов. Так определяется приоритетность — и приоритетные фичи попадают в работу.
Опросник для приоритизации фич команды AdSaver
Второй этап — переход фич на стадию анализа аналогов (АА). Можем это также назвать UX research. Смотрим на то, как подобный функционал реализован в других системах. Обсуждаем, собираем опыт, анализируем техническое решение и UX-аналоги. Собранные данные изучает бизнес-аналитик. Если у него есть замечания, АА отправляется на доработку. Если нет — создаются User Stories.
Третий этап — это BA. Функционирование будущей фичи описывается с точки зрения пользователя. Это не программистское описание, а именно пользовательское, которое чем-то должно быть похоже на инструкцию.
Четвертый этап — отрисовка прототипов. По сторис рисуется первый прототип, его анализируют. После прохождения бизнес-аналитики, всех правок и апрувов дизайнер готовит уже более-менее чистовой вариант, где показывает экраны, кнопки и все, что необходимо. Все прототипы кликабельные.
Пятый этап — это защита. Автор фичи продает ее команде и объясняет, почему ее надо сделать. Как правило, здесь в фокусе какая-то одна функция или сценарий использования. Главное — это ответ на вопрос «почему именно это, а не что-то другое?». Фактически это квинтэссенция работы ВА, UX и CRM, которую команда или поддерживает, или нет.
Все задачи должны обладать тремя характеристиками: быть конкретными, достижимыми и конечными. То есть при постановке задачи мы хотим, чтобы она была исчерпывающей и согласованной с клиентом, а у разработчиков, которые будут вычитывать фичу, не возникало ни одного вопроса.
И очень важно — фича должна быть реальной. То есть она пишется с учетом реального функционала для расширения дальнейшего. Нельзя прийти и сказать «я хочу вот этот функционал, вот вам ТЗ, пилите». Нет. Нужно обязательно знать систему и то, как она работает, чтобы новый функционал корректно ложился на все существующее сейчас.
Именно такой подход дает уверенность в том, что мы делаем то, что надо. Наглядным примером такого подхода может служить недавняя реализация фичи «Конструктор кастомных полей» в рамках CRM-системы AdSaver.
Суть задачи заключалась в том, чтобы дать возможность пользователям самостоятельно создавать и вносить нужные им поля и их значения для работы со сделками, контактами, обращениями в рамках собственных бизнес-процессов. Например, отделу продаж ЖК требуется указывать характеристики квартир и самого комплекса, а интернет-магазинам нужны детали по адресам доставки. Все эти данные могут регулярно обновляться: например, появилась новая информация о квартирах, которая может заинтересовать пользователей; при доставке стали учитываться вкусовые предпочтения заказчика и так далее. Поэтому мы хотели реализовать инструмент, благодаря которому и пользователи системы, и наши специалисты смогут быстро вносить изменения в данные.
Изучив аналоги, мы пришли к выводу, что в основном все конкуренты используют расширенные функционалы карточек сущностей и позволяют администраторам создавать новые поля прямо в карточке (например, «Битрикс24»). Также часто встречался инструмент для настройки дополнительных полей для каждой сущности, как в конструкторе. Его мы и взяли за основу реализации.
Следующим этапом стало составление подробного ТЗ бизнес-аналитиком для такого конструктора с учетом уникальности нашей системы. В процессе были продуманы кейсы для создания полей разных типов для каждой из сущностей (строка, разные виды списков, дата, чек-боксы), что позволило нашим разработчикам быстро понять суть задачи.
Далее было создание дизайна, его согласование с бизнес-аналитиком и автором фичи, внесение незначительных корректировок. И скоро фича была представлена уже перед всей командой.
Защита фичи перед командой — одна из важнейших частей процесса, так как здесь уже знающие о сути функционала люди презентуют идею коллегам со свежим взглядом, которые и будут ее реализовывать. На данном этапе разработчики смотрят на новый функционал с точки зрения возможных реализаций в коде, поэтому иногда могут придумать такой вариант, что сократит планируемые сроки едва ли не вдвое. В случае с конструктором кастомных полей мы очень тщательно подошли к проектированию, бизнес-аналитик регулярно обращался к разработчикам за консультациями, а доработки ТЗ после защиты фичи, ввиду их незначительности, были готовы уже на следующий день.
Обычно главная боль всегда начинается на этапе тестирования, но учитывая то, что вся команда была в курсе сути и реализации фичи, то и тестировщику было легко определить баг и понять, откуда он вылез, и разработчику было несложно решить эту задачу.
Важно ещё отметить, что при внедрении любого функционала большое количество новых кейсов и идей к нам приходят уже в процессе работы. Это может быть незначительный выпадающий список, кнопка в правом углу экрана, простая сноска с объяснениями или же вовсе не видимый для пользователя скрипт, который позволяет добавить небольшую анимацию при создании нового поля. Каждый из команды в нашем случае добавил что-то свое.
Все это не просто упрощает работу пользователя, но и создает тот самый полноценный функционал, благодаря которому новый юзер сможет открыть конструктор и без вопросов, консультаций и чтений мануалов настроить систему и ее сущности так, как ему необходимо.
Основные наши клиенты — это отделы продаж жилых комплексов. И около 30% менеджеров постоянно изъявляют желание принимать участие в процессах улучшения продукта для того, чтоб им же было в нем комфортнее работать в будущем. На основании таких запросов система AdSaver максимально оптимизировалась, а количество жалоб снизилось втрое.
В своей команде мы стремимся уходить от общего к частностям и постоянно добавляем новые этапы для того, чтобы сложный процесс разложить на множество простых, которые проще контролировать. Благодаря этому мы видим возможности скейлинга, гарантирования качества и имеем уверенность в том, что все делаем правильно.
dou.ua
Этот материал будет полезен продуктовым командам, которые ищут варианты оптимальной организации работы над новыми фичами, стремятся минимизировать технический долг, поддерживая высокую скорость разработки и при этом не теряя в качестве.
Наш продукт имеет широкий спектр применения — это и CRM, и аналитическая система, и телефония, и колл-центр. Поэтому существует множество векторов его развития. В то же время ресурсы не бесконечны, выбор приоритетов критически важен. Мы хотим, чтобы каждый час разработки был максимально эффективен, и ключ к этому видим в качественной работе с бэклогом.
Бэклог продукта — это упорядоченный список всего, над чем команда должна работать; единственный источник требований, относящихся к фичам, которые будет иметь продукт. Элементы бэклога — это User Stories. От громоздкой документации сторис отличаются тем, что доходчиво и на языке пользователя описывают требования. Да и сам бэклог у нас заполняется простым и доступным языком без сложных технических спецификаций для того, чтобы он был понятен каждому в команде. Все элементы в нем сгруппированы в зависимости от их веса для бизнеса. Чем он больше, тем быстрее элемент отправиться в разработку.
Чаще всего в нашем бэклоге встречаются задачи, которые начинаются со слов «доработка», «добавление», «улучшение». Например, доработка функциональности календаря, добавление новых признаков для фильтрации по данным источников, улучшение скорости передачи данных в сторонние системы и многое другое. Зачастую они и реализовываются быстро. Но вот когда дело доходит до более-менее нового функционала, тут мы уже формулируем задачу в общих чертах, после чего она разрастается до полноценной фичи.
Например, описание задачи из бэклога с названием «Массовые действия над сущностями»: суть задачи состоит в том, чтобы «у пользователей была возможность выбрать 2 и более сущностей из списка и реализовать с ними стандартное одинаковое действие вроде смены ответственного, установки общего дедлайна или перенесение сделок на нужный этап для упрощения рутинной работы менеджеров». Описание весьма короткое, но команде уже ясно, о каких массовых действиях идет речь, и специалисты уже могут предлагать свои варианты реализации.
Бэклог продукта обладает определенными свойствами:
- Любая отметка в нем прибавляет бизнес-ценность для клиентов. Это не просто некая абстрактная запись, а то, что впоследствии будет нести пользу пользователю.
- Абсолютно все записи в нем оценены и приоритизированы.
- Это живой документ, над которым постоянно работают. В отличие от обычного to-do list, в бэклог нельзя внести что-то и забыть про него до лучших времен. Все задачи регулярно двигаются и перемещаются в приоритетности.
Почему мы выбрали канбан
Запросы на новые фичи в продукте могут поступать из различных источников. Это пользовательские истории, отзывы, баги, собственные инициативы, идеи маркетинга, изменения в дизайне, технический долг, запросы клиентов и так далее.Из-за разной трудоемкости фич, их меняющейся важности и внезапных пожеланий клиентов, на которые нужно быстро реагировать, мы поняли, что Аgile и спринты нам не подходят. Поэтому мы работаем по более гибкому канбану, так как для нас важно, чтобы каждый элемент, которым занимаемся, как можно быстрее дошел до финальной стадии.
Мы не смотрим, что войдет в следующий релиз, а смотрим на то, как ту или иную фичу быстрее зарелизить клиенту. К тому же часто в процессе выполнения можем передумать и поменять подход к реализации, а если фиксировать все в спринтах, менять что-то становится уже проблематично. Для операционных команд с постоянно меняющимися приоритетами, которые ведут непрерывную поставку продукта, канбан подходит идеально.
Мы детально прорабатываем каждую фичу, и нередко работа над постановкой задачи по ней может занять время, сопоставимое с реализацией. Поэтому для планирования у нас отдельный борд. За каждым типом работ закреплен ответственный специалист, у которого есть своя производительность и своя колонка в бэклоге. Ответственность проджект-менеджера — следить за тем, чтобы производительность людей на разных колонках была сопоставима.
Для наглядности давайте посмотрим на то, какой процесс проходит заявка от идеи до передачи к разработчику.
Пять этапов работы над фичей
Первый этап работы над фичей — это всегда ответ на вопрос «Почему мы вообще решили это сделать? Как это закрывает бизнес-потребность клиента и какова бизнес-цель?».То есть описание необходимости с использованием параметров Value и Efforts. Первая показывает, какую бизнес-ценность может принести продукт. Вторая измеряет ресурсы, которые нужны для реализации задачи.
Если это запрос от клиента или пожелания по доработке, придумываем, какой функционал системы будет полезен нам, чтобы мы могли использовать его в дальнейшем и при этом он покрывал клиентский запрос. У нас есть опросник, в рамках которого выясняем, например, какому количеству пользователей это полезно? Как эта задача скажется на конечной стоимости продукта? Удешевит ли она поддержку? И так далее. В результате ответов получаем какое-то количество баллов. Так определяется приоритетность — и приоритетные фичи попадают в работу.
Второй этап — переход фич на стадию анализа аналогов (АА). Можем это также назвать UX research. Смотрим на то, как подобный функционал реализован в других системах. Обсуждаем, собираем опыт, анализируем техническое решение и UX-аналоги. Собранные данные изучает бизнес-аналитик. Если у него есть замечания, АА отправляется на доработку. Если нет — создаются User Stories.
Третий этап — это BA. Функционирование будущей фичи описывается с точки зрения пользователя. Это не программистское описание, а именно пользовательское, которое чем-то должно быть похоже на инструкцию.
Четвертый этап — отрисовка прототипов. По сторис рисуется первый прототип, его анализируют. После прохождения бизнес-аналитики, всех правок и апрувов дизайнер готовит уже более-менее чистовой вариант, где показывает экраны, кнопки и все, что необходимо. Все прототипы кликабельные.
Пятый этап — это защита. Автор фичи продает ее команде и объясняет, почему ее надо сделать. Как правило, здесь в фокусе какая-то одна функция или сценарий использования. Главное — это ответ на вопрос «почему именно это, а не что-то другое?». Фактически это квинтэссенция работы ВА, UX и CRM, которую команда или поддерживает, или нет.
Все задачи должны обладать тремя характеристиками: быть конкретными, достижимыми и конечными. То есть при постановке задачи мы хотим, чтобы она была исчерпывающей и согласованной с клиентом, а у разработчиков, которые будут вычитывать фичу, не возникало ни одного вопроса.
И очень важно — фича должна быть реальной. То есть она пишется с учетом реального функционала для расширения дальнейшего. Нельзя прийти и сказать «я хочу вот этот функционал, вот вам ТЗ, пилите». Нет. Нужно обязательно знать систему и то, как она работает, чтобы новый функционал корректно ложился на все существующее сейчас.
Именно такой подход дает уверенность в том, что мы делаем то, что надо. Наглядным примером такого подхода может служить недавняя реализация фичи «Конструктор кастомных полей» в рамках CRM-системы AdSaver.
Суть задачи заключалась в том, чтобы дать возможность пользователям самостоятельно создавать и вносить нужные им поля и их значения для работы со сделками, контактами, обращениями в рамках собственных бизнес-процессов. Например, отделу продаж ЖК требуется указывать характеристики квартир и самого комплекса, а интернет-магазинам нужны детали по адресам доставки. Все эти данные могут регулярно обновляться: например, появилась новая информация о квартирах, которая может заинтересовать пользователей; при доставке стали учитываться вкусовые предпочтения заказчика и так далее. Поэтому мы хотели реализовать инструмент, благодаря которому и пользователи системы, и наши специалисты смогут быстро вносить изменения в данные.
Изучив аналоги, мы пришли к выводу, что в основном все конкуренты используют расширенные функционалы карточек сущностей и позволяют администраторам создавать новые поля прямо в карточке (например, «Битрикс24»). Также часто встречался инструмент для настройки дополнительных полей для каждой сущности, как в конструкторе. Его мы и взяли за основу реализации.
Следующим этапом стало составление подробного ТЗ бизнес-аналитиком для такого конструктора с учетом уникальности нашей системы. В процессе были продуманы кейсы для создания полей разных типов для каждой из сущностей (строка, разные виды списков, дата, чек-боксы), что позволило нашим разработчикам быстро понять суть задачи.
Далее было создание дизайна, его согласование с бизнес-аналитиком и автором фичи, внесение незначительных корректировок. И скоро фича была представлена уже перед всей командой.
Защита фичи перед командой — одна из важнейших частей процесса, так как здесь уже знающие о сути функционала люди презентуют идею коллегам со свежим взглядом, которые и будут ее реализовывать. На данном этапе разработчики смотрят на новый функционал с точки зрения возможных реализаций в коде, поэтому иногда могут придумать такой вариант, что сократит планируемые сроки едва ли не вдвое. В случае с конструктором кастомных полей мы очень тщательно подошли к проектированию, бизнес-аналитик регулярно обращался к разработчикам за консультациями, а доработки ТЗ после защиты фичи, ввиду их незначительности, были готовы уже на следующий день.
Обычно главная боль всегда начинается на этапе тестирования, но учитывая то, что вся команда была в курсе сути и реализации фичи, то и тестировщику было легко определить баг и понять, откуда он вылез, и разработчику было несложно решить эту задачу.
Важно ещё отметить, что при внедрении любого функционала большое количество новых кейсов и идей к нам приходят уже в процессе работы. Это может быть незначительный выпадающий список, кнопка в правом углу экрана, простая сноска с объяснениями или же вовсе не видимый для пользователя скрипт, который позволяет добавить небольшую анимацию при создании нового поля. Каждый из команды в нашем случае добавил что-то свое.
Все это не просто упрощает работу пользователя, но и создает тот самый полноценный функционал, благодаря которому новый юзер сможет открыть конструктор и без вопросов, консультаций и чтений мануалов настроить систему и ее сущности так, как ему необходимо.
Основные наши клиенты — это отделы продаж жилых комплексов. И около 30% менеджеров постоянно изъявляют желание принимать участие в процессах улучшения продукта для того, чтоб им же было в нем комфортнее работать в будущем. На основании таких запросов система AdSaver максимально оптимизировалась, а количество жалоб снизилось втрое.
Вывод
Чем больше вы инвестируете в постановку задач и превращаете ее из атомарной задачи в процесс, тем большую ценность будут приносить ваши разработчики.В своей команде мы стремимся уходить от общего к частностям и постоянно добавляем новые этапы для того, чтобы сложный процесс разложить на множество простых, которые проще контролировать. Благодаря этому мы видим возможности скейлинга, гарантирования качества и имеем уверенность в том, что все делаем правильно.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua