Как сделать простое техническое задание и не потерять деньги и нервы

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку Техническое задание не должно быть жадным. Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы? Техническое задание должно быть реалистичным и выполнимымНапример, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое. Техническое задание должно быть подробным.например, расчёт дилерских бонусовДа, корпоративный софт выглядит примерно так, и в нём много важных мелочей Техническое задание должно быть однозначным и точным.благими намерениями устлана дорога в адВ этом году ты можешь снова загадать одно желание. Только, прошу, не трать его на то, что даже я не смогу выполнить, типа понятных бизнес-требований! Техническое задание должно быть написано на человеческом языке.

1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.

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

Альтернативное техническое задание

Итак, хорошее техническое задание:

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

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

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

Так вот. Техническое задание — это постановка задачи в таком виде, чтобы СРЕДНИЙ специалист по программированию или дизайну сразу без лишних вопросов смог приступить и выполнить ее. То есть не надо туда писать бизнес-стратегии. Не надо зауми. Не надо ориентации на карманных оракулов.

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

Еще. ТЗ нифига не защищают разработчика, особенно письменные. Попробуйте более-менее конкретно расписать какой-то сайт. Если клиент захочет, он сможет ЛЮБОЙ пункт интерпретировать по другому, или считать какие-то «допфункционалы» с точки зрения разработчика дефолтными. То есть он сможет при желании оспаривать любой пункт и приводить какие-либо доводы, о том, что «он думал что будет так», или что «так есть у всех», или что «так принято в моей отрасли», или что-то еще.

Я думаю, никакого способа побороть это на уровне формализации ТЗ нет. Нужно отстраивать отношения с клиентом, понимать его потребности, говорить с ним ГОЛОСОМ, а процесс работы сделать максимально интерактивным.

Люди быстрее понимают картинки и наглядное представление — поэтому рулят прототипы. Однако описать технические аспекты и механику работы web-приложений на прототипах до конца нельзя, поэтому текстовые ТЗ/постановки/диаграммы так же нужны. Это не обязательно должны быть отдельные документы. Иногда достаточно презентации в PowerPoint, иногда — даже просто комментариев к прототипу.

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

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

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

Еще раз об экономии времени. Разработка прототипа и ТЗ к нему обычно съедает 12% бюджета проекта. На первый взгляд — много. (И это реально много!) Но она не более трудозатратна, чем создание традиционного технического задания на разработку сайта. К тому же она прогнозируема по срокам, и позволяет избежать гораздо большего вылезания из сроков и бюджета.

В маленьких проектах жопа проблема в разработке хорошего технического задания еще и в том, что его нужно готовить до того, как будет готов договор. А на это жалко времени, так как есть риск, что договор в итоге не будет подписан. Но тут нет каких-то вариантов. Или вы разрабатываете ТЗ за отдельную плату (но тогда это нужно суметь продать и обеспечить качество выполнения), или вы делаете это «бесплатно» (в этом случае имеете риски по написанию ТЗ задаром). Лично я — за проработанные платные ТЗ, и многие адекватные клиенты на это идут с удовольствием.

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

Что такое техническое задание на проектирование

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

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

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

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

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

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

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

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

ГОСТ 19 для Технического задания

Техническое задание по ГОСТу 19 должно содержать следующие разделы:

1. введение;
2. основания для разработки;
3. назначение разработки;
4. требования к программе или программному изделию;
5. требования к программной документации;
6. технико-экономические показатели;
7. стадии и этапы разработки;
8. порядок контроля и приёмки.

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

В разделе 1 «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

В разделе 2 «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведётся разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

В разделе 3 «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Раздел 4 «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

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

В подразделе 4.2 «Требования к надёжности» должны быть указаны требования к обеспечению надёжного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

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

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

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

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

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

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

В разделе 7 «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

В приложениях к техническому заданию, при необходимости, приводят:

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

ТЗ для сайта — важные моменты

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

Детальное описание сущностей

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

1. Вы создаёте сайт-визитку, состоящий исключительно из нескольких страниц. В этом случае, сущностью будет «Страница», у каждой из которых есть свой заголовок, содержимое и другие опции.
2. Если вы захотите добавить на свой сайт раздел с новостями, то «Новость» будет новой сущностью. Помимо заголовка и содержимого эти материалы могут иметь, например, дату публикации или автора.
3. Кстати, «Автор» также является сущностью — у каждого из них может быть уникальная фотография и имя. В этом случае, сущности могут быть связаны друг с другом, как новость и её автор.

Узнать больше о проекте

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

Функциональные особенности

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

Что дает сторонам каждый раздел ТЗ:

Технологически не связанные товары

Иногда заказчик в один лот включает технологически и функционально не связанные между собой товары. За такие действия ему грозит штраф от 10 000 до 50 000 рублей.

