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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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