Без ТЗ результат ХЗ? Не думаю

Всем привет! На связи Антон Фокин 👋 Я CEO студии QTIM, мы с командой занимаемся заказной разработкой. Сайты, приложения, цифровые сервисы, вот это вот всё. Сегодня вместе с Артемом Трушиным, нашим CPO, расскажем, как мы выкинули написание ТЗ из наших процессов и сократили среднее время на разработку проектов в 4 раза.

Причина 1. Его редко используют на 100%

Зачем пишут ТЗ? С ним клиенты чувствуют, что они защищены: есть документ — значит, мы должны получить определенный функционал. На практике от этого функционала остается буквально 30 процентов, в лучшем случае 40. Остальное замещают доработки, новые идеи и неучтенные моменты, которые всплывают в процессе.

Когда речь идет о цифровых продуктах, которые несут ценность сами по себе (например, мобильное приложение для аренды летающих электросамокатов), то ТЗ почти всегда окажется в мусорке. Потому что продукт живой, а значит, и писаться должен итеративно. Если речь о корпоративном сайте ООО «Заптехросгосснаб» — то не вопрос, можно спроектировать его заранее, написать ТЗ и сделать строго по нему.

Причина 2. Никто ничего не знает наверняка

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

Когда ТЗ столкнется с реальностью, оно почти наверняка разобьется всмятку. Потому что рынок, пока вы писали техзадание, поменялся, появились новые технологии или сервисы. Или сервисы, наоборот, сделали ручкой и стали недоступны.

Причина 3. Это пожиратель времени

Написание ТЗ — это долгий процесс, который занимает около 25% от общих сроков проекта. Ну, по крайней мере, в нашей с Артёмом вселенной это так.

Проинтервьюировать заказчика, написать техзадание — это еще только половина приключения. Потом будут согласования и корректировка. Согласования имеют свойства затягиваться: заказчик будет читать, проверять, пытаться всё сразу предусмотреть. Но так не бывает. В большинстве случаев клиент до конца не знает, что хочет получить в итоге (см. причину 2).

Причина 4. Это шоустоппер

Работал с одним клиентом, техзадания писались по два месяца. Проект уже мог идти полным ходом, но без готового техзадания не двигался с места.

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

Причина 5. Пока ты пишешь ТЗ, у клиента все поменялось внутри

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

Причина 6. Клиент не высказал всего, что ему нужно

Техзадание обычно пишет не ЛПР и не product owner. У него на такое нет времени. ТЗ пишет выделенный под это человек. Он собеседует и интервьюирует клиента, а потом пишет все, что услышал. Но самые нужные слова приходят на лестничной клетке (ну или в лифте), так что за рамками ТЗ остается целый запас того, что подразумевалось, но не проговаривалось вслух.

Итого. По моему опыту, при работе с ТЗ теряется 60–70% функционала, изначально описанного в документе. Это происходит из-за новых идей или неучтенных моментов, которые возникают в процессе разработки. Отступать от ТЗ приходится в любом случае. И на ТЗ уходит до четверти всего времени, заложенного на проект. Мы с Артёмом подумали: ну его нафиг.

Все-таки наши рабочие процессы даже без ТЗ далеки от хаоса. Вот так мы с нашим CPO все устроили.

Первый этап: разработка пользовательской истории

Клиент представляет обычную user story в формате «я хочу, чтобы при нажатии этой кнопки открывалась история заказов».

Например, PowerApp — приложение с шарингом зарядных устройств. Из пожеланий в нем должны быть процесс аренды, гибкие тарифы, современные способы оплаты: СБП, Yandex Pay и так далее. С помощью уточняющих вопросов я собрал wireframe в одно пространство — матрицу, из которой уже формируются макеты.

Второй этап: отрисовка макетов

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

Я призываю команду смотреть на задачу с точки зрения пользователя — и описывать, как сайт или приложение должны работать с его стороны. Если выгрузить все задачи из ClickUp, по сути получится ТЗ — но оно не пишется заранее, а формируется в процессе: описывается, редактируется, обсуждается. Получается такая проектная документация.

