Различия между MVP и временной системой
Два проекта могут быть запущены с одинаковым количеством экранов, но один из них станет основой для роста, а другой — обузой, которую придется демонтировать. Разница не в объеме, а в характере компромиссов.
Практическое правило: в первой фазе сокращается бизнес-ширина, а не архитектурная глубина. Допустимо сократить количество процессов, подразделений и типов входящих клиентов. Недопустимо сокращать ключевую модель данных, модель разрешений и определение источника истины — это закладывается один раз правильно, даже если на начальном этапе используется всего пятьдесят пользователей.
Тот, кто сокращает глубину вместо ширины, получает систему, которая работает квартал, а затем перестраивается. Широкий контекст этапов проекта представлен в Руководстве по внедрению Salesforce.
Три определения, которые часто путают
| Термин | Что это на практике | Когда это уместно | Основной риск |
|---|---|---|---|
| Proof of Concept (PoC) | Доказательство технической реализуемости одного компонента | При наличии серьезных сомнений в возможности реализации | Склонны продвигать его в производство |
| Pilot (Пилот) | Полное развертывание для ограниченной группы | Когда решение известно, а вопрос в его освоении | Группа недостаточно репрезентативна |
| MVP | Первая рабочая версия, создающая реальную ценность | Когда хочется учиться на реальном использовании | Становится постоянным без принятия решения |
Выбор между этими тремя понятиями не является семантическим. PoC можно отбросить, MVP — нет. Поэтому MVP должен создаваться только по производственным стандартам.
Какие решения нельзя откладывать
Существует группа решений, стоимость изменения которых возрастает на порядок после появления данных в рабочей среде. Эти решения включаются в первую фазу, даже если они охватывают лишь малую часть общей картины:
- Объект, который содержит бизнес-процесс, и его отношение к ключевым сущностям.
- Уникальный ключ, который идентифицирует клиента во внешних системах.
- Видимость по умолчанию для каждого основного объекта.
- Структура владения записью — кто является владельцем и что происходит, когда сотрудник уходит.
- Определение источника истины для каждой сущности, синхронизированной с другой системой.
Напротив, решения, которые можно и нужно отложить: разработка расширенных отчетов, удобные автоматизации, интеграция второстепенных каналов, локализация подразделений не первой очереди, а также интеграции, не требующие принятия решений в реальном времени.
Как выбрать процесс для первой фазы
Выбирается не самый простой и не самый проблемный процесс. Выбирается процесс, который одновременно отвечает трем условиям: у него есть один доступный владелец процесса, он дает результат, который виден руководству, и он представляет центральную модель данных. Процесс, отвечающий двум из трех условий, все еще возможен; процесс, отвечающий только одному, приведет к первой фазе, которая ничего не даст.
Дополнительный фактор — объем: процесс, который происходит десять раз в месяц, не сгенерирует достаточного использования, чтобы извлечь из него уроки в течение квартала.
Критерий выхода — что указывает на успешность фазы
MVP без критерия выхода становится постоянным. Критерий должен быть измеримым, кратким и заранее известным. Пример структуры:
- X процентов процессов выбранного типа выполняются в системе, а не за ее пределами.
- Нет открытой блокирующей ошибки дольше определенного количества дней.
- Данные, созданные за период, соответствуют заранее определенному порогу качества.
- Владелец процесса подтверждает в письменной форме, что процесс выполняется без постоянных обходных путей.
Обратите внимание, что ни один из этих пунктов не означает "система запущена". Эта дата является началом измерения, а не его концом.
Стоимость отсрочки — инструмент для разрешения споров о масштабе
Когда обсуждается, войдет ли функция в первую фазу, полезный вопрос не в том, сколько стоит ее построить сейчас, а в том, сколько стоит ее построить потом. Следующая таблица служит рабочим инструментом на встрече по определению объема:
| Тип функционала | Стоимость разработки в первой фазе | Стоимость разработки во второй фазе | Вывод |
|---|---|---|---|
| Изменение в структуре ключевого объекта | Низкая | Очень высокая — включает миграцию | Включается в первую фазу |
| Новая модель разрешений | Средняя | Высокая — раскрытие уже произошло | Включается в первую фазу |
| Управленческий отчет | Низкая | Низкая | Откладывается |
| Автоматизация оповещений | Низкая | Низкая | Откладывается |
| Интеграция, необходимая для принятия решений в реальном времени | Высокая | Высокая + укоренившийся обходной путь | Включается, если процесс зависит от нее |
| Интеграция только для отчетности | Средняя | Средняя | Откладывается |
Пример для иллюстрации: Международная логистическая компания
Сценарий гипотетический и предназначен для иллюстрации. Логистическая компания с деятельностью в трех странах хотела запустить MVP за одиннадцать недель. Первое предложение состояло в том, чтобы включить все три страны, но только этап предложения, без этапа заказа.
Команда изменила подход: одна страна, но полный процесс от предложения до утвержденного заказа, включая интеграцию, которая подтягивает тарифы. Причина была проста — прерывание процесса посередине обязывало бы пользователей продолжать работу в старой системе на этапе заказа, то есть вводить данные дважды. Вместо того чтобы выяснить, помогает ли система, компания узнала бы, что система затрудняет работу.
Общий объем работ в неделях остался примерно таким же. Изменилось то, что после первой фазы у компании был полный работающий процесс, а не половина процесса в трех странах.
Признаки того, что MVP превратился во временную систему
- Существует постоянный ручной процесс, предназначенный "для моста до следующей фазы", который работает уже два месяца.
- Согласовано поле, используемое для двух разных целей, потому что не было времени его разделить.
- Существует группа пользователей, работающих параллельно в двух системах.
- Нет даты решения для следующей фазы, только лист ожидания.
Эти паттерны подробно описаны наряду с другими ошибками в Руководстве по распространенным ошибкам внедрения CRM.
Интеграция с общим графиком
Определение MVP напрямую влияет на продолжительность проекта, и иногда в направлении, противоположном ожидаемому: слишком узкая первая фаза удлиняет общий проект, потому что каждая фаза несет фиксированные затраты на тестирование, обучение и запуск. Как это перевести в детальное реалистичное планирование, описано в Руководстве по продолжительности проекта Salesforce, а в случае замены существующей системы также в Руководстве по переходу на Salesforce.
Следующий шаг
Напишите одним предложением, какой процесс является основным для первой фазы, кто его владелец, и какой критерий через квартал укажет на его успех. Если одно из трех предложений пока невозможно написать — это отправная точка, а не список функций.