Мы в 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 раз — этого будет достаточно.
Итог
Грамотно сформулированное ТЗ помогает экономить время и силы. Нет какого-то единого рецепта, как составить его так, чтобы информация для исполнителя была достаточной, непротиворечивой и лаконичной. Здесь каждый ищет баланс между формальным и неформальным, между подробным и лаконичным.
Помните, что техническое задание — это не цель вашей работы и не заменитель живого общения с подрядчиком. Поэтому не превращайте его в «лангольера», пожирающего время и силы. Делайте не больше, чем действительно нужно.
Удачи в работе!
Полезные статьи и литература:
- Когда пора прекратить писать Техническое задание?
- 5 причин написать ТЗ
- 12 проблем при работе по техническому заданию в IT-продукте
- Откровенное общение с заказчиком
- Техническое задание как база знаний о проекте
- Как и какое техническое задание писать при работе по Agile
- Доклад Анатолия Левенчука о нотациях
- О принципе управления проектами FFF
- Краткое описание системного мышления
- Качество вместо контроля качества
Комментарий недоступен
И мне бы этого хотелось:)
К сожалению, не существует идеального образца или шаблона, по которому можно сделать все классно. Намеренно не привожу конкретные примеры реализации т.к. они создают искушение сделать также или скопировать, вместо того чтобы думать о принципах в контексте своей текущей задачи.
Комментарий недоступен
Какие стандарты?
Стандарты нужны для стандартизируемых процессов/продуктов.
Тут уместно посмотреть на CYNEFIN Framework.
Если мы работаем над задачами типа Simple, то действительно можно и нужно использовать готовые стандарты и делать как написано сильно не фантазируя. Если мы работаем над Complicated-задачами, то нам скорее нужны не стандарты (готовые решения/инструкции), а принципы, лучшие практики или эксперт, который скажет "как надо".
Ну и далее, по мере увеличения неопределенности цели и пути ее достижения, готовые решения, стандарты и практики работают все меньше.
Прелесть в том, что отнесение задачи к той или иной категории и выбор метода ее решения субъективно и основано на понимании задачи и предыдущем опыте. Таким образом, надо думать своей головой и выбирать решение (в т.ч. применение стандартов или готовых практик) под ситуацию.
Имеет смысл разрабатывать свой стандарт, если есть много типовых задач и нужно обеспечить их контролируемое выполнение "на потоке". Например, разработка лендингов или типовых корпоративных сайтов может делаться по "шаблону ТЗ", который лишь слегка модицифицируются под потребности заказчика. Но кажется невозможным использовать готовый шаблон для описания требований, например, к CRM или маркетплейсу.
Комментарий недоступен
Да, рисунок забавный, но то что на нем изображено вполне серьезно и важно:) Можно нагуглить массу более формальных описаний и историю этого фреймворка.
"ПО для веба" может представлять собой баннер, а может систему управления логистикой глобальной корпорации. Комплексность этих задач отличается на много порядков. Соответственно и подходы для их решения надо выбирать разные. Не могу дать конкретных советов или ответов не понимая о каких задачах и каком процессе их реализации идет речь:)
Если у вас получается реализовывать ваши задачи в рамках достаточно строгого процесса то, вероятно, действительно имеет смысл подумать о стандартизации подхода к описанию требований чтобы делать это быстрее и с более предсказуемым качеством.
С вероятностью 99% все что мы придумываем - уже придумано до нас. Имеет смысл инвестировать какое-то время в то чтобы изучать чужой опыт и подходы, отраженные в "трудах":) Это может сильно сэкономить время и повысить уровень компетенции.
Комментарий недоступен
ГОСТ 34 у нас из стандартнов, но он старенький
Я бы еще такой совет добавил — если вам предоставили подробную смету по вашему толстенному ТЗ, то давайте обратную связь и не "теряйтесь". Даже если итоговые цифры вас не устроили, уважайте затраченное поставщиком время на оценку.
Вот да. Мы с какого-то момента очень скептичны к такого рода расчетам. Ой, спасибо, что подсветили риски. Такой замечательный документ вы сделали. Мы, пожалуй, будем туда подглядывать, когда будем нажимать на «ООО Рога и копыта, с которыми мы решили делать проект». Ничего личного, просто они дали сроки и стоимость значительно ниже вашей. Оценки у них нет, они просто угадывали, но у вас то есть. Вот на ваши сроки мы и будем ориентироваться. А драть подрядчика будем по их обещалась. Большое спасибо за участие в нашем тендере, коллеги. Было, так сказать, очень продуктивно.
Вся статья сводится к тому, что заказчику нужно определиться с бизнес-целями, а компания-разраб все сделает сама.;)
Но так не бывает. И подробное тз служит защитой заказчика в том, что он прописывает свои бизнес-цели так, как видит он, а не компания разраб.
И тут в игру вступает проджект/продакт (не важно на чьей стороне), который всех должен подружить.
Зы не стоит делать заказчика козлом отпущения - таки он платит деньги и может за них требовать хоть разработчиков-стриптизерш.))))
И заказчик и подрядчик птицы вольные и могут желать чего угодно. Но есть более продуктивные пути сотрудничества, а есть менее. К сожалению, детальное ТЗ часто не защищает клиента от риска "получить не то что нужно", а иногда еще и усиливает его (потому что подрядчик тоже будет думать не над тем, что нужно, а над тем чтобы соответствовать написанному в ТЗ).
"заказчику нужно определиться с бизнес-целями, а компания-разраб все сделает сама" - представьте, так бывает:) Если каждая из сторон грамотно сделала свою работу: заказчик не вываливал необоснованные фантазии или личные мотивы вместо бизнес-целей, а подрядчик имел достаточную компетенцию чтобы их понять и превратить в правильные функциональные требования и приоритеты.
Вообще по толстенному ТЗ оценка вполне может быть точной. Другой вопрос, что это надо уметь оценивать (большинство не умеет), оценка может оказаться значительно выше ожиданий и занять примерно вечность. Ещё интересный вопрос - кто писал этот документ? Чтобы составить грамотное толстенное тз нужно минимум два-три человека с разной специализацией. Подробные портянки может писать и штат аналитиков. Почему эта компания сама не разрабатывает продукт, если они такие молодцы в спецификации?
Пока читал статью, сбоку слышал какой-то голос. Он саркастически комментировал ))
"Не пишите подробное ТЗ. Нам ведь придется много читать, много считать, много думать, мы боимся ошибиться с оценкой. Мы чувствуем себя некомфортно без неопределенности, за счет которой можно потом выезжать."
"Не описывайте детали подробно. Вдруг мы этого не умеем, нам будет трудно убедить вас в том, что вам нужно другое (вон тот плугин к битриксу, мы его уже умеем, а заодно и на битрикс переедем)."
"Не используйте UML, BPML и прочую шнягу. Вы видели на рынке специалистов, которые в них умеют? А действительно умеют? А сколько они стоят?"
"Не рисуйте интерфейс. Ведь тогда мы не сможем применить наш любимый фрамеворк или куски из прошлых проектов."
Впрочем, статья справедлива для плохого(!) и "подробного" (запутанного) ТЗ.
Если честно, не вижу никаких минусов в продуманном и подробном техзадании. Оно совсем не обязательно становится догмой, его тоже можно менять и корректировать. Но вот в качестве устойчивой платформы для разработки оно подходит гораздо лучше, чем "давайте балабонькать про бузинесс-цели".
Ну, это немного передергивание:)
Статья про то, что "не надо считать что чем подробнее тем лучше". Разумеется, это не равно утверждению "чем меньше, тем лучше". Что-то действительно может требовать подробного и грамотного описания. Например, специфика предметной области, не доступная на уровне здравого смысла (или контринтуитивная).
Кстати, обычно, большинство людей чувствуют себя комфортнее как раз в определенности. И выезжают за счет того что "дык у вас в ТЗ так написано. А чего не написано - того нет". Неопределенность сложнее для обоих сторон и требует грамотной работы с ней. Но маскировка неопределенности фантазиями и глупостями (читай "плохо написанное ТЗ") - хуже чем "явная" неопределенность.
Без ТЗ результат ХЗ.
Если ТЗ или ЧТЗ подробно не зафиксированы, в том числе дизайном и нюансами поведения, то и критерии выполнения задания становятся размытыми. Это чревато затягиваниями и доработками на этапе приемки.
Зависит от уровня исполнителя. Кому-то вообще никакая спецификация не поможет: они все проигнорируют и сделают через жопу. А кто-то и по брифу прекрасно справится. Вы правы в том, что приемочные критерии должны быть определены четко. Но «четко» не обязательно «длинно» и «супер-подробно. На персом месте должен быть все-таки вопрос «что», а не «как».
Не могу согласиться с этим утверждением как с догмой:)
Многие прекрасные продукты разрабатываются без ТЗ или по очень высокоуровневым требованиям/целям (BRD, например). Никого уже не удивить гибкими процессами разработки, основанными на обратной связи от потребителей, результатах тестирования гипотез и т.п.
Да, если нет детальных требований то нельзя утверждать что-либо о соответствии продукта этим требованиям. Но это зачастую не нужно. Заказчику, заинтересованному в продукте, важно получить от этого продукта пользу для бизнеса (а может для себя лично или каких-то других стейкхолдеров).
Важно очень четко и прозрачно понимать кому и какую пользу должен принести продукт, а также иметь достаточные компетенцию и кругозор чтобы предложить оптимальный способ создания этой пользы. В таком случае, какой бы ни был результат, если он достигает цели - все будут довольны.
Это, конечно же, тоже не догма. Бывает, что детальное описание требований и сверхстрогая приемка необходимы для обеспечения высокого уровня надежности или безопасности. Но статья, с учетом уровня погружения, скорее про более простые случаи, где риск измеряется в относительно небольших суммах денег, и не грозит жизни и здоровью людей, например.
А есть ли /должен ли быть какой-то проектный документ, который содержит исчерпывающее описание итогового проекта? Если - да, то когда он появляется и кто его готовит?
Как вариант «живая спецификация», описанная Гойко Аджичем
Ну, есть такой вариант ответа: исчерпывающее описание содержит код:) Если этот код хорошо структурирован, читаем, не содержит лишнего то он является максимально приближенным к реальности описанием того, как программа будет выполняться на процессоре.
Постановка задачи и описание результата ее выполнения - это очень разные вещи, которые описываются по-разному. К сожалению, часто их путают и считают, что ТЗ "описывает" разработанный продукт.
Конечно постановка задачи и описание результата это разные вещи. Поэтому обычно есть некая документация на входе (называйте как хотите: ФТ/ТТ/ТЗ), до заключения договора, в которую, так же как и договор, обе стороны в рамках своих компетенций могут вносить и согласовывать правки. А уже после заключения договорных обязательств, исполнитель в рамках проектирования детально описывает как будет реализовывать проект, уже как "профи", который умеет писать ТЗ/ЧТЗ, хоть одним куском за раз, хоть итерационно под спринты (зависит от методологии и условий договора).
А исполнитель, который жалуется на избыточные входные данные, которые не может проанализировать и "причесать" на этапе пресейла, а на выходе выдающий вместо нормально документации "хорошо структурированный код", думаю, достоин продолжать жрать кактус.
Что бы вам дома так строили, без всей проектной документации, главное, что бы кирпичи хорошо структурировано уложены были.