Техническое задание - если говорить простым языком, это перечень пожеланий заказчика, обернутый в более или менее понятную оболочку. Бывают случаи, когда клиент совсем не знает, что он хочет, но хочет. В этом случае, обычно, он высказывает общие пожелания в свободной форме - и далее отдаёт работу на усмотрение заказчика. А бывает наоборот - клиент отлично знает что он хочет, разбивает информацию на блоки, даёт ссылки на информацию для создания уникального текста, или на источники для его рерайта, чётко, или более или менее чётко определяет структуру и порядок блоков.
Рассмотрим оба варианта:
Пример №1: ТЗ в виде неструктурированного потока сознания
Я хочу продать собственную книгу по кулинарии! В ней я собрал авторские рецепты со всего мира и добавил собственные фишки! Хочу, чтобы клиенты заходили на сайт и понимали, какие-же классные там рецепты - и что они обязательно должно её купить/заказать. Вот тут все картинки из книги, а тут тексты. Сделайте, чтобы прям было очень красиво и сочно. Желательно в тёмной гамме.
_____________
Конечно, такой вариант ТЗ не оптимален. Из чётких пожеланий, здесь только пожелание по цветовой гамме. Однако, клиент не обязан знать что такое триггеры, как устроен ленд, что такое лид-формы, подогревающие блоки, закрывающие блоки и так далее.
В этом случае, проект делается на наше усмотрение. А клиент должен находится на связи и отвечать на возникающие вопросы. Ничего плохого в этом нет. Но если после его презентации клиент говорит: А я вообще не так хотел! То, нужно быть готовым к тому, что переделывать его бесплатно никто не будет. Потому что, как именно вы хотели - никто не знает.
Встречаем такие ответы мы редко. Прежде всего потому, что клиент видит прототип до стадии дизайна и согласовывает его, ну и просто потому, что мы не делаем плохие проекты. Однако, это нужно иметь ввиду.
Пример №2: Структурированное полноценное ТЗ
Требуется лендовая страница на 4-5 экранов. Продукт - книга с авторскими рецептами со всего мира. Особенность - все рецепты дополнены и улучшены личными фишками.
1-ый экран: красивый мокап обложки книги в половину экрана. Где-то рядом слоган и моя фотография. Большая кнопка заказать оформленная в виде грилля.
2-ой экран: пример трёх самых ярких блюд с кратким описанием и вкусовыми особенностями. 1-ое блюдо (картинка, текст) 2-ое блюда (картинка, текст), 3-е блюдо (картинка, текст)
3-ий экран: рассказать о том, что для приготовления большинства блюд не требуется сложные и дорогие ингридиенты, или сложная профессиональная кухонная техника. Всё можно приготовать дома, сходив в ближайший магазин. Показать это наиболее просто и коротко, с использованием иконок или другой визуализации.
4-ый экран: об авторе. вот небольшой текст обо мне (держите текст). Его можно дополнить моими фотографиями с путешествиями, где я общаюсь с разными шеф-поворами мира (держите фотографии).
5-ый экран: 2-3 фотографии из книги. И специальное предложение при покупке до сентября - скидка 20% в ресторан партнёрской сети. Кнопка заказать также, как в 1-ом экране.
Детали: в поп-апе, просьба разместить информацию, которая расскажет про детали доставки и получения книги. Дать возможность выбрать самовывоз или доставку (цена такая-то, цена такая-то). После этого человек переходит на страницу оплаты в банк.
Дополнительно: сайты, которые нравятся:
www.agaev.digital
www.сайт.ру
www.сайт2.ру
В оформлении желателен максимальный контраст, фиолетовая или синяя гамма цветов.
______________________________________________________
Это простой и максимально сокращенный пример структурированного ТЗ. Заказчик может предоставлять свои тексты, ссылки и многое другое - самое главное, чтобы весь этот текст соответствовал тому, чем он является - техническому заданию. То есть четкому перечню пожеланий, изложенных в понятной форме.
Как делать не надо
К сожалению, иногда мы сталкиваемся с достаточно объемными ТЗ, которые не несут никакой смысловой нагрузки.
Пример №3: невнятное тз - результат хз
Нужен сайт - чтобы показать, что у нас самая лучшая книга с рецептами в России.
На первый экран - книгу, а хотя, может лучше и не книгу - а меня, автора. С книгой в руке. Чтобы создалось впечатление серьёзности.
Важно, чтобы было лучше, чем у конкурентов. Чтобы клиент сразу понял - что эта книга отличается от всех остальных в мире, и что в ней то, что ему нужно - лучшие рецепты.
Во 2-ом и 3-ем экране нужно разместить мою экспертность в сфере кулинарии, чтобы было понятно - что я не просто доморощенный повар, а настоящий профессионал, который смог собрать лучшие рецепты.
4-ый экран - тут нужно написать про то, что таких рецептов больше нигде нет. Ни в интернете, ни вообще где-либо ещё. То есть человек должен на этом экране захотеть купить книгу, понять, что она написано профи.
5-ый экран: фотогалерея с лучшими блюдами и призывом к покупке книги. Призыв должен быть простым, но при этом содержательным.
________________________________________________
Понятно, что ленд - это и есть страница, которая должна показать преимущества вашего продукта. В частности на фоне конкурентов. Но набор пожеланий в духе “показать, что мы лучше”, “чтобы клиент понял, что мы серьёзнее” “увидел, что мы эксперты” “понял, что это то, что ему нужно прямо сейчас” - отношения к техническому заданию имеет мало.
Лучше конкурентов вас делает ваш продукт - а лучше чем вы, ваш продукт не знает никто. Поэтому, если вы хотите, чтобы он был лучше - то должны по пунктам рассказать, чем он лучше. Если же он не лучше - нужно попробовать найти оригинальный подход к привлечению внимания. Использовать провокацию, юмор, креатив. Но понять, что нужно делать по такому ТЗ - невозможно. Скорее всего, мы будем работать по схеме №1, у нас просто не будет выбора, и очень велик риск, что мы услышим: “Но я же не это имел ввиду под экспертностью!”.
Но мы-то откуда это знаем?
Пишите правильное ТЗ. Оно сэкономит время как нам, так и вам. А главное - позволит получить качественный результат, а не ХЗ.
Комментарии (16)
nikitaGlobal
31.07.2021 20:10+1ТЗ - это хорошо, но на всякого мудреца довольно простоты
"Это свинство - прикрываясь ТЗ, отказываться признавать мою правоту"
"Да, я принял ТЗ, но не говорил, что принимаю пункт 5.4, а значит он недействителен"
(про оплату разработки ТЗ) "Почему я должен платить за то что нужно вам?"
(про то же) - я бы хотел как в ИКЕЕ - пришел и купил. Без всяких ТЗ.
aleks_pingvin
31.07.2021 20:47Главное во время разработки чего-либо (не только сайта) - думать, что из не сказанного и не указанного в ТЗ может потенциально понадобится Заказчику и своевременно уточнять необходимость и предлагать. Конечно, для этого надо быть в контексте предметной области, но это уже другой вопрос. Ну и проектировать решение так, что бы оно было пригодно для расширения и наращивания функционала. В таком случае, "поток сознания" постепенно начнет превращаться в то, что устроит и Вас как Исполнителя и Заказчика, который поймет, что ему действительно хотят оказать услугу, которая решит его задачу и который захочет снова и снова с Вами сотрудничать.
sibmax
31.07.2021 21:33+1Скажите точно, по пунктам, что мне делать.
И я вам сделаю это за 100500 денег.
Это про второй вариант ТЗ.
Если этот вариант кто-то способен сделать,
то тем паче - он способен нанять соответствующих спецов.
И дополнительно платить "конторе" за это смысла не видит априори.
ТЗ "по полочкам" - результат овернепростой задачи чаще всего.
Решить которую 80-90% заказчиков не способны априори.
Поэтому заработок конторы часто - это перевести
"поток сознания" в "то самое ТЗ".
И слупить основное бабло
именно за это. Имхо.
Lofer
31.07.2021 22:29+2А давайте для начала будем различать:
Business Requirements Specification (BRS) describing business or mission requirements,
System Operational Concept (OpsCon) describing stakeholder needs,
Stakeholder Requirements Specification (StRS) describing stakeholder requirements,
System Requirements Specification (SyRS) describing system requirements,
Software Requirements Specification (SRS) describing software requirements.
и уже потом любое "хочу" называть "техническое задание" ? вроде есть "ISO/IEC/ IEEE 29148-2011 \ ISO/IEC/IEEE 29148:2018 " для составления ТЗ.
Стандарты и шаблоны для ТЗ на разработку ПО: https://habr.com/ru/post/328822
surVrus
01.08.2021 14:37Совершенно верно! Все уже давно и много раз разжевано, отработано на уровне стандартов и документов, применяется более 40 лет. Но нет, снова вылезают какие-то кривуляки с названием "ТЗ", как их не надо писать, и что это такое.
Учим матчасть, ибо управление требованиями к ПО - это только один из множества процессов, которые обязательны при разработке ПО,
SpiderEkb
31.07.2021 23:13+1перечень пожеланий заказчика, обернутый в более или менее понятную оболочку
Это не ТЗ. Это называется BRD - Business Requirements Document
Есть специально обученные люди (системные аналитики), которые на основе BRD составляют FSD - Functional Specifications Document Вот его уже можно рассматривать как техзадание для разработчика.
И если все сделано правильно, то икать не придется.
zorn_v
02.08.2021 23:10Есть специально обученные люди (системные аналитики), которые на основе BRD составляют FSD
А есть реальный заказчик, который ASD и QWE. И тебе не BSD как ему составить ZXC.
Pyhesty
01.08.2021 09:19ГОСТ 15.016-2016
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Система разработки и постановки продукции на производство
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
pavel_raskin
01.08.2021 11:12Тогда уж ГОСТ 19.201-78 или ГОСТ 34.602-89, а Ваша ссылка на 15.016 немного не в тему:
Настоящий стандарт устанавливает требования к построению, содержанию, изложению, оформлению, порядку согласования и утверждения технического задания на выполнение научно-исследовательских и опытно-конструкторских работ в области изделий машиностроения и приборостроения.
Ну и мало кто поспорит, что стандартизация штука отличная. Вот только в стандартах на ТЗ обычно сказано о чём писать, но почти ни слова о том как писать, с чем у многих по началу проблемы и случаются.
doom3quake4
06.08.2021 13:12Нет, ну можно конечно умничать, посылать в (потенциального) клиента ссылками и доками как писать истинноправильные ТЗ... и остаться без клиента! А можно на этапе переговоров вместе с клиентом, понятное и клиенту и команде, это самое ТЗ составить и утвердить. Всегда есть две стороны. Если бы клиент мог сформулировать полностью все-все-все, то именно студия ему скорее всего и не нужна была бы. Мог бы заказать просто набор компонентов и самостоятельно их сложить в готовый продукт.
zorn_v
Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы... И эльфу раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подходиш они преобразовываются в 3-хмерные деревья. Можно покупать и т.п. возможности как в Daggerfall. И враги 3-хмерные тоже, и труп тоже 3д. Можно прыгать и т.п. Если играть за охрану дворца то надо слушаться командира, и защищать дворец от злого (имя я не придумал) и шпионов, партизанов эльфов, и ходит на набеги на когото из этих (эльфов, злого…). Ну а если за злого… то значит шпионы или партизаны эльфов иногда нападают, пользователь сам себе командир может делать что сам захочет прикажет своим войскам с ним самим напасть на дворец и пойдет в атаку. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона людей (нейтрал), 2- зона императора (где дворец), 3-зона эльфов, 4 - зона злого… (в горах, там есть старый форт…)
Так же чтобы в игре могли не только убить но и отрубить руку и если пользователя не вылечат то он умрет, так же выколоть глаз но пользователь может не умереть а просто пол экрана не видеть, или достать или купить протез, если ногу тоже либо умреш либо будеш ползать либо на коляске котаться, или самое хорошее… поставить протез. Сохранятся можно…
P.S. Я джва года хочу такую игру.
vsviridov
Кстати, на Kenshi похоже по описанию.
don_ikar
Это же классика...
vsviridov
Это то понятно, мем древний, как гном и шар свиборга....
Просто недавно играл в Kenshi и многое подходит под тз автора.