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

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

Небольшой объем задач (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-схемах и так далее), и в итоге сделают понятное ТЗ за вас.

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