всех с наступающими праздниками, само собой!
Частая ситуация на пресейле или уже на старте проекта. Клиент хочет “как у больших”, но бюджет и сроки у него как на пилот.
Пример из жизни. Приходит клиент с новым стартапом - финтех продуктом. Хочет web, iOS, Android, админку, роли, отчёты, интеграции со Stripe, CRM, аналитикой. И всё это за 3-4 месяца желательно. Ну и бюджет у него на это меньше сотки зелени.
Есть два пути.
Первый путь я видел много раз, хотя я всеми силами стараюсь в таком не участвовать, ибо это гигантский гемор потом - пообещать “да, сделаем”, взять небольшой аванс, начать. Я его называю “бери и беги”)
На этом пути обычно через 6-8 недель выясняется, что интеграции заняли вдвое больше, требования плавают, дизайн не готов, а “маленькие правки” в сумме стали отдельным модулем. Дальше начинается торговля за доп бюджет, конфликт, потеря доверия. Иногда проект дотаскивают, но отношения сгорают. В процессе я трачу тонны времени на разбор эскалаций со стороны клиента и участвую в звонках, где ПМа уже закидали фекалиями и теперь моя очередь давать клиенту скидки, плюшки и еще больше обещаний - не самое приятное времяпровождение, я вам скажу.
Второй путь скучнее, труднее, но он рабочий и в долгосроке сэкономит всем нервы, силы и настроение, а также позволит выстроить долгосрочные взаимовыгодные отношение. Это разговор про выбор, а не про “всё или ничего”.
Как я обычно веду такую беседу:
1. Сначала цель релиза 1.0, а не список фич, желательно цель достижимая и не такая амбициозная с которой клиент пришел. Его видение мы не оспариваем и не говорим что оно невозможно, скорее сводим это к “перовму шагу”
- Что должно случиться после запуска: первые N оплат, первые N активных пользователей в день, сокращение ручной работы, проверка гипотезы что это кому то нужно
2. Затем ограничения: Бюджет, срок, объём. Одновременно фиксировать все три пункта это почти всегда путь в никуда. Выбираем один, максимум два, третий становится переменным.
2. Дальше 2-3 варианта на стол:
- Вариант A: укладываемся в бюджет и срок, режем объём
- Вариант B: сохраняем объём, двигаем срок
- Вариант C: сохраняем срок, добавляем бюджет
3. Нарезаем
4. Убираем автоматизацию, которую можно пережить
- Отчёты в первой версии часто можно выгрузить из БД и собрать в Excel
- Ролей можно сделать 1-2 вместо полноценного RBAC
- Какие то операции по сборным платежам можно делать вручную, если платежи уже работают и тд
5. Пересматриваем интеграции и платформы:
- Каждая интеграция это риск и деньги. В MVP оставляем только критичное
- По платформам то же самое. На старт предлагаем 1-2, а не все три
- Один язык, один регион, очень желательно
6. Ищем готовое: дизайн-система, типовые админ-модули, стандартные провайдеры. Кастом только там, где это даёт преимущество с первого дня. Вообще желательно ВСЕГДА с этого начинать любой пресейл и тренировать технарей думать об этом, а не сразу оценивать разработку с нуля
Для кейса выше: мы говорим клиенту: за 3-4 месяца и фикс бюджет мы доводим до запуска один рабочий сценарий. Пользователь заходит, оформляет подписку, получает доступ. Владелец видит базовую картину и может руками решать исключения. Всё остальное в фазу 2, уже с данными после запуска, а не с ожиданиями.
Главный эффект. Клиент не покупает “обещание”. Он покупает короткий, понятный шаг с контролируемым риском.
Дополнительный совет: можно добавить какую то гарантию, например “если вы не получите рабочую систему через 3-4 месяца, то на каждый час сверху мы даем один бесплатно/мы даем месяц бесплатной поддержки после запуска/все баги фиксим бесплатно и тому подобное.
Всем отличных выходных!