ТЗ не работают: как описать задачу разработчикам, чтобы получить корректную оценку

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

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

Когда клиент без ТЗ обращается в Skipp, мы изучаем его материалы, собираем команду по проектированию и помогаем провести предпроектную подготовку. Итог этой работы — описание задачи, которое потом отправится на оценку разработчикам.

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

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

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

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

В России для ТЗ есть ГОСТ 34. Ему следуют госучреждения, но стандарт устарел и не всегда подходит для бизнеса. ГОСТ 34 создали для космической программы и военно-промышленного комплекса, из-за этого в стандарте есть много требований к описанию аппаратной части, которой часто нет в современных ИТ-проектах. А некоторые рекомендуемые требования ГОСТ 34 избыточны, например, по патентной чистоте или квалификации персонала.

Готовить ТЗ по ГОСТу необходимо, если вы работаете с госзаказчиками. Также этот фреймворк подойдёт, если вы создаёте ТЗ для развития зрелой системы. Иногда мы используем некоторые элементы из методологии ГОСТ, например, UML-диаграммы. Но ТЗ по ГОСТу, особенно в бизнесе, — не гарантия того, что информации в задании хватит, чтобы разработчики чётко поняли, что нужно сделать, и точно оценили задачу.

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

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

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

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

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

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

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

Но если потом окажется, что нужно сделать интеграцию c Google Pay или Apple Pay, при этом обеспечить автоматические ежемесячные платежи, суть задачи меняется, и сроки могут растянуться.

Из-за низкой детализации задач разработчики по-разному оценят одно и то же ТЗ. Вот ситуация из реальной практики в Skipp. Мы отправили ТЗ, которое подготовил клиент, трём командам разработчиков. Они решили использовать разные стеки и дали оценки с разбросом в 330 часов:

Чтобы решить проблемы традиционных ТЗ, мы разработали свой формат описания задачи. Он состоит из трёх этапов:

Сначала продакт-менеджер Skipp помогает заказчику разобраться, какие задачи должен решать будущий продукт. Менеджер проводит продуктовое интервью с клиентом, может проанализировать конкурентов или провести глубинные интервью с представителями целевой аудитории. Словом, он погружается в задачу и использует весь свой арсенал, чтобы помочь заказчику понять, какой продукт нужно сделать.

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

Итог концептуального проектирования в Skipp — User Story Map (USM). Это карта ролей пользователей и действий, которые они совершают с ИТ-продуктом. Если мы делаем приложение интернет-магазина, то в USM продакт опишет, как клиент будет его использовать.

Например: «Клиент может авторизоваться, смотреть каталог товаров, добавлять товары в «Избранное», класть в корзину и оплачивать». Последовательный набор действий это и есть User Story, то есть, пользовательская история.

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

Тогда на основе User Stories будет удобно собирать список функций для MVP: нужно взять в первый релиз только критически важные функции, без которых пользователь не сможет пройти путь до конца. Можно детализировать USM ещё сильнее и на основе выбранных функций создать список верхнеуровневых задач для разработчиков.

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

Почему этап важно сделать

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

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

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

Что будет, если не сделать

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

Вовлечённость заказчика

Максимальная: заказчик передаёт материалы, вместе с нами изучает конкурентов и результаты глубинных интервью, синтезирует идеи.

Артефакт этапа в Skipp

User Story Map в Miro или Figma, результаты анализа в Notion.

Следующий этап описания задачи — визуальное проектирование. Его проводит дизайнер на основе USM. На этом этапе важно показать, как продукт будет выглядеть для пользователя: какие элементы интерфейса нужны на каждом экране, где и как размещать контент, как устроена навигация.

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

В Skipp на этом этапе создают прототипы разного уровня детализации. Есть проекты или части проектов, где интерфейс важнее дизайна. Для них в Skipp соберут чёрно-белый прототип с низкой детализацией. Его можно назвать вайрфрейм (wireframe) или лоу фиделити (low fidelity, low-fi) прототип.

