Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

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

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

На самом деле, слишком детализированное ТЗ зачастую бесполезно, а иногда и очень опасно. Помните «лангольеров» Стивена Кинга? Они пожирали время и пространство. Так и подробное задание съест ваше время и ресурсы. Оно легко может привести к усложнению и удорожанию проекта, а также замаскировать проблемы с достижением действительно востребованного результата.

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

Чем опасно слишком подробное ТЗ

1. На его понимание потребуется много времени

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

Как часто выглядит техническое задание на разработку, приходящее с запросом в IT-компании? 2 абзаца о компании, 1 абзац о целях разработки, 3 страницы воды и 100–300 страниц описания каждого процесса, каждого экрана с точным описанием форм, кнопок, функций, нюансов реализации, ролей пользователей и так далее. На то, чтобы вдумчиво его прочитать и понять, нужно очень много времени.

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

2. Оно мешает хорошей коммуникации

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

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

Это непродуктивная установка. Гораздо лучше останавливаться во время разработки и задавать вопросы «а туда ли мы идем» и «а получим ли мы желанный результат». Здесь разрешите процитировать отличную статью из блога Александра Бындю:

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

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

Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

3. В нем за детальными решениями не видно целей

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

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

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

Казалось бы, зачем подрядчику это знать? Есть ТЗ, есть руки и головы в штате, есть деньги. Но любую задачу можно решить разными способами. Одни оптимальные и приводят к ожидаемому результату, другие расточительные и приводят к разочарованию. У хорошего подрядчика есть опыт реализации проектов под бизнес-цели заказчиков, и он может предложить свое решение. Возможно, оно будет оптимальнее по трудозатратам, срокам готовности и удовлетворенности пользователей.

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

4. Подробное ТЗ не гарантирует достижения бизнес-целей

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

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

Здесь можно еще раз процитировать Александра Бындю:

Я, как разработчик и IT-архитектор, прекрасно понимаю, что любую задачу, как бы подробно она ни была описана, можно сделать сотней разных способов. Одни способы будут качественными и дорогими, другие быстрыми и «костыльными». Другими словами, при написании кода ужасного качества, можно формально выполнить требования ТЗ.

Есть способы достигнуть высокого качества IT-продукта, но точно не с помощью ТЗ.

Несколько советов по разработке ТЗ

1. Задаваться вопросом «Зачем я это делаю?»

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

  • Чтобы сделать продукт, который решит ваши задачи
  • Чтобы как можно быстрее получить оценку сроков и стоимости
  • Чтобы защитить себя от некомпетентного исполнителя

И каждый случай нужно разбирать отдельно.

Чтобы сделать продукт, который решит ваши задачи

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

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

Цели разных заинтересованных лиц
Цели разных заинтересованных лиц

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

Чтобы как можно быстрее получить оценку сроков и стоимости

Что нужно для того, чтобы узнать, сколько стоит продукт? Многие заказчики, которые представляют нам подробное ТЗ, думают, что описание каждой функции, экрана и кнопки упростит оценку, потому что снимет все возможные вопросы. А дальше мы можем занести все работы в Excel, проставить часы, умножить на ставку и получим какую-то сумму, которую уже сегодня сообщим клиенту.

Но в жизни все работает иначе. На самом деле, большое количество деталей «сожрёт» уйму времени на изучение, понимание и оценку. Кроме того в каждый отдельный оцениваемый элемент будут заложены риски, что приведет к раздуванию итоговой оценки. И все равно оценка не будет точной (см. первую проблему).

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

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

В идеале, стоит оценивать не стоимость и сроки придуманной функциональности, а задать сроки и стоимость, держа в голове бизнес-цели как ограничения. Состав работ, необходимых для их достижения, лучше прогнозировать вместе с подрядчиком. Для того чтобы делать продукты, строго укладывающиеся в ограничения по сроку и бюджету лучше использовать модель FFF: fix time, fix budget, flex scope. В рамках системы требования и решения не должны быть фиксированы детально. Нужно сохранить гибкость, чтобы регулировать объем работы по ходу проекта.