Кроме того, нет техзадания на весь проект. Оно пишется под каждый спринт, не досконально про каждую кнопку, а про основной функционал, ссылки на макеты и договоренности с клиентом. То есть есть доказательства того, о чем мы договаривались.

Третий этап: frontend и backend-разработка

Разбитые на спринты по две недели. Каждый спринт я отдаю клиенту часть функционала на тест, чтобы сразу свериться по вопросу «ожидание/реальность». При этом работаю в режиме «спринт плюс один». Общее понимание этапности и результата есть, но оно меняется в реальном времени — часто я не знаю, какой модуль будет лучше взять чисто по кодовой базе.

Один из клиентов ближе к концу проекта попросил составить полную документацию, и мы с Артёмом взяли на это целый спринт — примерно 100 часов. И описывали весь проект. Если каждый разработчик после написания своей задачи будет все документировать, будет очень классно и правильно. Но на неё уйдёт четыре недели вместо двух.

Четвертый этап: работа с багами

Фикс багов — отдельный спринт, под который заложен бюджет и время. Я всегда обсуждаю с клиентами процент багов. Чаще всего сразу проговариваем, что баги будут после каждого этапа — но фиксить я их буду в последнем спринте, потому что работаем быстро. У меня есть условные пять месяцев и нет времени доводить каждый этап до совершенства.

Как это работает на практике

Клиент: онлайн-школа.

Задача: выпустить собственную платформу с функционалом iSpring за 5 месяцев.

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

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

Я брал в два спринта задачи, которые мог показать и сдать. Например, берем 30–40% бэкенда, которые никто из клиентов не смотрит. К концу этапа должен быть результат, который они посмотрят, проверят — и увидят, что проект продвигается. Таким образом, клиент каждый месяц получает определенную ценность.

С точки зрения финансирования это выглядит так. Условно, проект стоит 5 миллионов и длится 6 месяцев. В среднем мне платят по 800 тысяч в месяц. Сначала отдают 400, а следующие 400 отдадут, когда убедятся, что я выполнил задачи на этот спринт. Клиент вносит постоплату, и я перехожу к следующему этапу — и так далее.

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

Формат, в котором я работаю, подходит не всем. С одной стороны, получается быстро, без бюрократии. Но у всего есть обратная сторона. Вот к чему нужно готовиться, если вы хотите перевести свою команду на такой подход.

Клиенты не всегда готовы работать без ТЗ

Многие клиенты считают, что ТЗ — это мастхэв, без которого нельзя. Это как когда к вам приходят и просят сделать интернет-магазин на Битриксе. Почему на нём? Потому что клиент не знает, что есть масса других решений, которые подходят ему больше. С техзаданием та же история: обычно у всех есть знакомый разработчик, который советует обязательно составить ТЗ. Придется переубеждать. Хорошо работают частые демонстрации промежуточных результатов — а когда проект готов на 65%, клиент обычно успокаивается и доверяется тебе.

Может быть сложно оценить проект

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

Без ТЗ невозможно дать идеальную оценку, поэтому оцениваю вилкой. Например, клиент говорит, что хочет маркетплейс с такими-то функциями. Я называю примерную стоимость, исходя из свого опыта. Считаем, сколько надо выделить человек в команду: фронта, бэка, дизайнера, менеджера — умножаем на рейт, примерный срок, получаем вилку. В процессе требования уточняются и картина становится более четкой. Обычно, если приходится выходить из бюджета, сообщаю об этом клиенту заранее.

Вам понадобится экспертная автономная команда

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

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

Момент, которому, на мой взгляд, уделяют недостаточно внимания. Хорошие дизайнеры работают с проджектами, продумывают пользовательские сценарии, учитывают все моменты — что и как будет работать. Если дизайнер с менеджером всё продумали, вы быстро согласуете макеты с клиентом и отдадите их в разработку. Продумывайте все вплоть до каждой иконки. Как и в каких случаях она будет себя вести?