Так, например, ФАС считает недопустимым обслуживание и уборку объектов, которые расположены в разных муниципальных образованиях. Суть в том, что большинство компаний в состоянии побороться за заказ на отдельном участке. Если же в одну закупку включаются удаленные друг от друга объекты, то многим компаниям не хватает мощности перебросить машины и людей в разные части региона. Либо это будет невыгодно. Поэтому такие заказы забирает нужная организация по максимальной цене.

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

Распространенные нарушения при составлении ТЗ

Использование неточных формулировок

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

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

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

Нарушения, связанные с ГОСТами

Очень часто происходит путаница с разного рода характеристиками, которые заказчики берут из ГОСТов. Зачастую оттуда переписывается все подряд. В результате в техническом задании присутствуют взаимоисключающие характеристики. Понятно, что объекта, соответствующего им, в природе быть не может. Проявляя такую некомпетентность, заказчик нарушает часть 2 статьи 33 закона 44-ФЗ.

Нередко заказчики просто перечисляют в ТЗ номера ГОСТов, при этом не указывая, к каким объектам они относятся. ФАС считает, что это мешает поставщику составить заявку правильно, ведь подобное описание не позволяет идентифицировать товар.

Отсутствие упоминания об эквиваленте

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

Советы специалистов

Грамотно составленное ТЗ отсекает заведомо неподходящее товары, избавляет от необходимости отвечать на множество запросов о разъяснении и, вообще, лишает заказчика массы проблем. И главное тут — внимательно изучить требования к объектам закупки, оценить свои потребности и строго следовать правилам закона 44-ФЗ Маститые специалисты дают своим коллегам некоторые советы, о которых расскажем далее.

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

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

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

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

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

О чем еще не следует забывать:

• объекты закупки указывайте в соответствии с классификатором ОКПД2;
• изучите нормативные документы и стандарты, в которых содержатся требования к объекту закупки (ГОСТ, СНиП, ТУ);
• при наличии сметной документации следите за тем, чтобы в ТЗ содержались соответствующие ей объекты закупки;
• обязательно укажите в требованиях, что товар должен быть новым, иначе рискуете приобрести бывший в употреблении, отремонтированный, отреставрированный товар;
• если закупаете выполнение строительных работ, капремонта, реконструкции, не забудьте приложить смету и проектную документацию.

Распространенные вопросы

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

Вопрос: Обязательно ли прописывать идентификационный код закупки в техническое задание?Ответ: Идентификационный код закупки указывается в плане закупок, плане-графике, извещении об осуществлении закупки, приглашении принять участие в определении поставщика (подрядчика, исполнителя), осуществляемом закрытым способом, документации о закупке, в контракте, а также в иных документах, предусмотренных настоящим Федеральным законом. В ТЗ его указывать не обязательно.

Вопрос: Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен. Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.Ответ: Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) – можно, в других случаях — нельзя.

Обучение по 44-ФЗ, 223-ФЗ

Повышение квалификации и профпереподготовка в Контур.Школе
Подробнее о курсах

Вопрос: Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?Ответ: При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». 

Пример описания прототипа одной из страниц сайта

1. Подчеркиваем, что это монобрендовый магазин с ценами фабрики.
2. Контакты выносим в отдельный блок, т.к. по статистике предыдущего сайта пункт был одним из наиболее кликабельных. Показываем режим работы, чтобы снизить число пропущенных звонков. Корзину смещаем наверх, чтобы не мешать ссылку на контакты и телефон с данными о товарах.
3. По статистике сайта поиском пользуются активно, в том числе и менеджеры при поиске по артикулам.
4. Основное меню имеет смысл сделать выпадающим, т.к. учитывая количество вложенных разделов, вертикальное меню может стать «портянкой».
5. Для слайдера нужно предусмотреть сортировку. В правой части слайдера размещаем блок, отображающий число слайдов.
6. Онлайн-консультант – всплывающее окно по клику
7. Сквозной блок о доп. услугах. Информация для покупателя, чтобы ее можно было получить на любой странице.
8. Текст, раскрывающий преимущества магазина и мебели, и одновременно описывающий страницу для поисковиков.
9. Просмотренные ранее товары. Если посетитель впервые на сайте, показываем популярные товары.
10. Блок футера: адрес, телефоны, дублирующее меню.

Заключение

Разработка и управление требованиями к ПОпример ТЗ, который я писал много лет назад

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»

Итого

Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.

Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.

И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.

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

Основные тезисы:

• Заказчик пишет ТЗ, оно может быть коротким, на салфетке из кафе, и содержать 3-4 пункты ключевых требований
• ТР — пишет Разработчик, оно может быть длинным, его цель сформулировать, согласовать и зафиксировать задание и предлагаемое решение.
• Только пара из ТЗ и ТР позволяет получить взаимопонимание между Заказчиком и Разработчиком.
• Иногда можно отказаться от ТР, но надо хорошо понимать когда это можно делать и последствия