Какое тз такой и результат

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

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

Почему мы отказались от технического задания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Быстрее в 4 раза: как мы строим процесс теперь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но есть нюансы. Что нужно учесть при отказе от ТЗ?

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

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

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

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

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

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

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

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

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

Нужны сильные думающие дизайнеры

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

А вы всё ещё к̶и̶п̶я̶т̶и̶т̶е̶ пишете ТЗ? Пишите о своих процессах в комментариях или мне в Telegram.

техническое задание
тз
веб-разработка
управление проектами
команда
команда разработки

Без ТЗ результат ХЗ

Ниже Я отвечу на ряд вопросов, которые по моему мнению очевидны, но на практике мы обо всем забываем и совершаем фатальные ошибки.

ТЗ — что это?

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

Для кого ТЗ?

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

Кто должен подготавливать ТЗ?

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

они очень длинные,
адекватного текста — 10%,
по такому ТЗ часто непонятно что надо сделать.

общее описание проекта (название, цель разработки, задачи);
структура проекта;
описание каждого из экранов (состав экрана, прототип (эскизный рисунок экрана),логика функционирования);
пользовательские сценарии (описание алгоритмов действий пользователей в разных ситуациях);
требование к функционалу административной панели;
требования к методами API для взаимодействия с серверной частью;
другие технические требования к проекту (операционная система, поддерживаемые устройства, используемые технологии для реализации частей проекта, описание математических методов (если это требуется) и др.)

Прототипам ДА или НЕТ

Обязательно необходимо делать прототипы.
Все на самом деле просто. Заказчику проще согласовать визуально эскиз экрана чем текст.
Основная ошибка — это не оправдать ожидания Заказчика. Когда он читает текст, то создает себе образ. В 90% случаях образы, которые себе представляют Заказчик и Исполнитель не совпадают. Для синхронизации образов необходимы прототипы.

Эпичная история:
Один из наших Заказчиков в процессе согласования прототипов подумал, что это уже готовый дизайн и утверждал их с такой мыслью. Мы ничего не заподозрили. Но когда мы скинули первые наметки по дизайну, то получили ответ «Зачем нам другой дизайн, нам нравится первый вариант». Мы были сначала в замешательстве и выяснили, что первым вариант дизайна являются прототипы. 🙂 Так и утвердили, но конечно немного все-таки переработав.

Важность ТЗ

делали без ТЗ
делали с ТЗ, но оно не было ещё утверждено
делали с ТЗ, но оно не было подробным
делали ТЗ без прототипов
делали ТЗ с прототипами, но без описания
и т.д.

БЕЗ ВНЯТНОГО ТЗ РЕЗУЛЬТАТ ХЗ — известная и уже избитая фраза.

Изображение БЕЗ ВНЯТНОГО ТЗ РЕЗУЛЬТАТ ХЗ - известная и уже избитая фраза. в соцсети TenChat

Но зато четкая и жизненная.

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

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

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

Важно понять, что ТЗ нужно не только исполнителю, но и самому заказчику, потому что:

ТЗ экономит время и дает возможность сразу поставить все точки над I, определиться с тем, что вам действительно нужно и дать знать о ваших предпочтениях исполнителю.

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

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

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

Что должно содержать техническое задание?

Исходную информацию о проекте (зависит от того, кто дает ТЗ, если сотрудничество долгосрочное, но конечно исполнителю еще и необходимо заполненный заказчиком бриф, чтобы понимать суть проекта и все его детали);
Описание задачи, масштабов задания, всех необходимых деталей (например в ТЗ дизайнеру креативов поясняем размеры, количество, пожелания по оформлению и т.п., копирайтеру — структуру поста, пожелания по содержанию и т.п.)
Договоренность о сроках выполнения. Важный момент и особенно он важен в тех случаях, когда речь идет о первых разовых заказах и до этого сотрудничества с этим заказчиком/исполнителем не было.

Если пост вам полезен, а тема откликается, буду благодарна за сердечко.