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