Нельзя назвать одну обоснованную цену веб-приложения для бизнеса, не определив его объем. Простой внутренний реестр для нескольких сотрудников и система, которая обслуживает заказы, расчеты, интеграции и работу нескольких отделов, являются разными проектами. В них может быть похожее количество экранов, но совершенно разное число правил, исключений и обязанностей, связанных с данными.
В Domin Software мы оцениваем каждый проект индивидуально. Сначала выясняем, какую проблему должно решить приложение, кто будет им пользоваться, откуда поступят данные и что должно работать на первом этапе. Если информации недостаточно, предлагаем отдельный платный этап анализа, а не угадываем цену по короткому сообщению.
Отсутствие прайс-листа не означает, что стоимость определяется случайно. Ниже мы объясняем, что чаще всего влияет на объем работ и какие сведения нужны для ответственной оценки.
Процесс важнее количества экранов
Экран входа, форма и список записей могут выглядеть просто. Однако значительная часть работы часто скрыта в правилах, которых не видно на первом макете.
Например, форма заказа может проверять наличие товара, учитывать индивидуальные цены клиентов, запрашивать согласование скидки, резервировать товар, отправлять уведомления и передавать данные в бухгалтерию. Каждый из этих шагов нужно описать, реализовать и проверить, в том числе в нестандартных ситуациях.
Поэтому до оценки мы уточняем реальный рабочий процесс:
- Что запускает процесс и каким должен быть его итоговый результат?
- Кто выполняет каждое действие и принимает решения?
- Где создаются данные и кто может их изменять?
- Какие исключения, исправления и возвраты к предыдущим шагам встречаются на практике?
- С какими программами должно взаимодействовать приложение?
- По каким критериям заказчик и исполнитель поймут, что этап выполнен правильно?
Чем точнее ответы, тем меньше предположений приходится включать в оценку.
Что сильнее всего влияет на стоимость веб-приложения?
Объем первого этапа
Важно, должна ли первая версия решить одну четко описанную проблему или сразу заменить несколько инструментов во всей компании. Меньший этап не должен быть временной версией на выброс. Он должен давать конкретный результат, который можно принять и использовать.
Когда все идеи включают в один объем, растет не только список функций. Сложнее определить зависимости, порядок работ и момент, когда систему можно безопасно запустить.
Роли и права доступа
Для одного человека, работающего со своими записями, нужны более простые правила, чем для системы, которой пользуются администратор, отдел продаж, бухгалтерия, партнеры и внешние клиенты. Необходимо определить, кто видит конкретную информацию, кто может ее менять, кто утверждает решения и как сохраняется история важных изменений.
Права доступа особенно важны там, где ошибка может повлиять на заказ, оплату, расчет или данные клиента.
Данные и их перенос
Новое приложение редко начинает работу с пустой базой. Информация может находиться в таблицах, старой системе, сообщениях или файлах, которые готовят разные сотрудники. До импорта нужно проверить форматы, полноту, повторы и правила объединения записей.
Перенести файл обычно проще, чем определить, какие значения актуальны и что делать с пропусками. Поэтому качество исходных данных может значительно изменить объем миграции.
Интеграции с другими системами
Интеграция может раз в день получать одно значение или в обоих направлениях передавать заказы, статусы и платежи. Объем зависит, в частности, от документации API, способа авторизации, ограничений, обработки ошибок и наличия тестовой среды.
Нужно также определить, что должно делать приложение, если внешний сервис временно недоступен или возвращает неполные данные.
Подробные факторы стоимости описаны в статье Сколько стоит интеграция систем и API?.
Правила, исключения и автоматизация
Автоматизация полезна, когда известны условия ее работы и понятно, в каких случаях решение по-прежнему должен принимать человек. Простое уведомление и автоматический расчет комиссий, выбор маршрута согласования или синхронизация нескольких статусов являются разными задачами.
Исключения нельзя оставлять на конец проекта. Если они возникают регулярно, их нужно включить в описание процесса и тесты с самого начала.
Безопасность и возможность проверить изменения
У внутреннего вспомогательного реестра и системы с данными клиентов, расчетами или информацией для нескольких компаний будут разные требования. Имеют значение правила входа, права доступа, журнал важных операций, резервные копии, обновления и порядок реакции на ошибки.
Безопасность нельзя гарантировать одной функцией. Меры должны соответствовать данным, пользователям и возможным последствиям проблемы.
Тестирование и критерии приемки
Функция не становится готовой только потому, что работает в самом простом примере. Может потребоваться проверка правильных и ошибочных данных, недоступных интеграций, разных прав доступа и фоновых процессов.
Оценка становится точнее, когда до начала работ обе стороны знают условия приемки этапа. Без таких критериев заказчик и исполнитель могут по-разному понимать слово «готово».
Запуск и дальнейшее сопровождение
Проект может включать только разработку приложения или также настройку среды, миграцию, запуск, мониторинг, резервные копии, обновления и дальнейшее развитие. Это отдельные обязанности, которые следует указать в предложении.
Кроме того, могут возникнуть платежи внешним поставщикам, например за хостинг, отправку сообщений, карты, прием платежей или другие API. Эти расходы не включаются автоматически в стоимость разработки.
Отдельно мы объясняем, что влияет на стоимость сопровождения веб-приложения после запуска.
Если вы рассматриваете систему для работы с клиентами и продажами, узнайте также, из чего складывается стоимость CRM на заказ.
Три примера разного уровня сложности
Следующие примеры помогают сравнить объемы. Это не готовые пакеты, не прайс-лист и не обещание срока.
| Пример ситуации | Что может войти в первый этап | Что может значительно увеличить объем |
|---|---|---|
| Внутренний реестр | формы, список записей, поиск, базовый экспорт и одна или две роли | импорт старых данных, расширенные права, история изменений и нестандартные правила проверки |
| Модуль рабочего процесса | несколько этапов работы, статусы, уведомления, разные роли и базовая отчетность | многочисленные исключения, автоматические решения, расчеты, расширенные отчеты и несколько отделов |
| Система с интеграциями | обмен данными с другими сервисами, миграция, заказы или расчеты и несколько ролей | низкое качество данных, отсутствие документации API, требования безопасности, внешние зависимости и сложные тесты |
Две компании могут описать похожие функции и получить разные оценки. Разница становится видна только после проверки процесса, исключений, данных и ответственности пользователей.
Чего часто не хватает в первом запросе?
Первое сообщение обычно посвящено функциям, которые видит пользователь. До оценки полезно уточнить и сведения, связанные с работой за пределами экрана:
- Нужно ли импортировать данные и кто подтвердит их правильность?
- Есть ли у внешней системы документация и тестовый доступ?
- Кто будет управлять учетными записями и правами?
- Какие сообщения, файлы или документы должны создаваться автоматически?
- Что происходит, если данных не хватает или процесс идет необычным путем?
- Кто принимает этап и на основании каких критериев?
- Кто отвечает за сервер, домен, резервные копии и внешние сервисы?
- Какие расходы на лицензии и подписки могут возникнуть помимо работы исполнителя?
Необязательно заранее знать все ответы. Важно отделить подтвержденные сведения от предположений и вопросов, которые еще нужно проверить.
Когда оценку можно подготовить без отдельного анализа?
Развернутый анализ нужен не всегда. Иногда проблема четко ограничена, в процессе мало исключений, данные известны, а для интеграций есть рабочая документация. Объем, результат и критерии приемки все равно потребуются, но их можно согласовать в рамках более короткой подготовки предложения.
Бесплатная предварительная беседа с Domin Software может длиться до 20 минут. Она нужна, чтобы определить проблему, цель и материалы для дальнейшей оценки. В нее не входят диагностика приложения, проверка кода и готовый отчет.
Если проект затрагивает несколько отделов, содержит много неизвестных, требует миграции или объединяет несколько систем, мы предлагаем сначала бизнес-анализ и определение объема MVP. Это платный самостоятельный этап. Заказчик получает упорядоченные материалы, которые может использовать и с другим исполнителем. Если затем проект реализует Domin Software, уже оплаченная стоимость анализа засчитывается в общую стоимость проекта.
Как Domin Software готовит оценку?
Мы начинаем с проблемы и ожидаемого результата, а не с выбора технологии. Затем определяем процесс, пользователей, данные, интеграции и ограничения. Крупный проект делим на этапы, у каждого из которых есть собственный объем, результат и способ приемки.
В оценке указано, что входит в этап, а что остается за его пределами. Если часть информации еще не подтверждена, мы фиксируем предположения или предлагаем сначала ее проверить. Мы не выдаем предварительную догадку за точную цену всей системы.
Цена, срок и порядок оплаты подтверждаются до начала работ. Обычно оплата производится после завершения согласованного этапа. Для большого объема может быть согласован аванс.
Примеры того, откуда возникает сложность
Система бронирования 44Islands включала разные роли, бронирования, комиссии и последующие этапы развития. Сложность возникала из-за связи процесса продаж с работой администраторов, продавцов, водителей и сопровождающих групп.
В проекте HUB.ITM важной частью была обработка данных из разных программ и их преобразование в формат для импорта в бухгалтерские системы. Объем определяли входные форматы, правила преобразования и проверка корректности.
HUB-2-API объединял импорт товаров, предложения и заказы eBay с API для B2B-клиентов. Один только список экранов не описывает работу, которая выполнялась между системами.
Эти примеры не являются прайс-листом или сравнением стоимости проектов. Они показывают, почему до оценки нужно понять роли, данные и интеграции.
Что подготовить к первому разговору?
Для начала достаточно короткого практичного описания:
- Какую проблему должно решить приложение?
- Как процесс работает сейчас?
- Кто будет пользоваться решением?
- Какие данные нужны и где они сейчас хранятся?
- С какими программами должно взаимодействовать приложение?
- Что обязательно должно войти в первый полезный этап?
- Что можно сделать позже?
- По каким признакам вы поймете, что первый этап работает правильно?
Техническая документация не требуется. Бесплатный инструмент Описание проекта поможет упорядочить эти сведения до обращения к нам. Не вводите в него пароли, ключи API и настоящие данные клиентов или сотрудников.
Часто задаваемые вопросы
Можно ли оценить приложение только по списку функций?
Иногда можно подготовить очень предварительную оценку, но список функций обычно не показывает правила, исключения, данные, интеграции и критерии приемки. Чем больше неизвестных, тем менее надежной будет такая цифра.
Первая беседа и анализ проекта бесплатны?
Предварительная беседа продолжительностью до 20 минут может быть бесплатной. В нее не входят диагностика и отчет. Бизнес-анализ, проверка кода и другие этапы с конкретным результатом оплачиваются и оцениваются индивидуально.
Можно начать с меньшей версии и расширить ее позже?
Да, если меньший этап самостоятельно решает определенную проблему и имеет понятные критерии приемки. Не следует удалять необходимые для безопасной работы элементы только ради снижения начальной стоимости.
Интеграции и перенос данных входят в оценку?
Да, если они включены в согласованный объем. Сначала нужно определить системы, форматы, доступ к API, качество данных и способ проверки миграции.
Обязательно ли после анализа заказывать разработку в Domin Software?
Нет. Материалы анализа можно использовать с другим исполнителем при соблюдении конфиденциальности и без их публичного распространения.
Засчитывается ли стоимость анализа при последующей реализации?
Да, если Domin Software реализует проект, основанный на этом анализе. Тогда уже оплаченная стоимость анализа включается в общую стоимость проекта.
Почему самая низкая начальная оценка не всегда означает самые низкие расходы на проект?
В небольшую сумму могут не входить миграция, исключения, тестирование, запуск или сопровождение. Сравнивайте не только цену, но также объем, предположения, исключенные работы и способ приемки.
Подготовьте информацию для оценки
Если вы только упорядочиваете идею, начните с инструмента Описание проекта. Он поможет собрать сведения о проблеме, процессе, пользователях, данных и приоритетах без технического задания.
Если в процессе много исключений, он затрагивает несколько отделов или требует интеграций и миграции, ознакомьтесь с бизнес-анализом и определением объема MVP. Сначала мы можем определить безопасный первый этап, а затем оценить его реализацию.