Я Алексей, разработчик Appex.Media. К нам нередко приходят клиенты после неудачного опыта: проект с бюджетом на полгода разрабатывается второй год, а первый подрядчик перестал отвечать. Почти всегда причины одни и те же, и их можно предотвратить на старте. Ниже рассказываю, как мы выстраиваем заказную разработку, кто работает над проектом, как считаются сроки и бюджет и что делать, если проект уже начал буксовать у другого подрядчика.
Чего боятся заказчики
Перед первой встречей у заказчика обычно три страха. Сроки сорвутся, и запуск, под который уже запланирована реклама или открытие филиала, сдвинется на полгода. Бюджет вырастет вдвое, потому что «выяснились новые обстоятельства». Готовый продукт окажется неудобным, и сотрудники продолжат работать в таблицах. Каждый из этих страхов основан на реальных историях, и у каждого есть понятная защита: зафиксированные требования, короткие циклы разработки с показом результата и проверка продукта на реальных пользователях до полного запуска.
Почему проекты срываются
- Нет чёткого понимания, что строим. Требования меняются каждую неделю, потому что их никто не зафиксировал, и каждая новая идея съедает время уже сделанной работы.
- Делают сразу всё. Вместо работающей первой версии через два месяца клиент получает недоделанную большую систему через год.
- Клиент не видит промежуточный результат и узнаёт о проблемах слишком поздно, когда исправление стоит дорого.
- Продукт не проверили на пользователях. По данным анализа CB Insights, 42% провалившихся стартапов назвали главной причиной отсутствие потребности рынка в их продукте.
- Весь проект держится на одном разработчике. Он уходит, и вместе с ним уходит понимание, как устроена система.
- Код хранится у подрядчика, и при смене команды заказчик фактически начинает заново.
Как мы ведём проект: 6 этапов
1. Аналитика
Разбираемся в бизнес-процессах, пользователях и цели продукта. Разговариваем с теми, кто будет пользоваться системой каждый день, а не только с руководителем. Результат: описание функций с приоритетами, схема экранов и оценка сроков. Этот этап можно заказать отдельно и получить документ, с которым удобно сравнивать подрядчиков.
2. Прототип и дизайн
Кликабельный прототип показывает, как будет работать продукт, ещё до написания кода. Мы даём его попробовать будущим пользователям и смотрим, где они путаются. Правки на этом этапе стоят в десятки раз дешевле, чем после разработки.
3. Разработка спринтами
Работаем двухнедельными циклами. После каждого спринта вы видите работающие функции на тестовом сервере и можете менять приоритеты. Если идея оказалась хуже, чем казалось, это выясняется через две недели, а не через полгода.
4. Тестирование
Автоматические и ручные тесты на каждом спринте, нагрузочное тестирование перед запуском. Отдельно проверяем сценарии с ошибками: что будет, если пропал интернет, пользователь ввёл неверные данные или две операции пришли одновременно.
5. Запуск
Развёртывание на ваших серверах или в облаке, перенос данных из старых систем и таблиц, обучение сотрудников. Запускаем поэтапно: сначала на одном отделе или филиале, потом на всей компании.
6. Поддержка и развитие
Исправление ошибок, обновления, новые функции по результатам использования, в том числе ИИ-агенты для автоматизации рутины внутри системы. Если вы только выбираете, нужна ли своя система учёта клиентов, читайте статью «CRM под свой бизнес или готовая система».
Кто работает над проектом
Аналитик переводит задачи бизнеса в требования и следит, чтобы разработка не уходила в сторону. Дизайнер проектирует интерфейс, которым удобно пользоваться. Разработчики пишут серверную часть, веб-интерфейс и интеграции. Тестировщик ищет ошибки до того, как их найдут пользователи. Менеджер проекта держит сроки, бюджет и связь с заказчиком. В небольших проектах роли совмещаются, в крупных мы собираем выделенную команду, которая работает только на вас.
Что требуется от заказчика
Даже лучшая команда не сделает систему без участия заказчика. С вашей стороны нужен один ответственный, который знает процесс и может быстро принимать решения: какую функцию сделать первой, как должен выглядеть отчёт, кто из сотрудников протестирует прототип. На демо после каждого спринта нужен час его времени раз в две недели. Когда такого человека нет, вопросы копятся, разработчики ждут ответов, и сроки начинают ползти без всякой вины команды.
Сроки и модели оплаты
Первую рабочую версию небольшой системы обычно реально запустить за 2-3 месяца. Подробно об этом подходе в статье «MVP за 8 недель».
Работаем в двух моделях. Фиксированная цена подходит, когда требования понятны и стабильны: вы заранее знаете сумму, но каждое изменение оформляется отдельно. Оплата по времени подходит для продуктов, которые развиваются по ходу и требуют гибкости: вы платите за фактически потраченные часы и видите отчёт по каждой задаче. Часто мы комбинируем: аналитика и первая версия по фиксированной цене, развитие по времени.
Как мы оцениваем сроки
Каждую функцию из списка разработчики оценивают отдельно, в часах, с учётом тестирования и интеграций. К сумме добавляется запас на неизвестное, потому что в любом проекте находятся детали, о которых никто не подумал заранее. Оценка от подрядчика без разбивки по функциям и без запаса почти гарантированно окажется оптимистичной. Мы показываем заказчику оценку построчно, чтобы он видел, какие функции дороже всего, и мог перенести часть из них во вторую версию.
Как снимаем риски
Исходный код хранится в репозитории заказчика с первого дня. Документация пишется по ходу, а не в конце. Над проектом работает минимум два человека, которые знают код, чтобы уход одного не останавливал работу. Оплата идёт по этапам, и каждый этап заканчивается работающим результатом, который можно проверить.
Как выбрать подрядчика
- Попросите показать похожие проекты и дать контакты клиентов.
- Уточните, кому принадлежит исходный код. Он должен быть вашим.
- Спросите, как часто вы будете видеть результат.
- Узнайте, кто конкретно будет работать над проектом.
- Спросите, что будет, если ключевой разработчик заболеет или уйдёт.
В обсуждениях на Reddit заказчики, пережившие неудачные проекты, чаще всего советуют одно: никогда не платить вперёд за весь проект и требовать доступ к репозиторию с первого дня. Мы работаем именно так.
Если проект уже буксует
Когда проект застрял у другого подрядчика, мы начинаем с аудита: смотрим код, документацию и то, что уже работает. Иногда систему можно доделать, иногда выгоднее сохранить данные и часть кода и пересобрать остальное. Решение принимаем по цифрам: сколько стоит доделка и сколько стоит переделка.
Что вы получите
- Прозрачный план со сроками и приоритетами.
- Работающие функции каждые две недели.
- Исходный код и документацию.
- Команду, которая знает ваш продукт и развивает его после запуска.
Частые вопросы
Можно ли начать без готового ТЗ?
Да. Техническое задание мы составляем вместе на этапе аналитики, и оно становится основой для оценки сроков и бюджета.
Сколько стоит разработка?
Зависит от числа функций, интеграций и требований к нагрузке. После аналитики называем вилку бюджета и показываем, что можно перенести во вторую версию, чтобы уложиться в сумму.
Кто будет поддерживать систему после запуска?
Мы, по договору поддержки, или ваша команда. Документация и код позволяют передать систему другим разработчикам без потерь.
Можно ли усилить нашу команду вашими разработчиками?
Да. Наши специалисты могут работать внутри вашей команды по вашим процессам, если вам не хватает рук на конкретном этапе.
Опишите идею или задачу, и мы проведём бесплатную оценку: объём работ, сроки и вилку бюджета. Обсудить проект разработки ПО.
Источники
- CMO Council. Define the Need Before You Bleed (по данным CB Insights), 2021.
Алексей, разработчик Appex.Media
