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

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

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

Что не так с разработкой по ТЗ

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

Даже с хорошим аналитиком практически невозможно предусмотреть все, а еще это занимает очень много времени

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

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

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

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

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

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

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

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

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

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

Реальный кейс. Аналитик тратит время на попытки подробно описать все функции словами и перечислить технологии, которые нужно использовать, разработчик пытается в этом разобраться, а клиент вообще ничего не понимает и ему это неинтересно
В дизайн-экранах мы делаем упор на UX/UI — это 70% успеха для будущей разработки

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

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

Почему заказчику удобнее и выгоднее заказывать приложение без ТЗ

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

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

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

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

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

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

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

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

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

x-staticmediagroup.com

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну в смысле вообще без ТЗ?

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

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

Проще объяснить разработчику общими словами, что нужно сделать. Он выяснит суть и задачи приложения, а после предложит решение. И вы пощупаете первые результаты уже через месяц, а не будете еще год разрабатывать требования к своему проекту
А что вы думаете про классическое ТЗ и почему?
Старо как ICQ
ТЗ на 100 страниц — наше все
Лучше небольшое ТЗ, чем совсем без него
Одних экранов будет достаточно
Показать результаты
Переголосовать
Проголосовать

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

0
166 комментариев
Написать комментарий...
Никита Завьялов

Небольшое ТЗ + прототипы в figma (moqups) - самый хороший вариант. Без ТЗ не все разработчики могут работать. Многим нужно описание того или иного функционала (+ наглядный пример как это будет работать). Не совсем понятно как вы будете формировать смету имея только экраны

Ответить
Развернуть ветку
Александр Орлов

Мне вот интересно, что сейчас чаще всего является бэкэндом приложений, ну там где сервер, база данных, реализация логики и API? И какая это часть в проекте - большая или меньшая? А то ощущение что разработка начинается и заканчивается в figma... 

Ответить
Развернуть ветку
Artem Kharitonov
Автор

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

Ответить
Развернуть ветку
Александр Орлов

Не знаю откуда в России деление на бэкендщиков и фронтэндщиков, в мире есть простое понятие https://en.wikipedia.org/wiki/Software_architect

A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.

Но это по-взрослому,  для нормальных зданий.  При постройке дачных домиков  и туалетов типа  "дырка в полу" это все не нужно )

Ответить
Развернуть ветку
Artem Kharitonov
Автор

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

Ответить
Развернуть ветку
163 комментария
Раскрывать всегда