Главный страх при заказе разработки — вовсе не «сделают плохо». Плохо видно сразу. Страшнее другое: деньги уходят, сроки едут, отчёты приходят бодрые, а что там происходит на самом деле, выясняется в тот момент, когда менять уже поздно и дорого.
Поэтому описывать процесс честнее не через то, что делаем мы, а через то, что видит заказчик и в какой момент.
Шаг 1. Разбираемся
Прежде чем что-то строить, задачу разбирают до состояния, когда её можно оценить. Что должно получиться, из чего состоит, где сложности, чего делать не надо.
На выходе — описание задачи, схема решения и фиксированная смета. И честный ответ на вопрос, стоит ли это вообще делать.
Иногда ответ — нет. Это нормальный результат шага, а не провал. Узнать, что задача решается настройкой готового сервиса, гораздо дешевле здесь, чем через три месяца разработки.
Этот шаг заказывается отдельно и не растворяется в дальнейшей работе: описание задачи и смета остаются у заказчика как самостоятельный результат.
Шаг 2. Собираем
Дальше сборка по уже утверждённой схеме, а не по ходу выяснения.
И на каждом шаге появляется работающая версия. Не отчёт о процентах готовности и не скриншоты, а ссылка, по которой можно зайти и понажимать. Сначала она умеет мало, дальше больше.
Вот и вся разница между проектом, который идёт по плану, и тем, что идёт вразнос. Если каждую неделю есть что запустить, отставание видно на второй неделе, а не на третьем месяце. И видно оно обеим сторонам одновременно.
Шаг 3. Проверяем
Проверка не финальная стадия. Это фоновая работа: идёт всё время и просто нарастает к концу.
Продукт проверяется не на подготовленном показе, а на настоящих данных и живых сценариях. Плюс остаются автоматические проверки, которые продолжают работать и после нас — они поймают поломку при любом следующем изменении, хоть через год и не нашими руками.
Эту часть проще всего сократить ради срока и дороже всего сокращать. Если продукт уже написан кем-то другим и вызывает сомнения, разбор берётся отдельным шагом.
Шаг 4. Развиваем
После запуска продукт не замирает. Появляются реальные пользователи, а с ними то, чего на этапе планирования не было видно вообще.
Дальше формат уже не проектный, а партнёрский — развитие помесячно, аналитика по использованию продукта, новые модули по мере необходимости.
Как это выглядело на практике
Балетная студия в Вене. До нас всё держалось на трёх разных сервисах — отдельно сайт, отдельно расписание и записи, отдельно платежи. Данные между ними не ходили, и владельцы, люди совершенно не технические, каждый день сводили это руками — в том числе по вечерам и в выходные, потому что записи приходят тогда же, когда люди о них вспоминают.
Стало — одна платформа вместо трёх сервисов, которой они управляют сами. Записи, продления, напоминания, листы ожидания, оплаты, договоры — около 90% ежедневной рутины ушло из ручного режима. Помощник отвечает участникам круглосуточно на двух языках, а участников примерно двести.
Объём вышел немаленький — четырнадцать функциональных модулей и больше семисот автоматических проверок. Обычная команда собирала бы такое месяцев восемь-десять. У нас заняло около двух.
Дело тут не в героизме и не в том, что кто-то работал ночами. Решения принимались один раз и заранее, а не переизобретались по ходу, и рутинную часть исполнения вела машина под присмотром человека.
Где тут проходит граница доверия
Из всей схемы придирчивее всего стоит смотреть на первый шаг. Бесплатный разбор, который «входит в стоимость» и после которого на руках ничего не остаётся, — это не разбор, а часть продажи, и оценка из него выходит подогнанной под желание продать, а не под задачу.
Всё остальное можно посмотреть глазами по ходу. Работающая версия либо появляется каждую неделю, либо нет, и спорить тут не о чем.