Плохие ТЗ на разработку: что в них не так, и как исправить?

Не пишите ТЗ на разработку, просто скачайте любое из интернета и поменяйте часть требований под себя. Смеётесь? Мы всё ещё встречаемся с таким подходом. Рассказываем, как составить адекватное ТЗ на сложную разработку, понятное любому исполнителю, чтобы в конечном итоге ожидания и реальность совпали (а не как обычно).

Почему мы об этом пишем?

Небольшой объем задач (MVP, мини-проекты до 3 месяцев без существенных изменений в ТЗ) или дизайн-проекты можно оценивать по Fixprice (фиксированный бюджет). Если проект крупнее, стараемся переводить его в работу по модели Time and Materials. Заказчик от такого подхода только выигрывает: есть выделенная под задачи команда, понятно долгосрочное бюджетирование, можно гибко менять требования по ходу проекта.

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

Чтобы расчет был максимально точным, очень важно получить от заказчика детально проработанное ТЗ. Очень круто, если ТЗ составляли компетентные люди, либо вы сами. Но это что-то на идеальном 🙂

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

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

Например, картинке ниже ребята попросили написать код.

Плохие ТЗ на разработку: что в них не так, и как исправить?

И вот что получили в итоге.

Плохие ТЗ на разработку: что в них не так, и как исправить?

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

Какие проблемы часто встречаются в ТЗ?

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

ТЗ это не главное, нам нужно узнать цену.

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

В итоге оценка бывает неточной, дедлайны переносятся, потому что (сюрприз!) предполагалось еще и отдельное мобильное приложение, а не просто личный кабинет в веб-версии. В таком случае лучше отказаться от FIX-модели в пользу T&M, взять разработчиков на аутстаф и управлять приоритетами задач. Спланировать бюджет можно исходя из их рыночных ставок.

Абстракция, абстракция и еще раз абстракция.

Такой вариант ТЗ на качели вы, возможно, еще не видели
Такой вариант ТЗ на качели вы, возможно, еще не видели

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

Опять же, выход один — связываться с заказчиком и задавать целую пачку вопросов.

Тз пишется для кого угодно, только не для разработчика.

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

К примеру, фронтенд-разработчик хочет от нас услышать есть ли готовая дизайн-система, что с адаптивностью и «может вообще надо реализовать PWA-приложение?».
* На самом деле фронтендер хочет услышать намного больше конкретных технических вещей, но чтобы не перегружать статью хватит и такого примера.

Я его слепила из того, что было.

ТЗ пишутся в совершенно произвольном порядке. Иногда берут за основу ГОСТ 34.602, но добавляют собственные фишки. Во многих ТЗ информации для оценки катастрофически не хватает: ТЗ умещается на паре страниц, большая часть из которых не описывает ни юзкейсы, ни элементы интерфейса, ни экраны. Приходится созваниваться и тратить время на уточнение.

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

Детали, которые не касаются разработки.

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

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

Пример из практики

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

Плохие ТЗ на разработку: что в них не так, и как исправить?

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

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

Одной из дополнительных задач было просчитать выполнение плана, но формул по расчету в ТЗ, увы, не было. Сейлзы, конечно, очень удивились и все-таки решили этот момент уточнить у заказчика. Мало ли, может забыли формулу указать или неудачно форматнули документ перед отправкой. Попросили скинуть нормативы, а также формулы, по которым все это придется считать.

Оказалось, формул нет, мы должны их придумать. Ок, закопались в аналитику процессов клиента, чтобы создать необходимые формулы.

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

Проверьте свое ТЗ

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

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

