Почему работа без ТЗ — это способ сделать то, что действительно нужно заказчику

Принцип «Без ТЗ — результат ХЗ» — чаще всего ерунда.

Привет! С вами Артём Харитонов — основатель GORA Studio. Мы разрабатываем мобильные сервисы и приложения с использованием компьютерного зрения, нейросетей и дополненной реальности (AR) и при этом чаще всего работаем без классического ТЗ. В статье расскажу, как такой подход помогает сэкономить время, деньги и получить продукт, который не устарел еще во время разработки.

Главная сложность — невозможность предусмотреть в классическом ТЗ все мелочи. Именно они делают мобильные приложения и успешные веб-сервисы удобными и заставляют пользователей возвращаться раз за разом в полюбившееся приложение.

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

Приложение выходит на рынок позже. Обычно для создания этого масштабного талмуда привлекают аналитика.Чтобы все подробно описать для небольшого проекта, который можно сделать за 3–6 месяцев, аналитику нужно от 1 до 3 месяцев и ≈50–150 тысяч рублей (это без дизайна!). За это время можно было бы сделать треть или даже половину проекта, потратить деньги на саму разработку, подогрев рынка и запуститься на несколько месяцев раньше.

Приложение получается не таким, как его задумал заказчик. Понятия и формулировки в суперподробном ТЗ часто общие и неточные, а важные мелочи и вовсе забывают упомянуть. Разработчики могут читать и реализовывать формулировки из ТЗ по-разному, возникает двусмысленность, а потом вместо запуска начинаются бесконечные круги ада доработок.

Чтобы сократить количество переделок и доработок, вместо ТЗ мы разрабатываем функциональную карту: это визуализация дизайн-экранов в Figma, где сразу понятно, что и как будет устроено в приложении, плюс пометки для разработчиков.

Вот как мы создаем экраны-прототипы:

• Встречаемся с клиентом в офлайне, в Zoom или Skype. Он описывает своими словами, какое приложение нужно и для чего, что в нем должны делать пользователи.
• Разрабатываем прототипы, обычно 3-5 экранов в Figma. Первые результаты сразу показывают, насколько хорошо наша команда поняла заказчика, нравится ли заказчику общая стилистика. Клиент видит визуализацию своих хотелок сразу, а не через три месяца после начала работы.
• Делаем интерактивный прототип. Показываем заказчику, как будут прокручиваться экраны, как будут работать переходы. При необходимости сразу можно показать, какую форму или кнопку передвинуть.
• Оперативно вносим изменения. Дописываем функциональные особенности рядом с экранами. Поменять расположение иконок в прототипе — пара минут, а если бы заказчик дожидался запуска какого-нибудь MVP, уже пришлось бы переписывать код.

Сравните сами, что понятнее: ТЗ на 50 страниц текстом или дизайн-экраны, которые можно понажимать.

Подробное и хорошее описание того, что вы хотите получить, действительно может нам помочь. Если можете описать это сразу — делайте. Но не стоит тратить время и силы, чтобы прописать в ТЗ, как будет выглядеть датапикер на iOS или Android или что после ввода четвертой цифры из СМС-кода нужно автоматически проверять ввод и успешно авторизовывать, не прося нажать «Далее».

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

Для будущего проекта лучше, если владелец продукта (основатель) будет участвовать в жизни проекта постоянно. Например, каждую неделю-две смотреть у себя на телефоне или в браузере, что уже готово и как оно работает. В случае чего, можно сразу бить тревогу, если что-то не так или появилась новая идея. Часто бывает, что нарисовано красиво, а когда начинаешь нажимать — оказывается неудобно.

Конечно, в ТЗ тоже делят большие проекты на этапы. Только непонятно, зачем максимально подробно прописывать все 10 этапов и жестко себя ограничивать. Если на втором или третьем этапе концепция может поменяться (привет, пивот) и всю документацию придется переписывать по новой.

Запуск не откладывается. За время написания ТЗ можно упустить удачное время для вывода проекта на рынок. Лучше быстро проанализировать требования, сделать функциональную карту с примерами экранов и сразу стартовать. Мы просто утверждаем все нужные функции, экраны и количество подключаемых сервисов, подписываем NDA и сразу начинаем разрабатывать первую версию.

В итоге небольшие проекты стартуют за 2–4 месяца, а средние — за 5–8 месяцев. Да-да, без всяких переписываний и осмысливаний ТЗ, миллиарда уточнений и десятков совещаний на протяжении долгих месяцев.

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

Проще контролировать расходы и понимать, на что потрачены деньги. Первое, что отталкивает бизнес от работы без ТЗ, — это отсутствие фиксированной цены. Люди не понимают, как можно работать без этого. В классическом подходе все вроде просто: вот задача, вот цена. Например, за условные 10 тысяч долларов вам разработают готовое приложение. Но! Это будет приложение, которое нельзя выпускать и заливать в сторы. Его сразу нужно дорабатывать под новые требования, потому что в ТЗ что-то не учли и продумали не все или появились новые бизнес-требования.

В случае с работой без ТЗ заказчик оплачивает работу по часам (Time & Material) и контролирует отработанные задачи на каждом этапе. Из-за недобросовестных студий и неумения заказчиков оценивать затраты в часах в нашей стране не очень любят работать с платой за часы.

На самом деле так удобнее не только студии, но и заказчику тоже. Например, ему не нужно замораживать сразу всю сумму. Смотрите сами:

• Когда мы перед разработкой согласовываем список функций, уже можно предварительно оценить проект по часам, а значит, посчитать его стоимость.
• Заказчик оплачивает каждый этап, а не всю разработку сразу, но при этом уже на первом этапе он получает готовый рабочий продукт.

В результате заказчик контролирует бюджет на каждом этапе разработки. Сразу понятно:

• Сколько нужно потратить на запуск новой версии и когда она будет запущена.
• Во сколько обойдется разработка конкретной фичи и стоит ли ее добавлять вообще.

Работа не застопорится внезапно из-за того, что вдруг потребуются серьезные незапланированные вливания бюджета. Мы в студии используем трекер задач Jira, оттуда заказчик может получить отчеты о выполненных задачах и отработанных часах на любом этапе в понятном виде. Хотя бывают случаи, когда мы комбинируем две модели: выставляем фикс за основной функционал, а доработки добиваем через T&M.

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

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

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

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

Разработчик видит, что в документе написана ерунда, и начинает страдать. Он не может сделать шаг влево или вправо, чтобы не нарушить договор. И неважно, что это все написали еще год назад, а за это время многие интерфейсы и решения устарели. Разработчик вынужден сделать плохо.

⟶

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

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

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

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

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

Я совсем не против, если заказчик придет с готовым документом-заданием, где коротко и ясно описан функционал, что ему нужно и что он хочет от пользователя. Это даже хорошо, ведь получается, что задачу уже обсудили внутри компании, перенесли ее на бумагу и не отказались от идеи. Значит, они нацелены на результат, и это отлично!

А вы разрабатывали или заказывали без ТЗ? Поделитесь, что из этого получилось :)