Эта статья написана для заказчиков разработки, в основном касается IT-продуктов на ранних стадиях. Цель статьи — дать понимание, что писать в ТЗ, как и главное, зачем.
ТЗ — это вообще интересный феномен, все знают о том, что писать надо, но никто не делает. Либо делает халтуру с GPT, то же самое, даже хуже.
Зачем писать ТЗ
поиск более лучшего исполнителя
уменьшение стоимости разработки
уменьшение времени на разработку
уменьшение объёма коммуникации
уменьшение ваших собственных страданий
предотвращение множества ошибок в реализации
Все пункты сводятся к сокращению ресурсов на разработку.
Что такое ТЗ
Сначала разберёмся с терминами, есть несколько вещей примерно про одно:
техническое задание
проектная документация
продуктовые требования
бизнес-требования
Логика одинаковая, просто разные понятия применимы в разных случаях:
техническое задание обычно пишется технарём для технаря, оно прописывается достаточно детально, остаётся только код написать
продуктовые требования — верхнеуровневое описание задачи при создании IT-продукта, который приносит конечную ценность клиентам и продаётся сам по себе
проектная документация — пишется по проекту, проект — это всё, что не относится к продукту, например, вы хотите сделать промосайт с неким функционалом для маркетингового эффекта
бизнес-требования пишутся бизнес-аналитиком и обычно касаются автоматизации какого-то бизнес-процесса внутри корпорации
В данной статье я буду говорить вещи, общие для всех, но больше всё-таки про продуктовые требования, поскольку так обозначена целевая аудитория статьи. Однако термин ТЗ (техническое задание) является самым частым в обиходе, и я буду его употреблять. Но понимать под этим буду верхнеуровневое задание на разработку продукта.
Подготовка
Прежде чем приступать к созданию проектной документации, нужно точно решить:
для кого вы делаете
что вы делаете
какую задачу решаете
что самое важное (ваше конкурентное преимущество)
а что неважное (чем можно пожертвовать, что не нужно вообще или на данном этапе)
в каком формате делается продукт (чат-бот, веб или приложения)
Ответы на все эти вопросы лежат в продуктовой области, а не технической. Поэтому ответ на них должны знать вы (заказчик), а не исполнитель.
Самые важные вопросы, которые нужно себе задать при написании продуктовых требований:
Есть ли референс? Референс — это продукт, с кого можно скопировать большую часть того, что вам нужно. Если референс есть, то это облегчит всё остальное раза в 3, потому что ничего не нужно выдумывать.
Какие объективно есть технические требования? Сколько человек зарегистрируется? Какой объём запросов в секунду ожидается? Как много данных? Вот прямо в цифрах. Но не когда-то потом в светлом будущем, когда "стартап вдруг выстрелит", а на реалистичном горизонте в год.
Отметить пунктами, что из этого действительно важно для конечной цели:
дизайн (красивость, уникальность)
динамичность интерфейсов (сложный интерфейс, например, в играх)
функциональность (насколько много логики)
умные алгоритмы (ML, рекомендации, работа с большими данными и т. д.)
безопасность, критичность инфраструктуры, отказоустойчивость, надёжность, строгая консистентность (в финансовых сервисах важно)
интеграция с другими сервисами и системами
Только не надо говорить, что всё важно! И дизайн, и динамичность, и функциональность, и безопасность. Так не бывает. Если хотите, чтобы всё было важно, то исполнители это с радостью подхватят, вы ведь им на год обеспечите работой целую команду. Либо не будет ничего из этого. Придётся расставлять приоритеты, и делать это до начала работы.
Правильный ответ на эти вопросы должны исходить из вашего позиционирования. Каков рынок, что он диктует, к чему привыкли пользователи? За счёт чего вы собираетесь конкурировать на этом рынке, в чём уникальность? Конкурентное преимущество нужно усиливать, во всём остальном можно делать гигиенический минимум.
Например, вы делаете продукт на рынок, где есть 100 аналогичных решений, и вы делаете то же самое, только красивей? Это один сценарий.
Вы придумали супералгоритм, уникальную механику решения задачи? Это другой.
Вы делаете аналог зарубежного сервиса, чтобы занести его в реестр отечественного ПО и продавать госзаказчикам? Третий.
А ещё надо понимать для кого мы составляем ТЗ. Для специалистов какого уровня, кого мы ищем? И кем мы являемся сами? Если вы CEO/CPO, и составляете проектную документацию для CTO, то не нужно ударяться в технические детали, с этим он должен разобраться сам, и вашей "помощи" с детализацией он не обрадуется. Аналогично с ТЗ для аутсорсинговой компании. Надо говорить на своём уровне, в своих терминах, ничего не выдумывать. Держать образ читателя в голове.
Пример ТЗ
Возьмём в качестве примера проектную документацию на платформу, которую я уже сделала. Как могла бы выглядеть документация на неё, Допустим, что автор данных продуктовых требований — конечный заказчик, а не проджект-менеджер, который будет координировать узких специалистов. Поэтому продуктовые требования будут написаны на достаточно высоком уровне абстракций. По-простому. Но при этом ёмкие и достаточные.
Ответы на главные вопросы
Что делаем: платформу для соединения брендов одежды и цехов на российском рынке.
Целевых аудиторий две:
бренды одежды — до 2000 потенциальных пользователей
цеха — до 500 потенциальных пользователей
Цифры:
бренды одежды — до 2000 потенциальных пользователей
цеха — до 500 потенциальных пользователей
заказы — до 10 в день
высокой нагрузки на сервис не будет даже в случае, если он станет монопольным
объём данных — вряд ли больше 100 Гб в базе данных, вряд ли больше 1 Тб в хранилище
Есть ли референс?
прямого референса нет
есть несколько платформ на российском рынке, но не очень удачные и ими не пользуются
есть платформы в других сферах для вдохновения какими-то отдельными элементами (youdo, profi.ru и т. д.)
Конкурентное преимущество:
удобная механика поиска заказов
конкурируем с профильными чатами в телеграм
важным для успеха является количество самих участников (это маркетинговая часть, а не техническая)
Анализ важности и неважности компонент:
дизайн — не критичен, и цеха, и бренды пойдут и на уродскую платформу, если они смогут решить на ней свои бизнес-задачи, а в дизайне достаточно гигиенического минимума, главное тут UX, чтобы пользователи не заблудились
динамичность интерфейсов — совершенно неважно, там нет динамики и сложных элементов, информационная площадка
функциональность — логики немного, но то, что есть должно быть сделано хорошо
умные алгоритмы — их нет, всё линейно
безопасность и надёжность — не критично, можно потерять пару заказов, ничего страшного не случится, можно полежать несколько минут, если вдруг кто-то придёт в это время, то вернётся позже
Какой формат:
web — основное, при этом трафика больше будет на мобилах и планшетах, чем на десктопах, потому что (внезапно!) люди за пределами IT не все имеют ноутбук
приложения — нужно, но не первостепенно, делаем по-простому из сайта, на сдачу + сделать пуш-уведомления, это как раз важно, т. к. есть заявки и нужно оперативно уведомлять другую сторону
телеграм-бот — можно сделать потом, ради уведомлений о заказах, будет удобно тем, кто не хочет ставить приложения, но не критично
десктоп приложение — не нужно вообще
Пререквизиты (это то, что есть, ресурсы и материалы, что будет дано исполнителю):
название SewTerra
лого и фирменный стиль (цвета, шрифты)
домен sewterra.ru
содержимое лендинга, с полностью написанными текстами, например в notion
аккаунт в robokassa (для приёма платежей)
есть аккаунт appstore и google play (для публикации приложений)
Функциональные требования
Разделы верхнеуровнево:
публичная часть сайта (то что доступно без регистрации): лендинг, страница поиска цехов, детальная страница цеха, статические страницы (публичная оферта, политика конфиденциальности)
авторизационная часть: регистрация как цех, регистрация как бренд, вход, восстановление пароля через почту
личный кабинет цеха
личный кабинет бренда
внутренняя админка, где можно просматривать и менять все данные, а также управлять статическими страницами сайта
нужно, чтобы был базовый гигиенический минимум SEO (robots.txt, sitemap, title, description, H1 на каждой странице, alt у картинок, и прочее) — это тема отдельной статьи, для всех проектов всё универсально, в ТЗ расписывать специально не нужно
модуль уведомлений и их настройка
Личный кабинет цеха:
у одного аккаунта может быть несколько цехов
добавление и заполнение профиля цеха (анкета), редактирование
возможность увидеть список заказов от брендов
возможность откликнуться на заказ
Личный кабинет бренда:
у одного аккаунта может быть несколько брендов
добавление и заполнение профиля бренда (анкета), редактирование
поиск цехов, возможность отфильтровать и посмотреть на карте
возможность создать/отредактировать заказ
возможность отправить заказ цеху
У всех в личном кабинете есть функционал:
ввести и отредактировать свои контактные данные
изменить пароль
удалить аккаунт полностью
настроить уведомления
в колокольчике на сайте
по email
push в приложении
Сущности, данные и поля
(Поля, отмеченные звёздочкой* , являются обязательными)
Бренд:
Название*
Описание
Город*
Сайт
Начинающий бренд (Да/Нет)*
Цех:
Название*
Описание*
Город*
Адрес*
Сайт
Данные:
Минимальный заказ, в штуках*
Работает ли с начинающими брендами? (Да/Нет)*
Фотографии цеха (может быть несколько)
Направление работы цеха (множественный выбор)*:
Трикотаж
Ткань
Кожа
... (редактирование вариантов должно быть в админке)
Оборудование*:
Прямострочка
Оверлок
... (редактирование вариантов должно быть в админке)
Какие изделия производит*:
Костюмы
Платья
... (редактирование вариантов должно быть в админке, данные в формате дерева категорий, может быть любая вложенность)
Услуги*:
Разработка лекал
Отработка образца
Крой
... (редактирование вариантов должно быть в админке)
Портфолио:
Изделие
Фотографии (может быть несколько)
Цены:
Изделие
Заказ от шт.
Цена за шт.
Поля для фильтрации: минимальный заказ, работа с начинающими, направление, оборудование, изделия, услуги.
Заказ:
Название*
Кол-во изделий в партии*
Основной материал (текст)*
Ассортиментная матрица (текст)
Техническое задание (1 файл)
Что из этого уже есть (Да/Нет):
Лекала
Образец
Ткани
Фурнитура
Фото к заявке (может быть несколько)
Бизнес-логика
Единственный, пожалуй, алгоритм, который здесь есть, — это логика смены статуса по заказам (Tender) и заявкам (Tender Request). Синим обозначено действие цеха, оранжевым обозначено действие бренда, в узлах — статус заявки, на ребре — название кнопки, которую нажимает либо цех (синим), либо бренд (оранжевым):
Зачем же всё-таки писать ТЗ
На примере ТЗ, приведённого выше, посмотрим, в чём же оно нам могло помочь.
Найти противоречия на бумаге
Посмотрите на схему смены статусов заявки из ТЗ, и теперь я расскажу, как обычно приносят идею. Звучало бы оно примерно так: «ну там значит цех есть, бренд есть, один оставляет заявку, другой принимает, они работают, всё», а по факту есть куча состояний и переходов, каждый из которых нужно предусмотреть. Большинству людей кажется, что всё очевидно и слова не нужны. На практике выходит, что всё настолько неочевидно, что вытащить из головы и положить на бумагу трудно, требует напряжения ума, это явно не то, что льётся ручьём как нечто само собой разумеющееся.
ТЗ позволяет отловить ошибки на самом раннем этапе. Найти бо́льшую часть основных противоречий, нерешённых вопросов, которые даже не задавались, но на бумаге они видны, и их придётся решать! Когда всё собрано в одном месте, то можно окинуть одним взглядом контекст, задачу и образ решения, понять соответствует ли задача контексту, а решение — задаче. Можно предотвратить множество ошибок и затрат ресурсов, поменяв буквы в текстовом документе, а не работающий код.
Отвлекусь на короткую историю. Дело было в 2011 году, ко мне пришли тоже с двусторонней платформой (как sewterra), там связь между теми, кому нужно вывозить строительный мусор, и мусорными компаниями. Ну я сделала. И уже после этого, когда пришло время подключать монетизацию, внезапно (!) оказалось, что робокасса берёт 5% за эквайринг, а значит, экономика не сходится и платформа априори будет работать в минус, т. к. они собирались всего 5% брать комиссии. А ведь могли бы это выяснить на этапе ТЗ, а по-хорошему и ещё раньше, на этапе составления финансовой модели бизнеса.
Собрать пререквизиты
Прежде чем идти к исполнителям, вам надо чётко и ясно понимать, что от вас нужно, чтобы он смог реализовать функциональные требования, которые вы выдвигаете. Например, если вы в MVP сразу же хотите подключить монетизацию на сайте, то у вас в качестве пререквизита уже должно быть юридическое лицо, счёт в банке и договор с платёжной системой. Иначе уберите это из ТЗ! Вам же исполнитель посчитает смету на это тоже, а потом снижать стоимость договора не будет, скажет: «вы нам не предоставили все данные, проблема на вашей стороне, а не на нашей».
Обозначить границы
Главная метрика хорошего ТЗ — это точность! В нём должно быть всё необходимое. И не должно быть ничего лишнего. Второе так же важно, как первое. Нужно в ТЗ не только описать то, что должно быть. Но и то, чего не должно быть.
Писать нужно честно, объективно, без прикрас, перфекционизма и усложнения. Вот у меня в ТЗ написано: дизайн неважен, это неважно, и то неважно. По сути, успех платформы будет зависеть от маркетинга и количества пользователей, а не от того, что находится во власти технаря. Жёстко? Да, жёстко. Смотрим трезвым взглядом, отсекаем всё лишнее. Если не отсечёте, то разработчики по умолчанию будут считать, что вам всё нужно, и выльется это в долгострой, завышенные сроки и стоимость. И получите вы то, что вам не нужно. Если вы заранее обозначите контекст, то они не смогут игнорировать озвученные требования, сложнее будет додумать лишнего и включить в смету. Делают они это даже не специально, а на автомате.
Минимизировать коммуникацию
Расписывать нужно только то, что важно именно для вашего проекта и является уникальным, не нужно расписывать авторизационную часть, она вообще везде одинакова и стандартна, все знают механику того, как работает регистрация/вход/восстановление пароля. Почему-то я часто вижу, что люди расписывают очевидные вещи (авторизация или внутренности статических страниц), но не расписывают сложные. Видимо, потому что они делают что проще, где мозги меньше надо напрягать, набивают в ТЗ объём и думают, что они задачу свою выполнили. Но это называется халтура. Поймите, эта вода в ТЗ тоже не нужна никому.
На примере ТЗ выше, если не прописать все сущности и поля, то можно бесконечно коммуницировать на тему:
А в заказе может быть несколько фото или одно?
А по каким полям фильтровать список цехов?
А город — это обязательное поле у бренда?
Представьте. Он сел делать проект, наткнулся на вопрос, написал вам в мессенджер, пошёл уже делать что-то другое, вы ответили через 2 часа, он продолжает делать что-то другое, он ведь уже погружен в ту задачу, потом вернулся через 3 часа, снова сел делать, поработал полчаса, потом у него возник другой вопрос. И так дело на 1 час может растянуться на неделю. Надо предоставить человеку всю информацию, чтобы вопросов не возникало. Вопросы у него должны возникать только какие-то реально нетривиальные, которые сложно заранее предусмотреть.
Ответы на все эти вопросы относятся к продуктовой части. Программист понятия не имеет о таких вещах, он не разбирается в вашей предметной области, и лучше не доверять ему делать выбор в этом. Даже если предметная область якобы понятна всем и "очевидна", всё равно это ваша работа всё прописать. Если вы хотите переложить на кого-то работу, меньше напрягаться, то и ценник будет соответствующий. И страдать будут все. Страдания можно минимизировать хорошим продумыванием ТЗ заранее. Не нужно дожидаться от исполнителя вопросов. Очевидно, что данные о полях являются частью задачи. Чем меньше вопросов ему придётся задать, тем меньше слов, и больше дела. И быстрее/дешевле результат. На коммуникацию может уходить очень большой процент от всей общей работы. Чем больше коммуникации потребуется, а это видно уже по ТЗ, которое вы приносите, тем меньше денег исполнитель вам озвучит.
Уменьшить стоимость
Одна из функций ТЗ — это передача его исполнителям для оценки стоимости и сроков. Не нужно писать им и спрашивать «сколько?» пока нет ТЗ! Потому что они ответят вам по верхней планке, заложив сразу все риски (на коммуникацию, на уточнения требований, на то, что вы теоретически забыли упомянуть, на то что возникнут противоречивые хотелки), и потом ещё умножат это на два, потому что неопределённость высока, когда на бумаге нет ничего. Знаю я вот это вот «пока ТЗ нет, ну вы сориентируйте примерно, чтобы я понимал, ТЗ будет потом». Я-то сориентирую. Только когда вы на это "примерно" согласитесь, я буду понимать, что бюджет такой ок. Уменьшать озвученную цену после ваших уточнений, я, конечно же, не буду, она так и останется по верхней планке.
Получить другое отношение
Когда приходит человек с хорошим ТЗ, к нему и отношение другое. Сразу понятно, что заказчик серьёзный, подготовленный, проделал сам работу, собрал все пререквизиты, готов напрягать мозги. А значит, с ним будет работать легко и приятно. Производить такое впечатление — дорогого стоит. Они поймут, что на сопутствующую коммуникацию с вами уйдёт минимум времени, и исправлений потом тоже будет мало. Что вы системный, логичный, понятный, думающий. С вами хочется работать. И не хочется накидывать сверху риски за "неадекват" и компенсацию возможных страданий. Больше желание работать, меньше сопротивление => ниже цена.
Найти подходящего исполнителя
Написанное готовое ТЗ поможет найти наиболее подходящего исполнителя. Это происходит за счёт выравнивания. Ни вы, ни исполнитель, не рисуете себе из абстрактных слов, которых нет на бумаге, то что хотите услышать. Не додумывайте. Сталкиваетесь друг с другом сразу в деле. Он видит, что вы точно хотите, он примеряет это на себя. Вы видите как он реагирует на информацию. Будущее взаимодействие становится прозрачней и предсказуемей. К смете не будут накидывать процент за неопределённость и возможные проблемы, за коммуникацию.
Плюс по этому ТЗ вы можете задать разумные вопросы и он на них вразумительно может ответить. Не просто «скока?», это вообще не самый главный вопрос так-то. А что-то умное спросите, чтобы он мог проявить себя и показать на деле заинтересованность. А не просто с потолка объявить завышенную цену, вдруг вы согласитесь. Именно к этому приводит отсутствующее ТЗ и предложение обсудить на звонке.
Можно ли делегировать написание ТЗ?
Краткий ответ — нельзя.
Вытаскивание из мозга на бумагу — это супер-упражнение. Которое будет полезно вам самим в первую очередь.
Когда всё находится в голове, то кажется, что там идеальная непротиворечивая картина. В состоянии «у меня в голове есть полная и чёткое понимание, как это должно работать» кажется, что написание ТЗ — трата времени на лишние действия. Истинная же причина не в том, что это слишком просто, а в том, что слишком сложно. В голове иллюзия непротиворечивой картины, сложно сталкиваться с тем, что реальность иная. А так хотелось оттянуть момент боли и напряжения ума. Или делегировать кому-то.
Делегировать GPT тоже не нужно, он не сможет найти противоречия в вашей голове, а выдаст что-то шаблонное. Но результат вам нужен же нешаблонный? Есть иллюзия "автоматизации" с помощью GPT, но это не автоматизация, а халтура. Проблема ещё может быть в том, что GPT там напишет того, в чём вы не разбираетесь, а вы не сможете обосновать, откуда взялись те или иные тезисы. Потом это ещё кому-то читать и распутывать клубок, думать о том, откуда взялась данная строчка в ТЗ, действительно там что-то важиное, или оно унаследовано от шаблона. Если хочется взять GPT, значит, вы что-то делаете не так. Упрощайте. Цель в том, чтобы свои мысли и идеи на бумагу изложить, а не в том, чтобы получить бумажный артефакт.
Также не советую и отдавать это на аутсорс. Можете нанять себе человека, который будет вас интервьюировать если так сложно. Но есть работа, которую предприниматель/заказчик/заинтересованное лицо должен сделать сам и никак иначе.
Если я вас не убедила, то задайте себе вопрос, «а почему у меня есть желание делегировать написание ТЗ»? Только не говорите, что вы не профессионал в этом, ведь в этой статье я объяснила, что ничего сверхъестественного не требуется. Опишите в любом удобном вам виде, без фреймворков, без нотаций, без шаблонов. Просто объясните письменно, что хотите сделать. На своём уровне, как можете. Этого уже будет достаточно.
ТЗ — это необходимый документ, но не всегда достаточный. После того как вы выберете исполнителя, то по-хорошему, если ТЗ недостаточно полное, он должен сам написать проектную документацию о том, как это будет реализовано конкретно, в технике, сочинение на тему «как я понял, что вы хотели сказать и что собираюсь делать». Согласовать с вами, после этого приступать к работе. Не надо путать ваш документ и документ исполнителя. Понимая это, возможно будет проще выключить перфекционизм и написать ТЗ от себя, ведь эта работа не будет высечена в камне. Это всего лишь первый этап для начала диалога.
Если у вас есть IT продукт на разных стадиях (от идеи), приглашаю в своего бота @annkpx_bot, в нём я воплотила свой концентрированный опыт в формате диагностики.