Из какой информации мы получаем максимум полезных данных для оценки?

  1. Цели и задачи ИТ проекта. Расскажите немного о самом проекте, его идее. Помогает исполнителю избежать ошибок и разобраться, зачем нужно реализовывать проект, какие именно фичи нужны. Для примера, компании N нужно мобильное приложение, чтобы оповещать клиентов о скидках и акциях, а также показывать баллы, накопленные по программе лояльности. Значит, цели у нас как минимум 2: создание Программа лояльности и маркетинговые оповещения об акциях и скидках.

  2. ЦА. Расскажите, кто будет конечными пользователями продукта, их социальные и поведенческие характеристики. Это поможет точнее сформулировать функциональные требования к продукту. Операторы системы управления производством и любители знакомств в Tinder’е разные по пользовательским привычкам, и прямо сейчас в голове вы можете представить почему. То же самое стоит делать применимо к вашим пользователям.

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

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

  5. Интеграции. Обязательно распишите, с чем новый проект должен быть интегрирован. Исполнитель не знает, с какими программами и сервисами вы работаете. Поэтому, чем подробнее расписан этот пункт, тем лучше. Хотите, чтобы в админке появлялись актуальные цены из 1С? Или при введении ID клиента появлялись данные из CRM? Смело пишите.

  6. Сценарии использования продукта (юзкейсы) . Что будет делать пользователь и какой результат должен получить. Например, вам нужен сервис по регистрации на сайте. Шаги могут выглядеть примерно так. Пользователь нажимает на кнопку «Зарегистрироваться» — система открывает форму регистрации — пользователь заполняет все поля формы и нажимает «Зарегистрироваться» — система проверяет корректность заполнения полей, а также наличие введенного email в базе. Если все корректно и пользователя нет в базе, то создает аккаунт.

  7. Поддерживаемые устройства и операционные системы. Обязательно перечислите, с какими устройствами и ОС будет взаимодействовать система. Мы помним про mobile first, но часто бывают нюансы.

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

  9. Экраны. Продумайте, из каких экранов будет состоять ваш проект, как происходит переход с экрана на экран, как работает та или иная кнопка.
  10. Шаблоны страниц. Опишите и проиллюстрируйте, как будет выглядеть та или иная страница, какие элементы интерфейса будут на ней использоваться, будут ли всплывающие окна. Например, в приложении основное меню располагается внизу страницы. Разделы в нем будут обозначаться иконками. Всего 5 иконок: Главная, покупки, скидки, каталог и профиль.

  11. Требования к UI, если они есть в контракте. Есть ли есть брендбук, дизайн-система? Добавляем ссылку на них. Какие шрифты будут использованы, цветовая гамма, логотип и какой текст нужно разместить.

  12. Аналитика. Какие данные вы хотите собирать? Может сколько кликов пользователь сделал в приложении или на какие экраны попадают чаще всего? Обязательно укажите это в ТЗ + добавьте нужные варианты отчетов и их визуализаций.

Подытожим

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

Плохие ТЗ на разработку: что в них не так, и как исправить?

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

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

1313
4 комментария

1. В действительно крупных проектах с бюджетом хотя бы 20+ млн рублей ТЗ обычно пишет подрядчик. Либо за отдельные деньги, либо бесплатно. Высаживается команда аналитиков, разбирают "хотелки" по винтикам, согласуют, пишут горы документов. Это месяц-полтора работы. Это инвестиции, если уверены что сможете потом выиграть конкурс. Но тот кто пишет ТЗ уже имеет преимущество в конкурсе - т.к. может там написать что-то "под себя".
Лайфхак: в крупных компаниях есть некий лимит на бесконкурсные договора, обычно это до 500К. На ТЗ хватит. Однако, слыхал истории из кровавого энтерпрайза про ТЗ за 100М.

2. Если у заказчика нет глубокой экспертизы в IT и в технологиях, на которых будет реализован проект - лучше вообще не писать ничего про технику и код. Просите заказчика писать исключительно про бизнес-задачи, в формате требований (или ТТ). Лишние технические подробности только усложнят подрядчику выбор оптимальных решений. интеграционные задачи конечно не обойдутся без технических деталей, но это лучше вынести в сам проект, написать в стартовом ТЗ только бизнесовые ограничения.

3. Если у заказчика есть отличная IT-экспертиза, и он точно знает размеры и харакетиристики новой "детали" в свой IT-ландшафт и может это все качественно и подробно описать - считайте повезло. Такое бывает крайне редко, не стоит этого ожидать от заказчика.

5

Спасибо за коммент!

«Реалии таковы и больше никаковы» :) С новым заказчиком в рамках пре-сейла часто какой-то небольшой процент от проекта бесплатно делается.
Но если проект конкретного заказчика мы очень хотим включить себе в портфолио, то это в целом будут оправданные траты.

А если есть чит-код на полностью оплачиваемые пре-сейлы, то можно его прям в комменты?) Пошерим партнерам, 100 % заплюсуют)

Про п.2 — очень жизненно, но часто на оценку приходят проекты с уже описанными требованиями, где бизнесовые задачи случайно переплелись с чем-то сильно инженерным, примерно как наушники в кармане со связкой ключей))
Про это как раз был подзаголовок «Я его слепила из того, что было»)

1

Полезная статья, спасибо!

1