Заказ цифрового продукта начинается не с выбора технологий и не с макетов, а с одной фразы: какая именно проблема бизнеса должна исчезнуть и как вы это заметите. Без такой фразы подрядчик оценивает «систему вообще», а вы потом принимаете работу «на ощупь». Этот урок учит записывать проблему, выбирать метрику и проверять, нужен ли вам софт.
После урока вы сможете
- Сформулировать проблему бизнеса так, чтобы её можно было измерить
- Выбрать метрику успеха и записать её значение «до»
- Честно ответить, нужен ли вам собственный софт или хватит таблицы и готового сервиса
Содержание
Проблема, а не продукт
«Хотим CRM», «нужно приложение», «сделайте как у конкурентов» — это решения, а не проблемы. За ними обычно стоит конкретная потеря, которую удобно описать по схеме:
- Кто страдает: менеджеры, клиенты, бухгалтерия, вы сами.
- В какой ситуации: при приёме заявки, при закрытии месяца, при сверке склада.
- Что теряется: время, деньги, заказы, нервы клиентов, контроль.
- Как часто и в каком объёме: раз в день, на каждой заявке, в конце каждого месяца.
Получается фраза вроде: «Менеджеры при каждой заявке вручную переносят данные из мессенджера в таблицу, из-за чего часть заявок теряется, а отчёт для собственника собирается вручную». Из неё уже видно, что искать: перенос данных, потерянные заявки, отчётность.
Метрика: как вы поймёте, что стало лучше
Метрика — число, которое меняется, когда проблема решена. Для неё нужны четыре вещи:
- Что измеряем. Например, время от заявки до выставленного счёта, число ошибок в накладных, доля заявок без ответа в течение рабочего дня.
- Значение «до». Его нужно замерить сейчас, на реальных данных: на последних 20–30 заявках, за последний месяц. Без базы любое улучшение останется мнением.
- Целевое значение. Не «лучше», а конкретный порог, который имеет смысл для бизнеса. Его нужно обсудить внутри компании, а не угадывать вместе с подрядчиком.
- Кто и когда проверяет. Назовите человека и срок: например, через два месяца после запуска.
Метрик должно быть немного: одна главная и одна-две сопутствующие. Если вы называете восемь показателей, значит, продукт пытаются сделать решением всех проблем сразу — и первая версия получится неподъёмной. Как сузить объём, подробно разобрано в статье «Что входит в MVP».
Нужен ли вообще софт
Честный ответ часто звучит так: пока нет. Прежде чем заказывать разработку, пройдите по ступеням снизу вверх и остановитесь на первой, которая решает проблему.
Изменить процесс
- Когда достаточно
- Проблема в том, что никто не отвечает за этап или правила не записаны
- Что проверить
- Исчезнет ли потеря, если назначить ответственного и описать порядок?
Таблица или форма
- Когда достаточно
- Мало пользователей, простые данные, нет сложных прав
- Что проверить
- Выдерживает ли файл одновременную работу и контроль версий?
Готовый сервис по подписке
- Когда достаточно
- Процесс стандартный: учёт клиентов, задачи, онлайн-запись
- Что проверить
- Закрывает ли он основные сценарии без доработок и умеет ли обмениваться данными с вашими системами?
Настройка и доработка готового
- Когда достаточно
- Основа подходит, нужны несколько своих правил
- Что проверить
- Сколько стоит владение за год с учётом лицензий и доработок?
Собственная разработка
- Когда достаточно
- Процесс — ваше отличие от рынка или готовое не ложится на реальность
- Что проверить
- Есть ли внятная метрика и владелец продукта внутри компании?
Своя разработка оправдана, когда несколько признаков сошлись одновременно: нестандартный процесс, сложные роли и права, обмен данными с несколькими системами, требования к хранению данных. Если из этого списка у вас совпал один пункт, рассмотрите ступень ниже. Если подрядчик на брифе сам предлагает готовое решение вместо заказной разработки, это признак добросовестности, а не слабости; хороший бриф включает такую проверку. О том, когда таблица действительно исчерпала себя, читайте в статье «Когда бизнесу пора уходить от Excel», а о выборе между CRM и ERP — в «CRM или ERP».
Сколько стоит проблема
Чтобы сравнивать бюджет с пользой, оцените цену проблемы за год. Формула простая:
- часы ручной работы в месяц × число сотрудников × стоимость часа × 12;
- плюс потери от ошибок и пропущенных заявок: примерная сумма одного случая × число случаев;
- плюс то, что трудно посчитать, но нельзя забывать: риск остановки процесса, зависимость от одного сотрудника.
Это оценка порядка величины, а не бухгалтерский расчёт. Её цель — получить ориентир, с которым разговор о бюджете перестаёт быть спором о «дорого или дёшево». Если стоимость проблемы заметно меньше стоимости владения новым продуктом (разработка, серверы, лицензии, сопровождение), лучше менять процесс или взять готовое.
Разбор на условном примере: от «нужно приложение» к паспорту
Это иллюстрация, а не реальный клиент: вымышленная служба доставки воды. Числа и формулировки условные — они нужны, чтобы увидеть, как выглядит заполненный паспорт.
Исходная фраза: «Нам нужно мобильное приложение для курьеров». Идём по схеме и лестнице.
Кто страдает
- Как это могло бы выглядеть
- Диспетчер и клиенты
Ситуация
- Как это могло бы выглядеть
- На каждой доставке диспетчер звонит курьеру за статусом; клиент не знает время приезда и звонит в поддержку «где мой заказ»
Что теряется
- Как это могло бы выглядеть
- Время диспетчера, терпение клиентов, часть повторных заказов
Как часто
- Как это могло бы выглядеть
- На каждом заказе, весь рабочий день
Метрика
- Как это могло бы выглядеть
- Доля обращений «где мой заказ» от числа доставок
Значение «до»
- Как это могло бы выглядеть
- Замерить по журналу звонков за прошлый месяц и по числу доставок за тот же месяц
Цель и проверка
- Как это могло бы выглядеть
- Порог назвать после замера; проверяет руководитель клиентской службы через два месяца после запуска
Цена проблемы за год
- Как это могло бы выглядеть
- Часы диспетчера на звонки × ставка × 12 плюс оценка потерянных повторных заказов — порядок величины
Ступень лестницы
- Как это могло бы выглядеть
- Сначала сообщение клиенту со статусом из таблицы заказов; приложение для курьеров — если этого не хватит
Обратите внимание: после заполнения паспорта слово «приложение» перестало быть целью. Появилась проблема с числом, дешёвый первый шаг и условие, при котором дорогой шаг оправдан. Если и после этого понятно, что нужна своя разработка, у вас уже есть половина брифа.
Рабочий лист: паспорт проблемы
Выберите одну проблему вашего бизнеса. Ответы сохраняются в вашем браузере; скачайте файл, когда закончите.
Рабочий лист
Паспорт проблемы
Заполнено 0 из 9
Менеджеры, клиенты, бухгалтерия, вы сами
При приёме заявки, при закрытии месяца, при сверке склада
Время, деньги, заказы, контроль, нервы клиентов
Раз в день, на каждой заявке, в конце каждого месяца
Что именно измеряем: число, которое изменится, когда проблема решена
Чему равна метрика сейчас; на каких данных замерено или кто замерит и когда
Порог, который имеет смысл для бизнеса; кто и когда проверяет результат
Часы × сотрудники × ставка × 12 плюс потери от ошибок и пропущенных заявок; порядок величины
На какой ступени, по вашему мнению, проблема решается, и почему не хватает ступени ниже
Ответы хранятся только в вашем браузере — на нашем сервере их нет. Скачайте файл, чтобы не потерять.
Проверьте паспорт
Паспорт проблемы готов
Выполнено 0 из 7
Отметки хранятся только в вашем браузере.
Проверьте себя
Самопроверка: проблема, метрика, лестница
0 из 5
Ответы хранятся только в вашем браузере.
Что дальше
Паспорт проблемы — основа для следующего шага: превратить её в бриф, который поймёт подрядчик. Перейдите к уроку «Как описать задачу, чтобы вас поняли». Если по результатам лестницы вы увидели, что нужна собственная первая версия, посмотрите, как мы подходим к ней на странице разработки MVP. Это справка, а не приглашение: паспорт пригодится вам в любом случае.