Андрей Манюхин

Про ITIL, ITSM и управление в IT с высоты собственного опыта

  • IT4ALL. Мир IT для не-айтишников
  • Обо мне
  • О сайте
  • Контакты

CusDev-мышление как способ заработать

09.01.2020

Кто о чём, а я опять про качество сервиса. Тема Customer Development подробно и детально описана во множестве источников. Я же хочу взглянуть на тему через призму ITSM и DevOps практик, а также попытаться вынести идеи CusDev за рамки IT и культуры стартапов, применив к другим видам и направлениям бизнеса.

Классическая теория

Википедия говорит нам что развитие клиента (англ. Customer development) (сокращенно – custdev) — это тестирование идеи или прототипа будущего продукта на потенциальных потребителях.

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

Развитие продукта в рамках идеологии (по-другому у меня не получается этот термин назвать) CusDev происходит итерационно, через проверку гипотез. Например:

  1. Компании финансового сектора хотели бы иметь биржевую аналитику
  2. Поиск компании финансового сектора
  3. Обсуждение реальных потребностей конкретной компании в биржевой аналитике
  4. Применение результатов 3 на продукте
  5. Повторить с п. 1

То есть цепочка гипотеза – поиск клиента – тестирование гипотезы – применение – новая гипотеза. Очень похоже на общенаучный подход, не находите? Гипотеза – эксперимент – открытие – новая гипотеза.

А что говорит ITIL

В практиках ITIL v3 за развитие клиента, если так можно говорить, отвечает процесс BRM – Business Reletionship Management. Основной целью BRM декларируется установление позитивных отношений с заказчиками. Данный процесс отвечает за идентификацию потребностей существующих и потенциальных заказчиков и обеспечивает (контролирует) внедрение соответствующих услуг для удовлетворения выявленных потребностей.

Очевидна разница между классическим CusDev и BRM связанная с тем что в рамках идеологии CusDev мы сначала выдвигаем гипотезы сами, а потом проверяем их на клиентах, а BRM предполагает что мы сначала спрашиваем клиентов что им надо, а потом пытаемся наилучшим образом удовлетворить их потребности.

Пару слов про DevOps

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

В целом, если пытаться найти аналог CusDev в практиках DevOps, то в той или иной степени ниточки CusDev торчат во всех подходах, которые пропагандирует DevOps, а именно:

  1. Клиент готов платить только за то, что приносит пользу
  2. Готовность к изменениям в любой момент времени
  3. Подстраивать продукт под клиента, а не натягивать клиента на продукт
  4. Максимально оперативная работа с обратной связью от клиентов

Как это должно работать на самом деле

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

Подводя итог написанному выше, а также исходя из собственного опыта общения с представителями бизнеса и «продажи» своих проектов потенциальным инвесторам, могу сделать следующие выводы:

  1. Заказчик будет платить только за те продукты\услуги, которые:
    • Помогают заработать
    • Помогают не потерять (управление рисками)
    • Приносят удовольствие (игры, сфера развлечений)
    • Позволяют предъявить доминантность (премиум-продукты, участие в рейтингах, приобретение популярности, соцсети и т.д.)
    • Покупая продукт, клиент покупает не инструмент, а результат его деятельности (мы не покупаем дрель, мы покупаем дырку в стене)
  2. Клиент будет удовлетворён тогда и только тогда, когда результат как минимум не ниже уровня ожиданий. Важный вывод: управление ожиданиями (маркетинг и PR) — не менее важная часть работы с клиентом, наряду с изучением потребностей.
  3. При общении с клиентом следует уделять наибольшее внимание удовлетворению потребностей клиента, а не характеристикам продукта. То, что с помощью дрели можно будет размешивать тесто или ворочать шампуры над мангалом не гарантирует, что вы продадите её профессиональному строителю.
  4. И, самое важное, любой CusDev, даже в зачаточном состоянии, намного лучше его отсутствия.

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

Поделиться ссылкой:

  • LinkedIn
  • Facebook
  • Telegram
  • по электронной почте
  • Печать
  • Twitter
Posted in: Организация работы, Управление Tagged: CusDev, DevOps, ITIL, Оптимизация

Свяжитесь со мной!

  • Facebook
  • LinkedIn
  • Instagram
  • e-mail

Метки

1С BRM CSF DevOps DIKW ERP idef0 IT4ALL ITIL ITIL 4 ITIL4 ITSM KPI SCRUM SECI Автоматизация Автоматизация бизнес-процессов Базы знаний Жизнь Метрики Микросервисы Миссия Мотивация Обучение Оптимизация Планирование Пользователи Программирование Процесс разработки Работа Разработка ПО Саморазвитие Свой опыт Собеседование Статистика Требования Удовлетворённость Управление знаниями Управление инцидентами Управление разработкой Управление требованиями поиск работы приоритеты процессы управление временем
loading Отмена
Сообщение не было отправлено — проверьте адреса электронной почты!
Проверка по электронной почте не удалась, попробуйте еще раз
К сожалению, ваш блог не может делиться ссылками на записи по электронной почте.