Чтобы защитить себя от некомпетентного исполнителя

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

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

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

2. Использовать схемы только там, где они нужны

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

Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?

Что в вашем конкретном случае более полно, компактно и непротиворечиво передаст информацию? Если текст, выбирайте его. Если вы уверены, что схема понятна и в ней нельзя запутаться, рисуйте схему. Не стоит использовать стандартные нотации если вы полностью не уверены в том, что они хорошо описывают нужный вам вопрос, или не используете все выразительные инструменты нотации. На эту тему уже писал Анатолий Левенчук — рекомендую его доклад.

3. Проконсультироваться у нескольких компаний

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

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

4. Не копипастить из чужих ТЗ

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

Когда смотрите на чужие примеры, берите не готовые решения, а вопросы, на которые в примере даны ответы и думайте как на них ответить в вашем случае (и надо ли). Всегда думайте сами, пишите своими словами и искренне делитесь ожиданиями и мыслями — это гораздо важнее. Остальное можно будет уточнить в ходе работ.

5. Описывайте то, что есть

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

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

Итог

Грамотно сформулированное ТЗ помогает экономить время и силы. Нет какого-то единого рецепта, как составить его так, чтобы информация для исполнителя была достаточной, непротиворечивой и лаконичной. Здесь каждый ищет баланс между формальным и неформальным, между подробным и лаконичным.

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

Удачи в работе!

Полезные статьи и литература:

1111
22 комментария

Комментарий недоступен

2
Ответить

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

Ответить

Я бы еще такой совет добавил — если вам предоставили подробную смету по вашему толстенному ТЗ, то давайте обратную связь и не "теряйтесь". Даже если итоговые цифры вас не устроили, уважайте затраченное поставщиком время на оценку.   

1
Ответить

Вот да. Мы с какого-то момента очень скептичны к такого рода расчетам. Ой, спасибо, что подсветили риски. Такой замечательный документ вы сделали. Мы, пожалуй, будем туда подглядывать, когда будем нажимать на «ООО Рога и копыта, с которыми мы решили делать проект». Ничего личного, просто они дали сроки и стоимость значительно ниже вашей. Оценки у них нет, они просто угадывали, но у вас то есть. Вот на ваши сроки мы и будем ориентироваться. А драть подрядчика будем по их обещалась. Большое спасибо за участие в нашем тендере, коллеги. Было, так сказать, очень продуктивно.

2
Ответить

Вся статья сводится к тому, что заказчику нужно определиться с бизнес-целями, а компания-разраб все сделает сама.;)
Но так не бывает. И подробное тз служит защитой заказчика в том, что он прописывает свои бизнес-цели так, как видит он, а не компания разраб.
И тут в игру вступает проджект/продакт (не важно на чьей стороне), который всех должен подружить.

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

1
Ответить

И заказчик и подрядчик птицы вольные и могут желать чего угодно. Но есть более продуктивные пути сотрудничества, а есть менее. К сожалению, детальное ТЗ часто не защищает клиента от риска "получить не то что нужно", а иногда еще и усиливает его (потому что подрядчик тоже будет думать не над тем, что нужно, а над тем чтобы соответствовать написанному в ТЗ).
"заказчику нужно определиться с бизнес-целями, а компания-разраб все сделает сама" - представьте, так бывает:) Если каждая из сторон грамотно сделала свою работу: заказчик не вываливал необоснованные фантазии или личные мотивы вместо бизнес-целей, а подрядчик имел достаточную компетенцию чтобы их понять и превратить в правильные функциональные требования и приоритеты.

1
Ответить

Вообще по толстенному ТЗ оценка вполне может быть точной. Другой вопрос, что это надо уметь оценивать (большинство не умеет), оценка может оказаться значительно выше ожиданий и занять примерно вечность. Ещё интересный вопрос - кто писал этот документ? Чтобы составить грамотное толстенное тз нужно минимум два-три человека с разной специализацией. Подробные портянки может писать и штат аналитиков. Почему эта компания сама не разрабатывает продукт, если они такие молодцы в спецификации?

1
Ответить