Для приложений или сайтов, где есть пользовательский интерфейс, в Skipp подготовят подробные кликабельные прототипы. Интерфейс проработают детально: ползунки, галочки, поля форм и кнопки будут на своих местах. В таком прототипе дизайнер задумается о типографике и размерах объектов, подберёт для примера подходящий контент или возьмёт реальный.

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

Иногда в Skipp пропускают прототипирование и сразу делают дизайн. Это возможно, если продукт простой, мы уже работали с заказчиком и говорим на одном языке, а ещё у проекта сжатые сроки. Если неопределённость и риски выше, а сроки позволяют заниматься подготовкой, мы соберём хотя бы вайрфрейм, чтобы синхронизировать видение интерфейса.

Почему этап важно сделать

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

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

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

Что будет, если не сделать

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

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

Кто делает в Skipp

UX-дизайнер.

Вовлечённость заказчика

Прототипами и макетами занимается дизайнер, заказчик даёт обратную связь и принимает работу.

Артефакт этапа в Skipp

Вайрфреймы или прототипы в Figma.

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

Функцию описываем так: берём User Story, из которой она родилась, объясняем условия её возникновения или действия, которые совершает пользователь, затем описываем результат функции и прикладываем скриншоты дизайна.

Чтобы быстро создать функциональную спецификацию, важно заранее провести два предыдущих этапа предпроектной подготовки: концептуальный и визуальный. Тогда у вас всегда будет ответ на вопрос «зачем нужна эта функция?» и «как эта функция выглядит?». Функциональная спецификация будет логичным продолжением предыдущих этапов и её подготовка не займёт много времени.

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

В Skipp функциональная спецификация состоит из двух элементов. Первый — фич-лист, формат которого мы адаптировали из статьи на Хабре. Это таблица из функций или фич, которые будут в ИТ-проекте. Каждую описывают по шаблону: User Story / Условия возникновения и действия пользователя / Результат / Дизайн. По такому фич-листу легко провести декомпозицию: превратить его в список задач и собрать бэклог.

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

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

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

Почему важно сделать

Функциональная спецификация обуславливает выбор технологий. Это удобно для работы: разработчикам не придётся додумывать, предпроектная оценка будет более точной, процесс подбора команды ускорится.

Что будет, если не сделать

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

Если заранее не продумать архитектуру в сложном ИТ-продукте, будет трудно вводить новые сущности, характеристики объектов или пользователей, настраивать взаимодействие между разными компонентами системы. В базах данных могут сделать разную логику. Всё это усложнит работу для команд, которые будут развивать проект.

Кто делает в Skipp

Руководитель проекта, который будет общаться с разработчиками: продакт-менеджер, проджект-менеджер или скрам-мастер.

Если в проекте сложная архитектура, функциональную спецификацию делает системный архитектор или системный аналитик.

Вовлечённость заказчика

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

Артефакт этапа в Skipp

Фич-лист, описание архитектуры продукта, дорожная карта разработки.

У традиционного ТЗ, даже если это документ на сто страниц по ГОСТу, много проблем. На рынке все пишут ТЗ по-своему, заказчику в принципе сложно написать полное ТЗ самому, а разработчикам сложно однозначно оценить его.

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

Концептуальное проектирование, которое клиенту поможет сделать продакт-менеджер. Они вместе разберутся, какой нужен продукт, и создадут USM.

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

Функциональная спецификация, которой займётся руководитель проекта — продакт, проджект или скрам мастер. Он создаст фич-лист: опишет механику и технологии функций, которые придумали в USM, даст ссылку на прототип или приложит скриншоты.

USM, прототип и фич-лист мы отправим на оценку нескольким командам разработки. По опыту мы знаем: с таким ТЗ клиент получает более однородные и точные оценки от команд, а разработчикам проще провести декомпозицию и собрать бэклог.

#планирование #тз