Идеальное ТЗ для разработчика

Требования к идеальному ТЗ

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

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

• Идеальное ТЗ – это ТЗ, время выполнения которого укладывается в заданные рамки, установленные на этапе обсуждения.

• Идеальное ТЗ – это ТЗ, после выполнения которого не требуется дополнительная модификация продукта.

• И, наконец, идеальное ТЗ – это когда план сходится с фактом, то есть ожидания всех участников сходятся с реализацией.

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

Обоснование требований и метод «пять почему»

По моему мнению, требования должны иметь обоснование.

Что это значит? Разберем на конкретном примере. Как-то я работал с небольшим франчем, у которого не было аналитика в штате, и задачи, и потребности собирали директор и его бизнес-партнер-разработчик.

И вот они приходят с требованием на разработку, которое звучит примерно так: «Нужно разработать отчет по премиям для менеджеров по продажам, вот тебе Excel с формулами».

То есть техническое задание не особо большое, никаких нюансов нет. Результат выполнения задачи был такой же, как и ТЗ, – не очень.

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

Чем это закончилось? Техническое задание мы выполнили, отчет сдали, но через год заказчик решил перейти на Комплексную автоматизацию 2 и попросил сделать это снова.

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

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

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

Что можно было сделать, по моему мнению? На тот момент я, конечно, этого не знал, но сейчас предложил бы использовать метод «пять почему».

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

Давайте разберем на этом примере.

У нас есть потребность – разработка отчета по премиям менеджеров по продажам. Задаем первый вопрос: почему? Бизнес отвечает: «Нам хотелось бы автоматизировать расчет премий».

Почему мы хотим автоматизировать расчет премий? «Потому что количество сотрудников растет, а считать все премии становится неудобно».

Почему их становится неудобно считать? «Потому что у нас гибкая система мотивации, которая зависит от количества проданного товара из различных товарных групп». То есть мы видим, что бизнес растет, количество сотрудников растет, количество товарных групп и ассортимент растут.

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

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

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

Конкретика формулировок и метод SMART

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

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

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

Плюсы и минусы этого подхода очевидны.

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

Из плюсов – проработанное техническое задание, по которому нет никаких претензий от бизнеса.

Как же сделать так, чтобы даже дотошный Петя сразу получил все ответы на свои вопросы?

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

Первая буква означает «конкретный». То есть задача должна быть сформулирована четко, без двусмысленности. Это значит, что ее цель должна быть сформулирована так, чтобы каждый понимал ее одинаково.

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

Задача должна быть достижимой, то есть ее цель должна быть реалистичной и выполнимой с учетом доступных ресурсов.

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

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

Давайте разберемся на примерах, потому что это самый лучший способ понять.
 

Например, разработчику приходит требование: «Проведение документа должно быть быстрым».

У разработчика сразу возникают вопросы: насколько быстрым? Какие критерии? Что это значит?

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

Или другой пример: «Документы должны выгружаться, если они отправлены в банк».

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

Единый контекст команды и глоссарий

Следующее, что я выделяю, – это одинаковый контекст.

Здесь истории в пример не будет. Хотя на самом деле такая история есть у всех.

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

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

Что происходит по факту? Разработчик понял и сделал по-своему, а аналитик ожидал другого и описал свои ожидания в техническом задании. Тестировщик понял все точно так же, как аналитик. А мог понять и вообще по-третьему – тогда история была бы еще интереснее.

Почему разработчик не уточнил? Почему он не синхронизировался с аналитиком по своему мнению по поводу выполнения? Почему так вообще произошло?

Люди бывают разные. Некоторые боятся показаться некомпетентными, некоторые считают, что они все знают, а кто-то просто не любит общаться.

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

Пример глоссария именно технических терминов, бизнесовых терминов и описания того, что может быть: самое простое – это термин, определение и пример использования.

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

У нас есть такая. Это и «приседать», и описание нашего флоу, и описание тикетов, то есть задач в нашем Task-менеджере.
 

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

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

Что туда вносить? Как я сказал ранее, термины бизнес-процессов и терминологию, которая используется в команде.

Визуализация: схемы и макеты вместо текста

Последнее, про что я хотел рассказать, – это визуализация вместо тысячи слов. Я считаю это очень классной штукой.

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

Но я хотел бы поделиться своей историей о том, как я полюбил именно схемы.

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

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

Пока я делал схему, я нашел несколько тонких моментов, которые создали бы проблемы при дальнейшей эксплуатации. Впоследствии я их исправил, используя опять же схему. Я взял процесс as is, сделал to be, посмотрел, какие есть отличия, погонял кейсы, которые были у меня в голове, именно на решение этой проблемы. У меня все сошлось, и только после этого я приступил к кодированию, сделал все и отдал на сопровождение вместе с измененной подсистемой.

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

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

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

Но если ее взять и засунуть в какую-нибудь нейросеть типа DeepSeek, она выдает описание схемы на 325 слов. Это примерно три листа А4 двенадцатым шрифтом. То есть при использовании схем и текстов разница достаточно большая.
 

Что вообще дает визуализация? Я должен заметить, что визуализация – это не только схемы, но и макеты интерфейсов.

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

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

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

Также это можно показать бизнесу, и бизнес скажет, устраивает его это или нет.

Коммуникация с исполнителями и регулярные встречи

Давайте сделаем выводы из вышесказанного.

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

Что же мы ожидаем от исполнителя в конце? Вот предполагаемый результат:

А вот фактический:
 

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

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

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

Если бы дизайнер не была нашей подругой, эту историю мы бы никогда не узнали.

А соль истории заключалась в том, что по проекту у нас в спальне должен был быть проектор, который стоит над изголовьем кровати на высоте 1,8 метра. Нестандартное решение.

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

Для нас история закончилась хорошо. Бригадир увидел это, поговорил с коллегой и вразумил его. Он объяснил, зачем это нужно и для чего пятью минутами ранее этот же электрик монтировал провода, которые находятся на потолке.
 

Вот эта розетка, про которую я говорил.

К чему это я? Что самое важное в этой истории и какие выводы я сделал для себя?

Основной проблемой был недостаток коммуникации. Электрик не задал никаких вопросов вообще. Он пошел делать работу, используя схемы и документацию, которая у него была. Сразу взялся делать, а потом и вовсе решил, что документация для него не важна и он знает, как лучше сделать. То есть он пренебрег потребностями бизнес-заказчика и сделал, опираясь на свой непосредственный опыт, хотя до этого была проведена масштабная работа аналитиком – в нашем случае дизайнером. Были даже сметы, схемы и картинки с визуализацией.

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

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

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

Но самое худшее – когда некоторые молча делают, потому что считают, что знают, как лучше для бизнеса.

Давайте попробуем разобраться, о какой коммуникации я говорю.

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

Давайте посмотрим, на какие встречи лучше звать разработчика.

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

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

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

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

Итоги

Давайте подведем итоги.
 

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

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

Оно должно содержать конкретные формулировки.

Команда должна находиться в одном контексте с аналитиками и с тестировщиками, если они у вас есть.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.