Данный текст создан исключительно ради существования постоянной ссылки, которую сам автор, да и все вы, могли бы спокойно разослать своим будущим клиентам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «Нужны ли мне ваши технические характеристики и что вообщеЭ» Этот?" Как говорится - «вместо тысячи слов», так как каждый раз евангелизировать по 4-5 часов в скайпе на эту тему уже становится утомительно, а мировая тенденция подсовывать откровенную чушь в определение «Техническое задание» только усиливается.
на протяжении многих лет. 
Проблема
Дело в том, что когда есть конкретный формат, а также четкое и доходчивое определение термина, то все манипуляции и подмены его собственными брифами, прототипами, придуманными на лету анкетами, описаниями и просто входящими заявками выглядят как минимум непрофессионально.Поэтому начнем с научного определения нашего понятия:
Техническое задание – оригинал документа на проектирование технического объекта (изделия).В техническом задании устанавливаются основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, указания по выполнению необходимых этапов создания документации (проектной, технологической, программной и т.п.
) и ее состав, а также как особые требования.
Техническое задание является юридическим документом – как приложение оно включается в договор между заказчиком и подрядчиком на выполнение проектных работ и является его основой: определяет порядок и условия проведения работ, в том числе цель, задачи, принципы.
, ожидаемые результаты и сроки.
То есть должны быть объективные критерии, по которым можно определить, выполнен тот или иной элемент работы или нет. Все изменения, дополнения и уточнения формулировок технического задания должны быть согласованы с заказчиком и утверждены им.
Это необходимо еще и потому, что при обнаружении неточностей или ошибок в исходных данных в процессе решения проектной задачи возникает необходимость определения степени вины каждой из сторон, участвовавших в разработке, и распределения убытков, понесенных в связи с этим.
с этим.
Техническое задание, как термин в сфере информационных технологий, — юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям по разработке, внедрению или интеграции программного продукта, информационной системы, сайта, портала или иной ИТ-услуги.
.
Перевод на понятный язык
1) Техническое задание – оно ставит задачу.Это значит, что оно должно предшествовать прототипу, эскизу, тесту, дизайн-проекту, потому что любая майндмап, диаграмма потоков данных, архитектура — это уже выполнение определенной задачи, это ответ на вопрос.
И пока сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами, любой ответ будет априори неверным, не так ли? Итак, начало любой работы над любым проектом – это постановка задачи, а не бешеный поиск набросков десятка вариантов ее решения.
2) Собственно, из первого пункта логически вытекает новое - текст самого ТЗ должен начинаться с главы "Цели и задачи", в которой четко сформулировано, какие бизнес-цели преследует эта последняя попытка повысить энтропию в мире.
.
Бесцельная задача, не решающая никаких задач, ничего не достигающая и выполняемая «от скуки», официально не считается Техническим заданием и отныне находится в статусе «обычной бумажки».
3) Как понять, решает ли предложенная дизайн-концепция, интерактивный прототип или даже готовый сайт вышеуказанную бизнес-задачу? Ничего не поделаешь, придется снова вернуться к определению: «определяет… ожидаемые результаты и сроки».
То есть должны быть объективные критерии, по которым можно определить, выполнен тот или иной объект работы или нет».
То есть технические характеристики не могут существовать без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия.
Может быть, техническое задание, или прототип, или любая другая абсурдная бумажка, но только не Техническое Задание.
Отсюда делаем вывод, что в этом ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели снимаются, измеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на доработку.
4) Техническое задание обязательно должно соответствовать общему бизнес-плану заказчика, его стратегии развития бизнеса и анализу сегмента рынка.
Все это позволит вам поставить правильные цели, вывести точные метрики, которые затем будут использоваться для адекватного принятия готового информационного продукта.
Отсутствие бизнес-плана у заказчика автоматически гарантирует непрофессиональное выполнение Технического задания.
Знает ли аутсорсинговая студия бизнес-цели и измеримые показатели бизнеса лучше, чем ее владелец? Очевидно, нет, а значит правильное техническое задание должны писать представители Заказчика, а не наемные сотрудники Подрядчика.
Абсурд, когда исполнитель ставит себе задачу, потом придумывает способы ее оценки и в конце ставит себе итоговую оценку за проделанную работу.
В идеале такой «самодеятельности» быть не должно, хотя на практике именно так и происходит повсеместно, в результате чего Техническое Задание не оказывает необходимого содействия проекту, слишком часто являясь по сути фиктивным документом.
Не надо так.
5) Каждое изменение готового технического задания должно стоить денег.
Вы не можете свободно и бесконечно редактировать «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, вдруг решила сэкономить и т. д. Цена каждого изменения технического задания также должна составлять четко указано заранее в соответствующей главе.
Кстати, по идее, каждое редактирование дизайна или изменение списка страниц или функций должно иметь четкую цену, которая оплачивается заранее, до внесения этого изменения.
Лично я предлагаю, чтобы любое редактирование утвержденного технического задания оценивалось в 30% от всего бюджета проекта, но можно поступить и иначе.
Стоит ли упоминать, что в задании просто необходимо заранее указать сроки и общий бюджет разработки, а также список всех существующих ресурсов и ограничений? - Нет, это будет слишком очевидно.
Итак: Что мы делаем? За что? Как мы поймем, что мы сделали? Сколько стоит каждая опора? — ответы на все эти вопросы, написанные на листе бумаги, — это «серебряная пуля», способная вытащить даже самый провальный проект.
Контрольные вопросы
А здесь я перечислю ответы на наиболее часто задаваемые вопросы клиентов:
1) Так может быть есть и официальный ГОСТ по написанию ТУ? - Да, даже несколько.
2) Что, в ТУ нет описания необходимых страниц, количества кнопок, используемых библиотек, рекомендаций и т.д.? — Не в само ТЗ, но можно все это поместить в Приложениях, естественно скорректировав все это с вышеописанными целями, ограничениями и методами дальнейшей оценки достигнутого результата.
Публикуйте как минимум весь будущий контент, даже описание типичных персонажей — но не вместо четкой постановки задачи, а после нее.
3) Так может мне это и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без технического задания, так же, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения.
Но если вы хотите видеть, куда идете, осознанно принимать решения и самостоятельно оценивать полученные результаты, то без технического задания вам не обойтись.
4) Так вы и в Википедии пишете, что ТЗ создаётся заказчиком.
Но я не знаю как/у меня нет времени/я просто не хочу делать это сама.
Как быть? — Передайте разработку технического задания на аутсорсинг третьей стороне, которая полностью знакома с вашим бизнесом, его задачами, целевой аудиторией и потребностями и при этом досконально знает все этапы веб-разработки.
Эта третья сторона станет своего рода «веб-нотариусом», то есть гарантом того, что подрядчик не занизит нужные вам показатели и не затянет сроки, а заказчик установит достижимые метрики и при окончательной приемке не будет субъективно оценивать создаваемого продукта, на лету меняя фиксированные ранее требования.
5) А если ТЗ является юридическим документом, то я могу подать в суд на аутсорсера, не платить ему, заставить его в десятый раз всё переделывать? — Если документ составлен правильно, указываются цели и методика оценки их достижения; если документ подписан сторонами и упомянут в Соглашении (Само Техническое задание договором не является) - то конечно можно.
А вот с обычным брифом, прототипами, арт-креативным макетом Safe Deal на FL — уже нет. 6) Мне говорят, что работа будет вестись по какому-то Scrum или Agile; а значит мне больше не нужно архаичное техническое задание.
Это верно? — Судите сами: вас называют непонятным словом, которое явно что-то маскирует, а теперь на основе незнакомого термина предлагают отказаться от юридически грамотного документа, наполненного целями и показателями.
Сам по себе Agile не может ставить перед собой никаких целей типа «достичь не менее 10 000 посещений к концу года» или «добиться более 25 заказов с сайта за месяц», это всего лишь способ проведения встреч и новой организации.
нерадивых сотрудников.
Подумайте несколько раз: «А не пускают ли вам пыль в глазаЭ» На самом деле, профессиональное техническое задание не может навредить никакому новомодному Скраму, но оно обязательно поможет. Теги: #техническое задание #разработка сайта #цели и задачи #методологии разработки #Управление проектами #agile #Управление продуктом
-
Лучшая Онлайн-Служба Поддержки Пк
19 Oct, 24 -
Отзывы О Бонусах Fusion Hq
19 Oct, 24
