Без ТЗ, быстрая аналитика или глубокая аналитика. Как спасти заказчика веб-разработки от бесполезных трат

Привет! Меня зовут Роман Штых, я директор студии разработки MetaLamp. Я много общаюсь с заказчиками веб-проектов и вижу проблему: они часто не могут описать задачу так, чтобы её можно было сразу оценить. В ответ разработчики предлагают работать без оценки, по часам, либо продают глубокую аналитику — сначала составим ТЗ за счет заказчика, а потом назовем сумму разработки. Это выгодный подход для студии, но он не всегда подходит клиенту.

Работа без ТЗ заказчика не устраивает, потому что непонятно, какой бюджет закладывать. Нужен сильный кредит доверия — вдруг пройдет пару месяцев, придётся платить миллионы, а проекта так и не будет. Глубокая аналитика тоже смущает — тратить сотни тысяч и несколько месяцев на разработку ТЗ, прототипов и оценку стоимости разработки может показаться сомнительной идеей.

Я бы предложил третий вариант, «волшебную таблетку» для таких ситуаций — быстрая аналитика без сильной детализации. Расскажу, как это делаем мы, на примере нескольких заказчиков. В конце поделюсь методичкой: если подход понравится, сможете попробовать провести такое исследование сами, сэкономите деньги и время.

Знакомьтесь, Дима — владелец логистического бизнеса, который он решил перевести в онлайн и расширить, сделать аналог Uber, но в мире грузоперевозок. Дима скачал из интернета шаблон ТЗ, заполнил, получилась какая-то ерунда. Погуглил, понял, что у него совсем нетиповой проект, набирать свой штат разработчиков дорого, долго и сложно, и решил искать подрядчика.

Сначала Дима пришёл в бюро, где ему рассказали про Agile, гибкие методологии и почасовую оплату. Если проще, то предложили работать без подробного ТЗ: он рассказывает идею, ребята начинают разработку, заранее договорившись о стоимости часа программиста, дизайнера и других специалистов.

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

Дима пришёл в другое агентство, озвучил сомнения про гибкие методы работы. Ему сказали: «Не вопрос», и предложили провести глубокий бизнес-анализ проекта. Команда пообещала за 300 000 рублей и три месяца написать подробное ТЗ.

Глубокая аналитика потребует плотного контакта, согласовывать придётся каждую мелочь. Вплоть до поведения приложения при прокрутке экрана: будет ли контент сам погружаться или нужно будет нажимать на номера страниц.

После проработки всех деталей Диме озвучат точную сумму проекта вплоть до копейки, скажут точный срок, когда разработчики пришлют ссылку на работающий сервис. Отдадут ТЗ, с которым Дима сможет обратиться к другим разработчикам — можно сравнить варианты или провести тендер.

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

Наконец, Дима добрался до нас. Мы немного расспросили его о проекте и предложили золотую середину — провести быструю и неглубокую аналитику, как мы её называем, фазу «Дискавери».

Это как глубокая аналитика, только не настолько подробная, долгая и дорогая. Например, в «Дискавери» мы определим ключевые бизнес-процессы, решим сложные вопросы вроде логики получения груза или формирования заказа, и определим список сервисов, с которыми нужно проводить интеграции.

Если увидим сервисы, интеграцию с которыми оценить сложно, долго и дорого, то так и скажем. Например, с Димой получилось так: оценили 80% объёма проекта на точную сумму и срок. Интеграции же с сервисами вроде трекинга автомобилей по GPS предложили делать по часам, с ориентировочным прогнозом по срокам и вилкой цены.

В итоге получается смешанный стиль: за пару недель Дима получил ТЗ, в котором основной объём работы оценён, а для остатка проекта есть вилка по стоимости, которую он спокойно закладывает в свои планы.

Я не хочу говорить, что быстрая аналитика с помощью «Дискавери» — самый классный способ подготовить ТЗ. Хотя, судя по опыту, именно он больше подходит нашим клиентам. Если смотреть объективно, то выбирать модель работы нужно в зависимости от объёма проекта и комфорта заказчика. Если кратко, то так:

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

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

Это сэкономило время и деньги — чтобы точно оценить интеграции, пришлось бы ковырять много банковской документации. Тем более, что такие интеграции — это дополнительные фичи, ведь проект мог стартовать и без них.

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

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

Другой заказчик, Лёша, пришел к нам со срочным запросом — решить проблемы с документами. У него брокерский бизнес, в котором менеджеры принимали и отправляли клиентам кучу разных документов по почте, в нескольких письмах. Проблема — это занимало очень много времени, менеджеры иногда путались в бумагах.

Решение — сделать сервис, который будет принимать документы из разных источников и валидировать. Если что-то не так, то будет отправлять обратно на доработку, если всё нормально, передавать в работу менеджеру. Все действия зафиксированы в облаке, никто не путается и ничего не теряется.

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

Для этого этапа есть хороший инструмент — BPMN. Проще говоря, это большая цепочка бизнес-процессов, в которой явно видно, кто что делает, как делает и кто за что отвечает.

