ТЗ на разработку IT-продукта: почему это важно и как правильно подойти к составлению технического задания

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

Нередко предложение разработать сперва ТЗ воспринимается в штыки, и мы прекрасно понимаем нежелание клиента тратить дополнительные время и ресурсы на «ненужную» работу. Ну, например:

1. Откладывается старт проекта, а сроки и без того горят. И на этом фоне потратить несколько недель, а то и месяц, на сбор, уточнение и фиксацию требований кажется ненужным расточительством. Да и зачем, ведь клиент всегда на связи, и можно просто написать / позвонить и уточнить!
2. Не хочется разводить лишнюю бюрократию – в общем-то продолжение предыдущего аргумента. «Будут вопросы – пишите мне, я отвечу».
   
3. Клиенту проект и так ясен и понятен полностью, поэтому расписывать что-то нет нужды. А если что-то непонятно – снова, всегда можно поговорить и разрешить возникшие вопросы.
   
4. Итого: зачем же нам этот «ненужный» документ, если мы и так можем напрямую друг с другом обо всём договориться? Особенно если за него ещё и просят заплатить!
   

Даже я, пока пишу этот текст, в какой-то мере испытываю солидарность с заказчиком, ведь аргументы серьезные. Тогда почему же все-таки ТЗ нужно? Или, вернее, когда оно действительно нужно, а когда аргументация «против» более чем справедлива? Давайте попробуем разобраться.

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

1. Детализация абстрактных идей. Часто, даже если в целом задача действительно понятна и поставлена довольно точно, в постановке могут найтись некоторые неопределённости. Более того, конкретные и понятные задачи могут оказаться расплывчатыми из-за разных способов реализации.

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

• Как должен выглядеть предпросмотр товара, должна ли картинка увеличиваться при клике, как должен выглядеть слайдер?..

• Можно ли в блок показа картинки заливать видео? Должно ли это видео храниться на сервере с сайтом, или подойдёт встроенный плеер из YouTube?

• Что будет в блоке описания: просто свободный текст, или таблица с характеристиками? Должны ли характеристики браться из специальных полей карточки товара или же контент-менеджер должен просто сам вводить произвольный текст?

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

Или другой вариант: задача проста и понятна, но имеет несколько способов реализации. Например, разработать модуль обратной связи: здесь можно действительно разработать какую-то систему работы с обращениями на стороне сайта, сделать личный кабинет менеджера, настроить рассылку уведомлений о новых сообщениях и т.п. А можно просто поставить какой-нибудь готовый модуль, типа JivoSite, и по стоимости и трудоёмкости разработки эти две задачи радикально отличаются!

2. Более обоснованный выбор технического стека на проекте. Экстраполировать предыдущий пример можно на гораздо более сложные задачи, чем форма обратной связи. В целом может оказаться, что часть функционала, который требуется клиенту, уже реализован каким-то сервисом или библиотекой, и здесь можно сэкономить на разработке с нуля. Либо же наоборот, появится понимание, что требуемый бизнес-процесс в готовых решениях работает совсем не так, как нужно клиенту, и придётся писать всё самим.

Чтобы провести такой анализ, нужно обладать необходимыми данными, детально понимать задачу клиента. К сожалению, на нашей практике были случаи, когда мы ошибались в прогнозах, изначально вместе с клиентом рассчитывая, что функционал в готовом виде уже реализован в стороннем модуле, «остаётся только немного допилить». Когда же дело дошло до реализации, выяснялось, что требуемое поведение реализовать сложно/дорого или даже практически невозможно с использованием предполагаемой технологии. Итог печален: сверхурочная работа, непопадание в сроки, повышенные затраты. Для обеих сторон лучше постараться избежать таких ситуаций «на берегу».

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

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

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

4. Более точные прогнозы по бюджетам и срокам. Это достижимо, если ТЗ закрывает вышеописанные пункты. Как и любая хорошая аналитика, хорошо разработанное ТЗ значительно снижает возможные неопределённости в ходе реализации проекта.

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

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

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

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

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

Рассмотрим на примерах сайтов, от простого к сложному.

1. Простые лендинги. В данном случае важно иметь прототип для разработки дизайна, понимать, нужен ли адаптив для мобильных устройств, а также какое-то описание требуемых «спецэффектов» на странице, если они есть. В остальном какая-то детальная документация по проекту не требуется, т.к. как правило визуальным рядом весь проект и заканчивается.

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

3. Социальная сеть. Да, и такие проекты сегодня пишут! По сути, это тот же информационный портал, но есть более детальное разделение ролей и интерфейс публикации не только для редакторов, но и для других пользователей системы. Здесь уже требуется формализовать требования, т.к. у разных категорий пользователей есть разный «пользовательский путь», разные права доступа к функциям системы, и это всё необходимо зафиксировать как минимум чтобы просто не запутаться самим.

4. Интернет-магазин. Довольно шаблонная задача на сегодняшний день, и если есть планы использовать для него какое-то готовое решение практически без модификаций, например магазин от Битрикса, тогда можно действительно обойтись без ТЗ. В остальных же случаях стоит проанализировать и прописать те моменты, которые отличают новый магазин от всех прочих – в плане интерфейса, бизнес-логики, структуры каталога и процесса покупки товара. К примеру, магазины, ориентированные на бизнес, могут не предоставлять вообще способов оплаты на сайте, но при этом в конце покупки должен генерироваться PDF файл счёта на оплату. Кроме того, для такого рода проектов обязательно стоит уделить внимание обмену данными с внешними системами, наверняка такие будут, как минимум с учётной программой типа 1С.

5. Маркетплейс. Как социальная сеть отличается от простого блога возможностью разным категориям пользователя публиковать контент, так же и маркетплейс отличается от простого интернет-магазина возможностью разным продавцам продавать свой товар и управлять каталогом, а платформе получать комиссию с каждой сделки. Здесь техническое задание – вещь обязательная, т.к. для разных категорий пользователей будут разные бизнес-процессы, а также, скорее всего, понадобится биллинг и интеграции с банками.
6. Автоматизация процессов организации: ERP, CRM системы. В проектах такого рода аналитика в целом – один из важнейших этапов работы, и, порой, наиболее трудоёмкая её часть. Совсем без ТЗ в этой сфере можно делать только какие-то мелкие «наколеночные» решения, чтобы малой кровью протестировать гипотезу.
   

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

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

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

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

• Менеджер продукта со стороны Клиента.
• Менеджер проекта со стороны Исполнителя.
• Ведущий разработчик.
• Дизайнер, UI/UX.
• SEO-специалист.
• Специалисты со стороны внешних систем (например, 1С).
• Возможно участие дополнительных лиц, участвующих в согласовании или формировании списка бизнес-требований.

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

В таком случае разработка ТЗ может занять 1–2 месяца, в зависимости от эффективности взаимодействия и детальности проработки требований.

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

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

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

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