Всем привет! Наша команда развивает облачный сервис Okdesk — Help Desk систему для обслуживания клиентов в b2b сегменте. Наша стратегия продаж — не “впаривать”, а решать насущные проблемы клиентов. Поэтому особое внимание мы уделяем развитию функциональности продукта (пожалуй, так о себе может написать каждый:).
В разработке продукта нам приходится балансировать между долгосрочными планами развития и текущими пожеланиями активных клиентов. Ведь нужно поддерживать лояльность тех, кто уже выбрал наш сервис (улучшать созданные функции, повышать удобство работы и т.д.) и развивать новые функциональные блоки, ориентированные на тех, чьи проблемы мы пока решаем не в полной мере. Задача кажется простой, если есть неограниченное количество рук, голов и времени — но в реальном мире все обстоит иначе.
Под катом расскажем о том, как мы решаем описанные выше задачи, как устроен процесс разработки продукта, а также поделимся планами на 2017 год.
Развитие ИТ-продукта можно сравнить со строительством здания. В начале вы разрабатываете проект здания, далее делаете фундамент и несущие конструкции, заводите коммуникации, монтируете окна. В принципе, когда готова “коробка” — в ней можно прятаться от дождя и ветра, греться зимой (если есть отопление). Но чтобы чувствовать себя комфортно нужно обживаться — заниматься внутренней планировкой, ремонтом, покупать и расставлять мебель. При этом, внутреннюю планировку и отделку вы можете дополнять и изменять при необходимости в процессе “использования” здания без его перестройки.
Так и в “строительстве” ИТ-продукта. Есть изначальный верхнеуровневый план развития, сформулированный в терминах крупных функциональных блоков. Этот план исходит из реальных проблем клиентов, на решение которых ориентирован продукт. Для составления такого плана проводится анализ рынка, конкурентов, интервьюирование клиентов (например, мы проинтервьюировали несколько сотен сервисных компаний из разных отраслей). Верхнеуровневый план может меняться при получении обратной связи от рынка — но не радикально (в основном, с точки зрения приоритетов). Радикальное изменение плана возможно, но только вместе со сменой концепции всего проекта, что в народе именуется как “pivot”.
Не имея хоть какой-то реализации крупных функциональных блоков, сложно формулировать правильные требования к деталям — элементам интерфейса, удобству, прочим функциям, входящим в блок. После реализации первой версии крупного функционального блока и началу использования новых функций, у создателей продукта начинают накапливаться пожелания по их развитию — через собственный опыт и получение обратной связи от активных пользователей (подробнее об этом в следующем разделе)
Таким образом, в backlog-е продукта присутствуют крупные “стратегические” задачи, и накапливаются менее крупные задачи по улучшению созданной ранее функциональности. Крупные задачи нужны для расширения применимости продукта (рост бизнеса). Улучшения нужны для того, чтобы работа в системе была удобной и полноценной (повышение лояльности действующих клиентов и сокращение оттока).
Для поддержания баланса между крупными задачами и улучшениями мы разделили backlog продукта по типу задач, и в каждый продуктовый релиз включаем задачи каждого из типов (обычно — одну большую и несколько улучшений сделанного ранее). Таким образом, развитие продукта идет “по двум полосам”. Такой подход позволяет нам радовать действующих клиентов и привлекать новых, чьи задачи мы не могли решать ранее.
Обратная связь от пользователей является важным источником ценных требований к развитию продукта. Все пожелания необходимо фиксировать и анализировать. А в дальнейшем принимать решение о реализации новых функций.
Нет сомнений, что обратная связь от пользователей важна. Но не всегда и не от всех. В этом контексте пользователи бывают принципиально двух типов — клиенты и не клиенты.
Когда “не клиенты” только изучают систему, они могут дать обратную связь. Обычно это список требований в стиле: “я куплю, если вы сделаете это...”. Бросаться с головой в реализацию требуемых функций, в надежде получить еще одного клиента бессмысленно (особенно силен этот соблазн на ранних стадиях проекта, когда каждый новый подписчик дает заметный относительный прирост). Чаще всего данные требования являются не причиной отказа в покупке, а поводом. Причина может быть какой угодно (нет денег, устраивает текущее положение дел и так далее). К слову, по нашей уже накопленной статистике, процент тех, кто просто смотрит и не совершает покупку даже в течение года — достаточно высокий. Поэтому, если пользователь говорит “я бы купил, если бы вы сделали…”, мы отвечаем “мы сделаем, если вы купите…”. И когда такой пользователь становится клиентом — с его требованиями мы работаем уже полноценно. То есть настоящую ценность имеют пожелания, тех, кто перешел на этап “Успешная продажа” в воронке. У клиентов нет причины, чтобы искать изъяны или недоделки. Они сообщают о том, что им мешает или чего не хватает в системе в рамках ежедневной работы и бизнес задач.
Важно понимать, что за сформулированным требованием скрывается реальный сценарий использования системы. Присылаемое требование — уже сформулированный вариант решения проблемы, с которой столкнулся пользователь. Этот вариант решения придуман непосредственно им, зачастую за пару минут и без системного подхода. Проблема в том, что это решение не всегда оптимально. Поэтому мы каждый раз уточняем сценарий использования и проблему, с которой сталкивается пользователь. Такой подход дает возможность предложить оптимальное и системное решение проблемы, которая, с большой вероятностью, рано или поздно возникла бы и у других клиентов. Реализация же пользовательских требований “как есть” может со временем превратить систему в непригодный набор “заплаток” (каким, к сожалению, становятся через пару лет большинство решений).
Приведем пример из нашего опыта. В Okdesk есть панель с оперативной информацией о работе службы поддержки:
На квадратных плитках отображается количество заявок, соответствующих тому или иному критерию. В частности, на одной из плиток отображается информация о незакрытых, но просроченных заявках. Некоторое время назад от одного из наших клиентов поступило требование: сделать возможным настройку параметров фильтрации, по которым идет подсчет заявок в каждой из плиток. Начали разбираться в сценарии использования и проблеме.
Оказалось, что по бизнес-процессу компании, у заявок существуют статусы, в рамках которых, например, ожидается ответ от заявителя, либо ожидается поставка запчастей. Заявки, которые находятся в данных статусах продолжительное время, считаются системой просроченными (и, соответственно, подсчитываются на одной из плиток). Клиент предложил решение — настраивать параметры фильтрации для плитки, в рамках чего он сможет исключить заявки в “замороженных” статусах из подсчета. Но мы нашли другое решение — реализовать в настройках бизнес-процессов параметр “Учитывать время” для статуса. Таким образом, клиент сможет настроить “заморозку” счетчика времени, и отложенные заявки не будут считаться просроченными.
Если бы мы бросились реализовать пользовательское требование “как оно есть”, то потратили бы много времени на его разработку (в первую очередь — на разработку удобного интерфейсного решения). Но, углубившись на уровень сценариев использования и проблем, мы смогли найти более простое и понятное решение.
В заключении раздела хочется обратить внимание на тот очевидный факт, что обратная связь от пользователя ожидает обратной связи от вас. Если пользователь сформулировал требование или пожелание к системе — важно дать ответ о планах разработки. А когда (и если) ожидаемая функция будет реализована, важно не забыть проинформировать пользователя об этом событии. Во многом, обеспечение обратной связи по пользовательским требованиям пересекается с процессами технической поддержки. Поэтому логичным будет собирать первичные пожелания пользователей и давать им обратную связь в Help Desk системе.
Например, для поддержки пользователей Okdesk мы используем Okdesk :). Основные каналы поступления обращений — email и клиентский портал. Поэтому все обращения автоматически становятся заявками в системе. Если обращение является пожеланием к развитию системы, мы уточняем детали пользовательского сценария и описание проблемы. Взаимодействие с пользователем происходит как в рамках переписки по заявке, так и в рамках телефонных разговоров. После выяснения всех подробностей, тикеты с пожеланиями переводятся в специальный статус “Ожидание разработки”.
При выпуске нового релиза мы проверяем все заявки в данном статусе, и если какая-то часть из них полностью или частично решается новой функциональностью — сообщаем радостную новость пользователям. Пользователи довольны и ощущают нашу заботу :)
Несколько слов о том, как у нас устроены процессы управления требованиями и разработкой, а также какие инструменты при этом используются.
Выше мы уже рассказали, как формируется долгосрочный план развития продукта, откуда берутся варианты развития, и как проводится работа с обратной связью от клиентов. Когда план есть — нужно по нему работать.
Перед разработкой кода мы пишем постановки (спецификации, ТЗ — кому как удобно). Все требования разбиты по крупным функциональным модулям и внутри модулей сгруппированы в смысловые блоки. Например, есть крупный функциональный блок “01. Модуль учета заявок”. В нем ряд смысловых блоков “01.01. Карточка заявки”, “01.02. Комментарии к заявкам”, “01.03. Список заявок” и так далее. Отдельно ведем список изменений в требованиях по каждому релизу. Для каждого требования описываем кейсы, варианты решения и причину выбора одного из вариантов. Для всех — ведем (и актуализируем при изменениях) список Test-кейсов. Дорогих специализированных инструментов мы не покупали — на текущий момент хватает Google Docs.
Когда требование готово, начинается разработка. Для всех задач мы проводим Code Review (один из основателей проекта отвечает за технологическую часть). После этого новая функция выкатывается на тестовый сервер для поверхностного визуального тестирования — его осуществляет тот же человек, что разрабатывал требование. Если замечания есть — они отправляются на устранение, если замечаний нет — задача уходит на детальное ручное тестирование. После устранения всех замечаний новая задача покрывается автотестами в соответствии с написанными Test-кейсами.
После того как все задачи текущего релиза готовы — прогоняем повторное ручное тестирование версии, где собраны все новые функции. Если замечаний нет, скрещиваем пальцы и выкатываем новые функции клиентам.
Новый релиз мы стараемся выпускать каждые 3-5 недель. В каждый релиз включаем одну большую функцию и ряд улучшений ранее сделанного. Но бывают большие функциональные блоки, которые не умещаются в один релиз — например, с недели на неделю увидит свет мобильное приложение для работы с заявкам “полевых” сотрудников. На его разработку ушло около 3 месяцев.
Используемые в работе инструменты: Google Docs для документов и управления требованиями, Redmine для управления разработкой, GitHub для кода, Slack для коммуникаций, Okdesk для технической поддержки и работы с обратной связью от клиентов.
Ну и напоследок немного о наших планах (именно планах) по разработке крупных функциональных блоков на 2017 год.
С недели на неделю появится мобильное приложение для полноценной работы с заявками “на выезде”. Мобильное приложение будет доступно для платформ Android и iOS (сначала выйдет Android, iOS чуть позже).
Следом за мобильным приложением появится возможность учета объектов обслуживания в рамках клиентов (магазины, здания, филиалы и дополнительные офисы). А затем — учет клиентского оборудования (от компьютерной техники до холодильников и охранных систем) в привязке, в том числе, к объектам обслуживания.
И, конечно же, мы выпустим множество различных улучшений, делающих работу в системе более удобной и покрывающей бОльшее количество реальных клиентских кейсов. Кажется, будет интересно!
Разумных всем требований, системного подхода и хороших продуктов!
С наступающим Новым Годом!
В разработке продукта нам приходится балансировать между долгосрочными планами развития и текущими пожеланиями активных клиентов. Ведь нужно поддерживать лояльность тех, кто уже выбрал наш сервис (улучшать созданные функции, повышать удобство работы и т.д.) и развивать новые функциональные блоки, ориентированные на тех, чьи проблемы мы пока решаем не в полной мере. Задача кажется простой, если есть неограниченное количество рук, голов и времени — но в реальном мире все обстоит иначе.
Под катом расскажем о том, как мы решаем описанные выше задачи, как устроен процесс разработки продукта, а также поделимся планами на 2017 год.
Баланс между большими “фичами” и небольшими улучшениями
Развитие ИТ-продукта можно сравнить со строительством здания. В начале вы разрабатываете проект здания, далее делаете фундамент и несущие конструкции, заводите коммуникации, монтируете окна. В принципе, когда готова “коробка” — в ней можно прятаться от дождя и ветра, греться зимой (если есть отопление). Но чтобы чувствовать себя комфортно нужно обживаться — заниматься внутренней планировкой, ремонтом, покупать и расставлять мебель. При этом, внутреннюю планировку и отделку вы можете дополнять и изменять при необходимости в процессе “использования” здания без его перестройки.
Так и в “строительстве” ИТ-продукта. Есть изначальный верхнеуровневый план развития, сформулированный в терминах крупных функциональных блоков. Этот план исходит из реальных проблем клиентов, на решение которых ориентирован продукт. Для составления такого плана проводится анализ рынка, конкурентов, интервьюирование клиентов (например, мы проинтервьюировали несколько сотен сервисных компаний из разных отраслей). Верхнеуровневый план может меняться при получении обратной связи от рынка — но не радикально (в основном, с точки зрения приоритетов). Радикальное изменение плана возможно, но только вместе со сменой концепции всего проекта, что в народе именуется как “pivot”.
Не имея хоть какой-то реализации крупных функциональных блоков, сложно формулировать правильные требования к деталям — элементам интерфейса, удобству, прочим функциям, входящим в блок. После реализации первой версии крупного функционального блока и началу использования новых функций, у создателей продукта начинают накапливаться пожелания по их развитию — через собственный опыт и получение обратной связи от активных пользователей (подробнее об этом в следующем разделе)
Таким образом, в backlog-е продукта присутствуют крупные “стратегические” задачи, и накапливаются менее крупные задачи по улучшению созданной ранее функциональности. Крупные задачи нужны для расширения применимости продукта (рост бизнеса). Улучшения нужны для того, чтобы работа в системе была удобной и полноценной (повышение лояльности действующих клиентов и сокращение оттока).
Для поддержания баланса между крупными задачами и улучшениями мы разделили backlog продукта по типу задач, и в каждый продуктовый релиз включаем задачи каждого из типов (обычно — одну большую и несколько улучшений сделанного ранее). Таким образом, развитие продукта идет “по двум полосам”. Такой подход позволяет нам радовать действующих клиентов и привлекать новых, чьи задачи мы не могли решать ранее.
Работа с пожеланиями клиентов
Обратная связь от пользователей является важным источником ценных требований к развитию продукта. Все пожелания необходимо фиксировать и анализировать. А в дальнейшем принимать решение о реализации новых функций.
Нет сомнений, что обратная связь от пользователей важна. Но не всегда и не от всех. В этом контексте пользователи бывают принципиально двух типов — клиенты и не клиенты.
Когда “не клиенты” только изучают систему, они могут дать обратную связь. Обычно это список требований в стиле: “я куплю, если вы сделаете это...”. Бросаться с головой в реализацию требуемых функций, в надежде получить еще одного клиента бессмысленно (особенно силен этот соблазн на ранних стадиях проекта, когда каждый новый подписчик дает заметный относительный прирост). Чаще всего данные требования являются не причиной отказа в покупке, а поводом. Причина может быть какой угодно (нет денег, устраивает текущее положение дел и так далее). К слову, по нашей уже накопленной статистике, процент тех, кто просто смотрит и не совершает покупку даже в течение года — достаточно высокий. Поэтому, если пользователь говорит “я бы купил, если бы вы сделали…”, мы отвечаем “мы сделаем, если вы купите…”. И когда такой пользователь становится клиентом — с его требованиями мы работаем уже полноценно. То есть настоящую ценность имеют пожелания, тех, кто перешел на этап “Успешная продажа” в воронке. У клиентов нет причины, чтобы искать изъяны или недоделки. Они сообщают о том, что им мешает или чего не хватает в системе в рамках ежедневной работы и бизнес задач.
Важно понимать, что за сформулированным требованием скрывается реальный сценарий использования системы. Присылаемое требование — уже сформулированный вариант решения проблемы, с которой столкнулся пользователь. Этот вариант решения придуман непосредственно им, зачастую за пару минут и без системного подхода. Проблема в том, что это решение не всегда оптимально. Поэтому мы каждый раз уточняем сценарий использования и проблему, с которой сталкивается пользователь. Такой подход дает возможность предложить оптимальное и системное решение проблемы, которая, с большой вероятностью, рано или поздно возникла бы и у других клиентов. Реализация же пользовательских требований “как есть” может со временем превратить систему в непригодный набор “заплаток” (каким, к сожалению, становятся через пару лет большинство решений).
Приведем пример из нашего опыта. В Okdesk есть панель с оперативной информацией о работе службы поддержки:
На квадратных плитках отображается количество заявок, соответствующих тому или иному критерию. В частности, на одной из плиток отображается информация о незакрытых, но просроченных заявках. Некоторое время назад от одного из наших клиентов поступило требование: сделать возможным настройку параметров фильтрации, по которым идет подсчет заявок в каждой из плиток. Начали разбираться в сценарии использования и проблеме.
Оказалось, что по бизнес-процессу компании, у заявок существуют статусы, в рамках которых, например, ожидается ответ от заявителя, либо ожидается поставка запчастей. Заявки, которые находятся в данных статусах продолжительное время, считаются системой просроченными (и, соответственно, подсчитываются на одной из плиток). Клиент предложил решение — настраивать параметры фильтрации для плитки, в рамках чего он сможет исключить заявки в “замороженных” статусах из подсчета. Но мы нашли другое решение — реализовать в настройках бизнес-процессов параметр “Учитывать время” для статуса. Таким образом, клиент сможет настроить “заморозку” счетчика времени, и отложенные заявки не будут считаться просроченными.
Если бы мы бросились реализовать пользовательское требование “как оно есть”, то потратили бы много времени на его разработку (в первую очередь — на разработку удобного интерфейсного решения). Но, углубившись на уровень сценариев использования и проблем, мы смогли найти более простое и понятное решение.
В заключении раздела хочется обратить внимание на тот очевидный факт, что обратная связь от пользователя ожидает обратной связи от вас. Если пользователь сформулировал требование или пожелание к системе — важно дать ответ о планах разработки. А когда (и если) ожидаемая функция будет реализована, важно не забыть проинформировать пользователя об этом событии. Во многом, обеспечение обратной связи по пользовательским требованиям пересекается с процессами технической поддержки. Поэтому логичным будет собирать первичные пожелания пользователей и давать им обратную связь в Help Desk системе.
Например, для поддержки пользователей Okdesk мы используем Okdesk :). Основные каналы поступления обращений — email и клиентский портал. Поэтому все обращения автоматически становятся заявками в системе. Если обращение является пожеланием к развитию системы, мы уточняем детали пользовательского сценария и описание проблемы. Взаимодействие с пользователем происходит как в рамках переписки по заявке, так и в рамках телефонных разговоров. После выяснения всех подробностей, тикеты с пожеланиями переводятся в специальный статус “Ожидание разработки”.
При выпуске нового релиза мы проверяем все заявки в данном статусе, и если какая-то часть из них полностью или частично решается новой функциональностью — сообщаем радостную новость пользователям. Пользователи довольны и ощущают нашу заботу :)
Управление требованиями и процесс разработки Help Desk
Несколько слов о том, как у нас устроены процессы управления требованиями и разработкой, а также какие инструменты при этом используются.
Выше мы уже рассказали, как формируется долгосрочный план развития продукта, откуда берутся варианты развития, и как проводится работа с обратной связью от клиентов. Когда план есть — нужно по нему работать.
Перед разработкой кода мы пишем постановки (спецификации, ТЗ — кому как удобно). Все требования разбиты по крупным функциональным модулям и внутри модулей сгруппированы в смысловые блоки. Например, есть крупный функциональный блок “01. Модуль учета заявок”. В нем ряд смысловых блоков “01.01. Карточка заявки”, “01.02. Комментарии к заявкам”, “01.03. Список заявок” и так далее. Отдельно ведем список изменений в требованиях по каждому релизу. Для каждого требования описываем кейсы, варианты решения и причину выбора одного из вариантов. Для всех — ведем (и актуализируем при изменениях) список Test-кейсов. Дорогих специализированных инструментов мы не покупали — на текущий момент хватает Google Docs.
Когда требование готово, начинается разработка. Для всех задач мы проводим Code Review (один из основателей проекта отвечает за технологическую часть). После этого новая функция выкатывается на тестовый сервер для поверхностного визуального тестирования — его осуществляет тот же человек, что разрабатывал требование. Если замечания есть — они отправляются на устранение, если замечаний нет — задача уходит на детальное ручное тестирование. После устранения всех замечаний новая задача покрывается автотестами в соответствии с написанными Test-кейсами.
После того как все задачи текущего релиза готовы — прогоняем повторное ручное тестирование версии, где собраны все новые функции. Если замечаний нет, скрещиваем пальцы и выкатываем новые функции клиентам.
Новый релиз мы стараемся выпускать каждые 3-5 недель. В каждый релиз включаем одну большую функцию и ряд улучшений ранее сделанного. Но бывают большие функциональные блоки, которые не умещаются в один релиз — например, с недели на неделю увидит свет мобильное приложение для работы с заявкам “полевых” сотрудников. На его разработку ушло около 3 месяцев.
Используемые в работе инструменты: Google Docs для документов и управления требованиями, Redmine для управления разработкой, GitHub для кода, Slack для коммуникаций, Okdesk для технической поддержки и работы с обратной связью от клиентов.
Наши планы на 2017 год
Ну и напоследок немного о наших планах (именно планах) по разработке крупных функциональных блоков на 2017 год.
С недели на неделю появится мобильное приложение для полноценной работы с заявками “на выезде”. Мобильное приложение будет доступно для платформ Android и iOS (сначала выйдет Android, iOS чуть позже).
Следом за мобильным приложением появится возможность учета объектов обслуживания в рамках клиентов (магазины, здания, филиалы и дополнительные офисы). А затем — учет клиентского оборудования (от компьютерной техники до холодильников и охранных систем) в привязке, в том числе, к объектам обслуживания.
И, конечно же, мы выпустим множество различных улучшений, делающих работу в системе более удобной и покрывающей бОльшее количество реальных клиентских кейсов. Кажется, будет интересно!
Разумных всем требований, системного подхода и хороших продуктов!
С наступающим Новым Годом!
Поделиться с друзьями