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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По сути, мы выпускаем MVP. Понятие MVP сейчас так извратили, что нам порой страшно произносить это слово. Стараемся вначале разработать не отдельные детали, а рабочий продукт с минимальным необходимым функционалом — и дальше наращивать <p><a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fx-staticmediagroup.com%2Fblog%2Fwhat-mvp-and-why-do-i-care&postId=210496" rel="nofollow noreferrer noopener" target="_blank">x-staticmediagroup.com</a></p>
По сути, мы выпускаем MVP. Понятие MVP сейчас так извратили, что нам порой страшно произносить это слово. Стараемся вначале разработать не отдельные детали, а рабочий продукт с минимальным необходимым функционалом — и дальше наращивать

x-staticmediagroup.com

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3030
166 комментариев

Разработку "сервисов и приложений" можно сравнить со строительством домов. С помощью подходов автора можно рискнуть построить небольшую типовую дачку. Небоскреб так возводить не стоит. Лучше по старинке, с архитектором и проектом.

36
Ответить

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

3
Ответить

Вся суть в вашем комментарии, а статью читала дольше. Автор объемный материал подготовил, с интересным подходом к делу, хоть и рисковый.

4
Ответить

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

23
Ответить

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

1 раз покажи - вместо 100 раз объясни работает!

3
Ответить

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

2
Ответить

Вы просто не умеете готовить ТЗ. Рисование экранов - это тоже часть ТЗ.

19
Ответить