Попросите трёх разработчиков оценить «приложение для нашего бизнеса», и вы получите три цифры, которые нельзя сравнить, потому что каждый угадывал что-то своё. Чёткое ТЗ на разработку приложения решает эту проблему. Оно не обязано быть техническим или длинным. Оно должно сказать, кто будет пользоваться программой, что они должны уметь делать, с какими системами она связана и что происходит после запуска. Вот как составить его для веб-приложения, мобильного приложения или обоих сразу.
Что должно охватывать ТЗ на разработку приложения
Считайте ТЗ картой для первого разговора, а не договором. Для большинства проектов хватит двух-пяти страниц, и в нём должно быть:
- Задача. Что сегодня медленно, чревато ошибками или невозможно? «Расчёт занимает два дня, потому что цены лежат в трёх таблицах» полезнее, чем «нам нужно приложение для расчётов».
- Люди. Кто будет им пользоваться, примерно сколько человек и на каких устройствах.
- Цель. Что изменится, когда оно заработает: меньше телефонных звонков, быстрее выставление счетов, заказы больше не теряются между офисом и выездом.
- Ограничения. Реальные сроки, диапазон бюджета и системы, которые нельзя менять.
Называйте результат программным обеспечением на заказ или веб- и мобильными приложениями на заказ, документ остаётся тем же, и он лучшая подготовка к первой встрече с любым разработчиком.
Роли пользователей и важные задачи
В большинстве бизнес-программ есть несколько ролей пользователей, и каждая видит своё: администратор, который управляет настройками, сотрудники офиса, работающие с записями, выездные работники с телефоном и, возможно, клиенты, входящие в портал. Для каждой роли перечислите от пяти до десяти задач, которые она выполняет чаще всего, её собственными словами. «Техник отмечает работу выполненной и добавляет фото» — это задача; «модуль управления заказами» — нет.
Отметьте, кто что не должен видеть. Права доступа гораздо проще продумать в начале, чем прикручивать после запуска.
Обязательные функции, будущие функции и критерии приёмки
Разделите список функций на обязательные функции для первого выпуска и всё остальное. Первый выпуск, часто называемый минимально жизнеспособным продуктом, должен быть наименьшей версией, с которой реальные пользователи смогут работать каждый день. Будущие функции проще расставить по приоритету, когда люди уже пользуются программой и говорят, чего им не хватает.
Для каждой обязательной функции добавьте критерии приёмки: предложение, которое говорит, как вы поймёте, что она работает. «Когда клиент загружает документ, офис видит его в карточке заказа и получает уведомление» можно проверить; «удобная загрузка документов» — нельзя. Критерии приёмки к тому же самый справедливый способ решить, закончена ли функция.
Данные, интеграции систем и устройства
- Существующие данные. Что нужно импортировать из таблиц или старой системы и насколько чистые эти данные.
- Интеграции систем. Бухгалтерия, CRM, платежи, почта, карты или доставка. Назовите программу и направление потока данных; многие из таких соединений выполняются как работа по интеграции API вместе с самим приложением.
- Устройства и условия. Офисные компьютеры, личные телефоны или защищённые корпоративные терминалы; в помещении или на объектах со слабым сигналом. Если людям нужно работать офлайн, скажите об этом, потому что это определяет весь проект.
- Функции телефона. Камера, сканирование штрихкодов, геолокация или push-уведомления указывают на приложение, установленное на устройстве, а не на веб-приложение.
Веб-приложение на заказ, работающее в браузере, часто достаточно для офисных задач, а мобильное приложение на заказ оправдывает себя, когда важны возможности оборудования телефона или работа офлайн. ТЗ не обязано решать это; ему нужно предоставить факты, которые решают.
Аккаунты, права и жизнь после запуска
Вопросы владения проще всего решить до появления кода. В ТЗ должно быть указано, что репозиторий кода, хостинг, домен и аккаунты в магазинах приложений принадлежат вашей компании. Публикация в App Store под названием вашей компании означает регистрацию организации, и Apple требует для проверки юридическое лицо и номер D-U-N-S; см. требования Apple к регистрации. Google Play тоже проверяет аккаунты организаций, поэтому начните с обоих заранее.
Продумайте и годы после запуска. Операционные системы телефонов получают крупное обновление каждый год, а приложениям из магазинов нужны обновления, чтобы не отставать. Мобильным решениям на заказ и веб-приложениям одинаково нужны хостинг, обновления безопасности и ответственный за них человек, поэтому в ТЗ спросите, как будут организованы обновления и поддержка. В наших проектах приложений на заказ документация, доступ к репозиторию кода и план обновлений и хостинга входят в передачу проекта.
Часто задаваемые вопросы: ТЗ на разработку приложения
Насколько подробным должно быть ТЗ?
Достаточно подробным, чтобы два разработчика представляли себе одну и ту же программу. Описывайте задачи и результаты, а не экраны и технологии; хороший разработчик превратит это в проект и спросит о пробелах.
Нужно ли указывать бюджет в ТЗ?
Диапазон помогает. Одну и ту же цель можно достичь экономной первой версией или полнофункциональной, а диапазон позволяет разработчикам предложить подходящий объём, а не гадать.
Нужны ли макеты до обращения к разработчику?
Нет. Грубые наброски или снимки экрана понравившихся инструментов полезны, но проектировать экраны самому не нужно. В наших проектах кликабельные экраны для основных задач появляются после исследования и обсуждаются с теми, кто действительно будет пользоваться программой.
Процесс перерос таблицы? Наша услуга разработки веб- и мобильных приложений на заказ начинается с исследования и кликабельного прототипа, ведётся этапами и завершается передачей документации и доступа к коду для компаний в Лос-Анджелесе, Лонг-Бич и за их пределами. Пришлите нам ваше ТЗ, пусть даже черновое, и расскажите, кто будет пользоваться программой и с какими системами она должна работать.