Здесь задача обрастает «мясом» — мы уже понимаем, откуда в будущем проекте будут появляться данные, как их обрабатывает бизнес, насколько длинный будет путь.

Бывает, что человек начинает рассказывать, как он видит решение своей задачи сразу по процессам. Например, хочет, чтобы документы собирались и обрабатывались вот так, чтобы на конкретных этапах были такие-то результаты.

Другой вариант — заказчик может ничего не фантазировать и сказать, что ждёт от нас решения его задач. Так тоже можно — тогда мы проработаем это сами.

Уточняем у заказчика детали и начинаем описывать роли в сервисе — то есть перечень тех, кто будет им пользоваться.

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

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

Для каждой роли мы прописываем возможности — ещё их называют функциональными требованиями. Данные берём из бизнес-процессов, расписываем подробно.

Выясняем у заказчика, что в проекте будет делать каждый пользователь, к каким функциям у него будет доступ, как система будет реагировать на его действия.

Если хотите провести «Дискавери» сами, чаще задавайте себе два вопроса: «А что дальше?» и «Что, если нет?».

Например, водитель в экспедиторском проекте может попасть в личный кабинет. А что дальше? Он увидит оповещение о новом заказе. А что дальше? Может предложить свою цену. А что дальше? Возьмёт заказ. А что, если нет, если откажется брать заказ? Сервис предложит новый? А если он возьмет заказ, но не поедет? И так далее.

Итог этого шага — карточки с ролью и перечислением функциональных требований.

Это внутренний этап «Дискавери», который делает аналитик без привлечения заказчика. Изучая получившиеся функциональные карточки, специалист делает список всех нужных функций проекта: регистрация, авторизация, поиск заказа, отклик на заказ.

Получается большой список так называемых user stories, или разных возможностей, действий.

К работе мы подключаем дизайнера, который в Figma создаёт прототипы — набор основных окон будущего приложения. Это не конечный дизайн, а примеры того, как будет работать проект. Цветовая палитра, расположение и порядок элементов в итоге могут отличаться.

Смысл прототипирования — показать заказчику, как в целом будет работать проект, правильно ли в итоге мы поняли друг друга. И ещё это помогает глубже разобраться в функциях — заказчик по прототипам может уточнить, какие ещё в проекте есть нюансы.

Результат прототипирования — это итоговое согласование проекта.

Мы работаем итерациями: встретились с заказчиком, собрали данные, затем аналитики проработали их, снова встретились, обсудили результат и собрали уточнения, пошли на следующий круг.

Количество итераций и дней на каждый этап зависит от масштабности проекта. Может быть, мы только сбор информации о бизнес-процессах проведем за несколько дней, если это крупный проект типа логистического Uber. Или соберём всю информацию буквально за 3-4 часа, если это условный маркетплейс с какими-то нетипичными требованиями.

Результат фазы «Дискавери» у нас — техническое задание. Документ состоит из нескольких элементов:

В других студиях в результате «Дискавери» заказчику могут передавать и другие документы. Например, MindMap с расписанными процессами. Анализ бизнес-процессов для наглядности мы тоже делаем в таком формате, но я не вижу смысла перегружать заказчика дополнительными сущностями — всё равно эта карта связей ему вряд ли понадобится, ведь все нужные данные есть в ТЗ.

Вместе с ТЗ мы озвучиваем заказчику и коммерческое предложение — во сколько оцениваем проект, сколько по времени будем его делать, какие есть варианты, чтобы сэкономить или сделать проект быстрее.

Быстрая аналитика с помощью «Дискавери» отлично подходит для разработки ТЗ, с ней удобно уточнять требования заказчика и формулировать требования. То же самое можно сделать и с помощью глубокой аналитики. Но между этими двумя подходами есть ключевое отличие.

С помощью глубокой аналитики мы с заказчиком детально прорабатываем ТЗ, уточняем стоимость и сроки — это классно. Но одновременно мы жёстко ограничиваем себя.

Мы оценили каждую деталь, всё, весь бюджет подсчитан. Если заказчик решит добавить в проект какие-то значимые функции во время разработки, придётся либо переоценивать проект, что долго и дорого, либо просто выделять больше денег и всё равно дорабатывать ТЗ. Гибкость проекта теряется.

В «Дискавери» мы можем заранее договориться — вот такой объём точно делаем, а вот эти функции пока непонятно, поэтому тратить время и деньги на их оценку не будем. Договоримся так: по непонятным функциям либо отработаем по часам, либо вообще перенесём в следующую версию проекта. Всё, процесс оценки и ускорился, сэкономили несколько месяцев и сотни тысяч рублей.

«Дискавери» — процесс превращения идеи заказчика в техническое задание и прототипы, по которым разработчики оценят проект и озвучат клиенту сроки и стоимость работ.

За такую аналитику мы берём деньги. Но я готов поделиться одной из версий нашей внутренних методичек, с помощью которой аналитик изучает проекты заказчика и формирует ТЗ — вот ссылка на скачивание у нас на сайте. Попробуйте пройтись по ней самостоятельно, сформулировать описание проекта, категории пользователей и их возможности.

Пишите в комментариях вопросы, если что-то непонятно, я постараюсь помочь.