Предпроектная аналитика и техническое задание: MVP, интеграции, приложения

Вы описали одну и ту же задачу трём студиям. Оценки разошлись в пять раз. Дело тут не в жадности. Без внятного технического задания каждый исполнитель достраивает задачу сам и закладывает в цену запас на неизвестность.

Дальше идёт знакомый сюжет: смета растёт по ходу проекта, сроки едут. На каждое «а мы думали, это входит» подрядчик отвечает, что в договоре этого не было. Предпроектная аналитика забирает недели на старте, чтобы вы не потеряли месяцы и бюджет на переделках. Чем дальше зашёл проект, тем дороже обходится каждое «мы передумали». Дешевле всего передумывать на бумаге.

Как мы работаем

Начинаем с погружения. Это серия интервью: с вами и с теми, кто будет работать в будущей системе. Спрашиваем не про кнопки, а про задачу бизнеса. Постановка после такого разговора меняется регулярно.

Бывает так. Заказчик приходит за мобильным приложением, а по итогам аналитики оказывается, что нужна интеграция сайта с 1С и личный кабинет.

Дальше описываем пользовательские сценарии. Кто и что делает в системе. Что происходит, когда всё пошло не по плану: оплата не прошла, товара нет на складе, менеджер уволился. Именно такие ветки всплывают посреди разработки и ломают смету. К каждому сценарию пишем критерии приёмки: по каким признакам вы поймёте, что функция готова и работает правильно.

Если в проекте есть интерфейсы, собираем кликабельный прототип главных экранов. На нём дешевле всего проверить, понятна ли логика людям. До того как её начали программировать, а не после.

Для MVP режем объём отдельно и жёстко. Что обязано войти в первую версию, а что честно уходит во вторую очередь. Без этой резки MVP превращается в долгострой.

Что входит в работу

• Интервью с заинтересованными сторонами и разбор текущих процессов.
• Пользовательские сценарии и user stories с критериями приёмки.
• Функциональная спецификация: роли, экраны, логика, справочники, права доступа.
• Требования к интеграциям: с какими системами, какие данные, в какую сторону и что делать с ошибками обмена.
• Кликабельный прототип главных экранов для интерфейсных проектов.
• Границы MVP: что входит в первую версию, что отложено и почему.
• Ориентировочная оценка трудоёмкости по блокам. С ней вы сравниваете предложения подрядчиков.

Что остаётся у вас на руках

Пакет документов, который принадлежит вам, а не подрядчику. Это ваше ТЗ. С ним любая команда даст сопоставимую оценку. Вы сравниваете цены на одно и то же, а не на разные фантазии.

Решите поменять исполнителя посреди проекта? Новая команда войдёт в контекст по спецификации, а не по устным пересказам.

О чём предупреждаем заранее

Спецификация не заморозит требования. Она делает изменения управляемыми. Новые хотелки по ходу проекта нормальны. Но оформляются они как дополнение с отдельной оценкой сроков и денег, а не впихиваются в текущий этап.

Маленьким задачам столько аналитики не нужно. Нужен лендинг или типовой сайт-каталог? Мы так и скажем и предложим короткий формат вместо толстого документа.

Аналитика опирается на то, что рассказали люди. Человек, который держит процесс, не нашёл времени на интервью. Значит, его участок останется белым пятном. Доступ к команде на этапе аналитики важнее, чем кажется.

Опишите задачу в форме ниже: что за продукт задумали, для кого и что должно случиться в бизнесе после запуска. Вернёмся с уточняющими вопросами и предложим формат аналитики под масштаб задачи.