Три разработчика, оценивающие один и тот же бриф в 40,000, 90,000 и 250,000, обычно расходятся не в своих ставках. Они оценивают три разных продукта, потому что бриф допускал три варианта трактовки.
Почему возникает такой разброс
Бриф, в котором сказано, что «пользователи могут загружать документы», оставляет открытыми все дорогостоящие решения. Какого размера? Каких форматов? Предусмотрено ли сканирование на вирусы? Предпросмотр в браузере или только скачивание? Версионирование? Кто может видеть чьи файлы? Срок хранения и удаление?
Разработчик, делающий осторожную оценку, предполагает простой вариант. Тот, кто оценивает с запасом, предполагает сложный вариант и закладывает его стоимость. Оба действуют разумно. Заказчик решает, что более дорогой вариант переоценён, выбирает дешёвый и обнаруживает разницу в процессе разработки — тогда она уже превращается в запрос на изменение.
Пять вещей, которые нужно зафиксировать
- Роли пользователей и доступные каждой из них действия. Не просто «администратор и пользователь», а список действий для каждой роли. Логика разрешений составляет значительную часть работы в большинстве бизнес-приложений, но в списке функций она незаметна.
- Основные рабочие процессы, шаг за шагом. Опишите последовательность, через которую фактически проходит пользователь, включая действия при ошибках — отклонённый платёж, истёкшая сессия, повторная отправка.
- Данные. Что хранится, что является обязательным, какие проверки применяются и как долго данные хранятся. Список полей полезнее описания экранов, поскольку экраны меняются, а данные — нет.
- Внешние зависимости. Платежи, обмен сообщениями, карты, существующие системы, с которыми нужно интегрироваться. Каждая из них требует времени на согласование и обработки сбоев, что необходимо учесть в оценке.
- Критерии приёмки. Как вы определите, что продукт готов. Этот раздел чаще всего пропускают, хотя именно он предотвращает большинство споров.
Объём и производительность, выраженные числами
«Должно работать быстро» и «должно поддерживать много пользователей» невозможно оценить или протестировать. Числа — возможно:
- Ожидаемое количество пользователей в первый год и количество одновременных пользователей в пиковый период.
- Ожидаемое количество записей в крупнейшей таблице через год.
- Допустимое время ответа для самой медленной распространённой операции.
- Размеры файлов и общий объём хранилища.
Эти параметры меняют архитектуру. Приложение, рассчитанное на 200 пользователей, и приложение, рассчитанное на 200,000 пользователей, различаются проектированием базы данных, кэшированием и стоимостью хостинга, а создание второго варианта, когда нужен первый, приводит к лишним расходам, которые можно было бы направить на функции.
Чего не должно быть в спецификации
Две вещи, которые делают спецификации хуже:
Выбор технологий, если для него нет реального ограничения. Указание фреймворка только потому, что его кто-то рекомендовал, лишает разработчика возможности предложить более подходящее решение. Если существует настоящее ограничение — например, существующая система или внутренняя команда, которая должна поддерживать продукт, — укажите ограничение, а не заранее выбранный вывод.
Дизайн на уровне пикселей в функциональной спецификации. Дизайн и функциональность лучше разделять. Спецификация, в которой они смешаны, усложняет проверку обоих аспектов и превращает каждое визуальное предпочтение в функциональное изменение.
Разделы, которые позже становятся причиной споров
Как правило, в следующем порядке:
- Отчётность. «Отчёты» в брифе превращаются в неделю работы на каждый отчёт, когда становятся известны поля, фильтры, группировка и формат экспорта.
- Уведомления. Электронная почта, SMS, push-уведомления и уведомления внутри приложения — это четыре разные реализации с четырьмя разными затратами. Формулировка «система уведомляет пользователя» не уточняет ни одну из них.
- Поиск. Поиск по одному полю прост; поиск по связанным записям с ранжированием — отдельный проект.
- Миграция. Перенос существующих данных почти всегда оказывается сложнее ожидаемого, потому что старые данные содержат несоответствия, которые никто не задокументировал.
Явное указание этих четырёх пунктов в спецификации, даже краткое, переводит их из области предположений в область работ.
Практический подход
Полезная спецификация для небольшого проекта обычно занимает от пяти до пятнадцати страниц: список ролей, описания рабочих процессов, поля данных, список интеграций, нефункциональные показатели, критерии приёмки и отдельный раздел с явным указанием того, что не входит в объём работ.
Последний раздел выполняет больше работы, чем можно предположить по его объёму. Формулировка «отчётность, выходящая за пределы трёх перечисленных экранов, не входит в объём этого этапа» занимает одну строку и устраняет целую категорию последующих разногласий.
Связанные услуги Manboo
- Разработка приложений на Flutter для MVP под iOS и Android.
- Разработка бизнес-программного обеспечения для CRM, систем бронирования, учёта запасов и управления рабочими процессами.
- Разработка административных панелей для операционных дашбордов и управления серверной частью.
- Интеграция AI API, когда ваш продукт готов к интеллектуальному поиску, чату или автоматизации.
- Запросить проверку объёма работ и оценку проекта, когда вы готовы спланировать первую версию.