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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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