Customer Driven Development & история одного стартапа
Из статьи вы узнаете: что такое Customer Driven Development, как его используют западные компании и каким образом он позволил нашему стартапу за 6 месяцев утроить главные метрики.
Привет, я Максим Дьяков, основатель крупнейшего в России сообщества разработчиков Russian Hackers. Мы занимаемся организацией хакатонов, консалтингом по их проведению и помогаем разработчикам стать фаундерами инди-стартапов или устроиться на работу. Но речь в этой статье пойдет о подходе, который мы стараемся имплементировать при работе над нашим IT продуктом - самой популярной на данный момент платформе по организации хакатонов HackeR.
B начале было слово...
Начнем с небольшого интро как создавалась наша платформа. В 2018 году перед нами встала задача организация масштабного международного хакатона в условиях крайне ограниченных ресурсов. Так как вся наша команда - выходцы из IT, конечно же как решение была выбрана автоматизация всех процессов, чтобы не заниматься лишней рутинной.
И здесь нам повезло: мы приняли правильное решение - вместо того, чтобы пилить что-то с нуля (а программисты такое правда очень любят), мы решили поискать подходящий проект на GitHub и допилить его напильником под себя. Это позволило в 10 раз ускорить всю разработку и получить очень качественную базовую архитектуру.
Дальше был 2019, еще пара мероприятий, где мы всё также, как истинные программисты, думали, какую еще рутину можно оптимизировать, но кроме этого появлялись новые фичи, которые помогали нам повышать качество ивентов.
И тут наступила зима 2020 - переломный момент во всей нашей истории. К нам пришли знакомые организаторы с запросом: “мы видели, вы используете какую-то интересную систему регистрации, можете дать потестить?” В момент у нас стрельнула идея сделать из нашего внутреннего инструмента, который к тому моменту уже был отточен на сложных форматах и 4000+ пользователях, настоящий IT продукт. И поехало: первый пилот, превращение в SaaS, адаптация под онлайн-ивенты…
Но как мы принимали решения как развивать продукт и какие фичи отправлять в разработку?
Спустя полгода, проводя ретроспективу, могу сказать, что нам скорее всего опять повезло и мы интуитивно выбрали Customer Driven Development, который позволил за 5 месяцев в 3 раза увеличить количество мероприятий, которые использовали нашу платформу, а общее количество юзеров перевалило за 15,000 (при рынке хакатонов в России в 70-100к участников в год).
Что же такое Customer Driven Development?
Если просто - это построение процесса разработки программного обеспечения вокруг потребителя. В России с 2000 года компании используют слово “клиентоориентированный“, но зачастую все сводится к банальному сбору обратной связи для создания бэклога на 2030 год или “кастомизированной КаПэшечки”, куда включают все дополнительные запросы клиента по прайсу х3 от рыночного. Чтобы CDD сработал, все должно быть несколько глубже.
«Чтобы быть настоящей клиентоориентированной командой или компанией, вы должны быть готовы отложить свое эго в сторону.»
David Cancel, CEO at Drift
В чём же причина сложившейся ситуации? Ответ - метрики, которые применяются к командам разработки. Обычно в компаниях задают следующие вопросы:
- Команда выпустила релиз?
- Команда выпустила его вовремя?
- Есть ли там фичи, которые они обещали?
Возьмите минуту на размышление, очистите разум и постарайтесь подумать: в чем фундаментальная проблема этих метрик?
…
Ответ простой: конечному клиенту все равно – выпустили ли вы релиз вовремя или что в нём есть те фичи, которые вы решили, что они должны там быть. Клиенту нужен продукт под его запрос.
Чтобы решить эту проблему, команды должны понять что и почему действительно важно для пользователя. Когда вы пользуетесь Google, вам нравится получать нужный результат быстро и вам абсолютно все равно, как это работает: навороченный алгоритм или 30000 индусов проиндексировали все страницы вручную.
Это легко спроектировать на собственный опыт. Например, нам нужно было сделать качественную систему рассылок писем: подтверждение регистрации, различные уведомления и напоминания от организаторов. Мы конечно же могли бы сделать все сами, но пользователям нужно это уже вчера, а нам бы потребовалось на это не меньше месяца разработки. Решение - интеграция с MailerLite и GetResponse: неделя работы с нашей стороны, бесплатный первый месяц для клиента и максимально удобные сервисы, заточенные на качественный пользовательский опыт.
Но это лишь один из примеров, который показывает как быть эффективными и клиентоориентированными. Если говорить о более комплексных подходах, посмотрим на примеры западных компаний.
David Cancel, CEO at Drift выстроил процесс разработки в своей компании на основе следующих принципов.
- Измерять правильные вещи, и не измерять неправильные. Уже говорили об этом ранее, но важно не забывать про адекватность в управлении нагрузкой команды, приоритезации фич и управлении техническим долгом.
- Общаться со своими внутренними клиентами (продажи и маркетинг) и иметь возможность наблюдать за конечными пользователями. Здесь важно, чтобы у разработчиков были правильные стимулы: они видят как конечные пользователи используют продукт, вживую получают обратную связь, это вдохновляет их качественно делать нужные вещи и предлагать как технически оптимизировать продукт.
- Постоянный процесс обучения. “Для того, чтобы учиться и прогрессировать, вам нужно уметь выключать эго хотя бы на пять минут.” Соответственно вместо того, чтобы потратить время “на игры с интересными технологиями”, разработчик выберет оптимальное решение.
В качестве другого примера, рассмотрим историю Nicole Wright, UX Researcher at HoneyBook.
В их компании они создали Customer-Driven Testing and Development (CDTD) – процесс по обеспечению влияния клиентов и пользователей на цикл разработки ПО (по сути на QA процесс обеспечения качества программного продукта + проектирование и управление продуктом).
Главная их фишка - это “Запрос на изменение” (Change Request), ошибка на продакшене, которая скатывается прямиком до R&D. Это позволяет понять проблемы в подходе к тестированию. Далее команда передает QA запрос для улучшения тестов, что позволяет уменьшить вероятность появления данного CR в будущем.
Если говорить о принципах разработки, которые они заложили у себя в проекте:
- Стимулировать пользователей делиться своим продакшн-окружением. В первую очередь здесь идет речь про реальные данные клиентов. Их можно анонимизировать и использовать для проверки новой версии на них до выката на продакшн - максимально актуально для B2B. Бонусом вы получаете возможность увидеть, как ваш продукт выглядит “в живую”.
- Постоянно проводить опросы о том, как используется продукт. Все максимально просто - опросы, системы аналитики и т.д. - собираем информацию о максимально важных фичах.
- Вовлекать клиентов в разработку, использовать их как бета-тестеров и первых пользователей. Отличная возможность оптимизировать весь процесс выхода релиза: ускорить и удешевить + установить лучший контакт с клиентом.
- Нужно нормально организовать пространство для агрегации данных. Найти решение, которое позволит всей команде удобно взаимодействовать с данными клиентов, при этом не страшно переделывать существующий процесс под качественное решение.
Заканчивая историю про CDD, хочется упомянуть Customer Journey Map. Про него написано множество статей и снято часы вебинаров. Соответственно будем максимально краткими: Customer Journey Map позволяет отслеживать удовлетворение пользователя на всем пути взаимодействия:
- какая функция используется
- положительные / негативные реакции и факторы
- выводы
Это позволяет переложить весь продукт на понятную систему измерений и понимать, как сделать лучше клиенту - завязать процесс разработки вокруг него.
А по итогу то, что у вас вышло?
Вернемся к нашей платформе: какие инструменты мы имплементировали и о каких пока только мечтаем:
- нормальные метрики
- постоянные интервью с клиентами с участием команды разработки
- использование клиентов на стадии определения фичей, как бета-тестеров и первых пользователей
- открытая обратная связь от аудитории клиентов
- CJM в голове
- частичное использование продакшн-окружения клиентов
<-------------------------------- мы находимся вот тут --------------------------->
- анкетирование аудитории клиентов
- больше аналитики по использованию решения
- нормальный CJM
- большая утилизация продакшн-окружений
Данный подход в связке с “хакерскими подходами” по упрощению разработки позволяют максимально быстро развивать продукт. Из последнего мы поняли, на клиентских данных, что наша система поиска сокомандников не работает на больших мероприятиях, а на маленьких просто пользователи сдерживают эти эмоции. Соответственно, мы решили срочно её переделать и на этой неделе запускается хакатон, где мы сразу же протестируем новый UX на пользователе.
P.S
Когда я обсуждал эту тему с одним из знакомых, он справедливо ответил, что если делать только то, что хочет пользователь - инновации не случится. Генри Форд писал, что его клиентам нужна была быстрая лошадь, а не механическая повозка. Если посмотреть на наш кейс - мы также не спрашивали у организаторов, какая система им нужна, мы предложили им продукт, который им понравился и решил их боли, но чтобы они получали удовольствие от его использования - его нужно допиливать совместно с самими пользователями, а Customer Driven Development вам в этом поможет.
Подробнее про CDD можно почитать в следующих материалах:
- Customer-Driven Development — An Interview with David Cancel, CEO at Drift
- How HoneyBook Made Research Available to Everyone — and Doubleddown on their Mission to be a Customer-Centric Company
- Customer-Driven Development — A case study with Luke Chircop, Product Lead at Shedd.
- Customer-driven development: 3 ways to make customers part of R&D
- Customer-Driven Development – Driving Growth Through Communication
Они также использовались для написания теоретической части данной статьи.