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

Содержание

10 опасных ошибок в техническом задании

10 опасных ошибок в техническом задании

Техническое задание описывает работы, которые должен выполнить исполнитель, и требования к ним. Кажется, опиши все подробно в ТЗ – и проблем на проекте не будет! На практике многие ТЗ содержат опасные ошибки, которые могут серьезно «аукнуться» исполнителю. Давайте разберемся, что нельзя делать в техническом задании? Чтобы было нагляднее, приведем реальные примеры.

1. Недостаточная конкретность

Опасная ошибка, которая может привести к переработкам. Например, в ТЗ указано: «исполнитель обязан написать текст объемом 2000 знаков». Исполнитель считает знаки с пробелами, а заказчик – без пробелов. ТЗ определенность не вносит – про пробелы в нем информации нет.

Правильно написать: «исполнитель обязан написать текст объемом 2000 знаков с пробелами», если вы считаете пробелы.

Или еще пример. В техническом задании написано: «уникальность текста должна быть не менее 80%». Вроде бы все хорошо, но возникает вопрос: в какой системе считается уникальность? Клиент смотрит в одной, вы – в другой. Значения получаются разные. Назревает конфликт.

2. Конкретное значение вместо интервала

Ну вот, мы написали «2000 знаков с пробелами». Кажется, все учли. А нет! Сдаем заказчику текст, а там «всего 1998 знаков». Клиент не доволен – работа не соответствует ТЗ. И он прав! Теперь вам придется думать, как сдать текст объемом ровно 2000 знаков. Кстати, если получится 2001 знак – это тоже нарушает ТЗ.

Правильно написать: «исполнитель обязан написать текст объемом до 2000 знаков с пробелами» , но на такую формулировку может не согласиться заказчик. Ведь вы можете написать текст объемом 500 знаков, и он тоже подойдет под эти требования. Поэтому еще лучше написать так: «исполнитель обязан написать текст объемом от 1800 до 2000 знаков с пробелами». Все конкретно, и для вас есть некий интервал по объему.

3. Использование интервала вместо конкретного значения

И это может быть ошибкой! Например, вы пишете в ТЗ: «сайт должен корректно открываться во всех современных браузерах». А что это такое, современные браузеры? Для клиента – IE 6 – тоже вполне современный, установлен на компьютере, который пылится на даче и редко включается. Но ведь работает!

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

4. Гарантии невозможного

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

Поэтому желание гарантировать то, что нельзя гарантировать – опасная игра. Может выйти боком. Многие производители софта не гарантируют, что их программы будут работать корректно и поставляют их на условиях «as is».

5. Отсутствие определений к терминам

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

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

6. Наличие субъективных требований

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

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

Главное: субъективных требований в ТЗ быть не должно!

7. Неполное ТЗ

Хуже сорванного дедлайна, честное слово! Например, вы подробно описали функционал сайта, а добавить структуру в техническое задание – забыли! И начались прения с клиентом: вы думали делать сайт из 10 страниц, а клиент уверен, что страниц должно быть 100, и не меньше!

А еще возник вопрос, кто должен писать тексты для сайта? Клиент уверен – разработчик, а в ТЗ про то, кто должен предоставить контент – ничего не сказано.

8. Все, что не оговорено, выполняется на усмотрение исполнителя

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

9. Устное ТЗ

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

10. А клиент в курсе, что написано в ТЗ?

Убедитесь, что клиент внимательно прочитал техническое задание минимум 2 раза, и у него нет вопросов. Ошибочно думать, что можно написать в ТЗ любые требования к проекту, а если заказчик их не прочитал – это его проблемы. Это ваши проблемы! Если клиент не прочитал ТЗ, значит, он считает его формальностью, а при реализации проекта потребует делать «как он сказал, а что написано в ТЗ – это не важно». Можно, конечно, идти на конфликт, но зачем он вам нужен?

Поэтому вместе с клиентом внимательно прочитайте ТЗ. Объясните, что это не формальность. Согласуйте ТЗ с клиентом, убедившись, что клиент согласен со всеми формулировками в техническом задании. И только после этого приступайте к работе!

Полезные статьи по теме:

Рекомендуем

Что делать с работой, которую не оплатили?

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

Типы клиентов и методы работы с ними

Существует множество типологий клиентов. Мы рассмотрим типы клиентов, которые пользуются услугами фрилансеров – но эти же типы клиентов ...

задание - это... Что такое задание?

  • задание — задание …   Нанайско-русский словарь

  • задание — См. задача... Словарь русских синонимов и сходных по смыслу выражений. под. ред. Н. Абрамова, М.: Русские словари, 1999. задание вопрос, задача, урок, поручение, цель, запрос, миссия, штраф, план, нагрузка, упражнение, тест, фант, мечта идея,… …   Словарь синонимов

  • ЗАДАНИЕ — ЗАДАНИЕ, задания, ср. Возложенная на кого нибудь задача, поручение (книжн. газет.). Задание по снижению себестоимости выполнено. Плановое задание. Превысить задание. Работать по заданиям. || Замысел, цель, задача. Поставить себе задание. || То,… …   Толковый словарь Ушакова

  • ЗАДАНИЕ НА — ПРОЕКТИРОВАНИЕ, разработку перечень требований, условий, целей, задач, поставленных заказчиком в письменном виде, документально оформленных и выданных исполнителю работ проектно исследовательского характера. Такое задание обычно предшествует… …   Экономический словарь

  • задание —     ЗАДАНИЕ, упражнение, урок, устар. класс …   Словарь-тезаурус синонимов русской речи

  • ЗАДАНИЕ — ЗАДАНИЕ, я, ср. То, что назначено для выполнения, поручение. Дать, выполнить з. Производственное з. Боевое з. Домашнее з. (то же, что урок во 2 знач.). Толковый словарь Ожегова. С.И. Ожегов, Н.Ю. Шведова. 1949 1992 …   Толковый словарь Ожегова

  • ЗАДАНИЕ — ЗАДАНИЕ. Письменная или устная инструкция по работе с учебными материалами. Является одним из средств обучения. Формулировки З. во многом определяют эффективность упражнений …   Новый словарь методических терминов и понятий (теория и практика обучения языкам)

  • задание — — [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN job …   Справочник технического переводчика

  • ЗАДАНИЕ — основная единица работы ЭВМ. Оно состоит в осуществлении некоторого вычислительного процесса и для своей реализации требует выполнения одной или нескольких обрабатывающих программ, связанных между собой смысловым содержанием задачи. Каждое З.… …   Большая политехническая энциклопедия

  • задание — выполнить задание • реализация выполнять задание • реализация дать задание • действие задание выполнить • реализация получить задание • действие, получатель получить новое задание • действие, получатель …   Глагольной сочетаемости непредметных имён

  • задание — Викисловарь

    Морфологические и синтаксические свойства

    падеж ед. ч. мн. ч.
    Им. зада́ние зада́ния
    Р. зада́ния зада́ний
    Д. зада́нию зада́ниям
    В. зада́ние зада́ния
    Тв. зада́нием зада́ниями
    Пр. зада́нии зада́ниях

    за-да́-ни·е

    Существительное, неодушевлённое, средний род, 2-е склонение (тип склонения 7a по классификации А. А. Зализняка).

    Приставка: за-

    ; корень: -да-; суффикс: -ниj; окончание: [Тихонов, 1996].

    Произношение

    • МФА: ед. ч. [zɐˈdanʲɪɪ̯ə]  мн. ч. [zɐˈdanʲɪɪ̯ə]

    Семантические свойства

    Значение
    1. действие по значению гл. задавать; поручение, указание или установление чего-либо ◆ Отсутствует пример употребления (см. рекомендации).
    2. то, что было задано, назначено для выполнения ◆ Отсутствует пример употребления (см. рекомендации).
    Синонимы
    1. задача, указание
    2. задача, упражнение
    Антонимы
    1. -
    2. -
    Гиперонимы
    Гипонимы
    Меронимы
    1. подзадание
    2. подзадание

    Родственные слова

    Этимология

    Происходит от глагола задать, из за- + дать, далее от праслав. *dā́tī; *dājā́tī; *dāvā́tī, от кот. в числе прочего произошли: ст.-слав. дати (греч. διδόναι), русск. дать, давать, укр. дати, белор. даць, сербохорв. да̏ти, словенск. dáti, чешск. dát, польск., в.-луж. dać, н.-луж. daś. Восходит к праиндоевр. *do-. Родственно лит. dúoti, 1 л. ед. dúomi, dúodu «даю», греч. δίδωμι, др.-инд. dádāti «даёт», авест. dadāiti «даёт», алб. аор. dhashë «я дал», алб.-тоск. dhënë ж., гег. dhąnë ж. «дар». Использованы данные словаря М. Фасмера. См. Список литературы.

    Фразеологизмы и устойчивые сочетания

    Перевод

    Так что же такое «Техническое Задание»? / Habr

    Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

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


    Проблема

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

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

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

    2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».

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

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

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

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

    5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

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

    Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

    Контрольные вопросы

    А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

    1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.

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

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

    4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

    5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.

    6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

    10 заповедей технического задания (с толкованием). Читайте на Cossa.ru

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

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

    Форматы ТЗ перерабатывались, перерабатываются и будут перерабатываться. Формулировки переписываются, какие-то разделы вымарываются, новые добавляются. Толщина документа непостоянна, как ветер мая.

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

    Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

    1. ТЗ — обязательный документ при создании любого продукта

    Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

    2. ТЗ описывает продукт, но не проект

    ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

    ТЗ в общем случае обозначает требования к продукту, но не требования к тому, как этот продукт будет делаться. Это не касается тех случаев, когда метод неотделим от продукта. Автор ТЗ не имеет права навязывать разработчикам решение хотя бы потому, что он не обладает должной экспертизой. При этом важно следить и за тем, чтобы разработчик не спрашивал с ТЗ того, что он должен решать на своём уровне.

    3. ТЗ не является договором

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

    4. ТЗ описывает не только функциональные требования, но и интерфейс

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

    5. ТЗ составляет только обладающий соответствующей компетенцией специалист

    Звучит просто, а реализуется сложно.

    Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

    6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

    Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.digital перешли на относительно новую для рынка схему, когда ТЗ делается уже после утверждения дизайна. Таким образом, техническое задание у нас не диктует требования к дизайну, потому что у него на то нет компетенции, а фиксирует дизайн. Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

    7. ТЗ не терпит правок после его утверждения

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

    8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

    9. ТЗ должно описывать, как минимум, текущую версию продукта

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

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

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

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

    ЗАДАНИЕ НА - это... Что такое ЗАДАНИЕ НА?

  • задание — задание …   Нанайско-русский словарь

  • задание — См. задача... Словарь русских синонимов и сходных по смыслу выражений. под. ред. Н. Абрамова, М.: Русские словари, 1999. задание вопрос, задача, урок, поручение, цель, запрос, миссия, штраф, план, нагрузка, упражнение, тест, фант, мечта идея,… …   Словарь синонимов

  • ЗАДАНИЕ — ЗАДАНИЕ, задания, ср. Возложенная на кого нибудь задача, поручение (книжн. газет.). Задание по снижению себестоимости выполнено. Плановое задание. Превысить задание. Работать по заданиям. || Замысел, цель, задача. Поставить себе задание. || То,… …   Толковый словарь Ушакова

  • задание —     ЗАДАНИЕ, упражнение, урок, устар. класс …   Словарь-тезаурус синонимов русской речи

  • ЗАДАНИЕ — ЗАДАНИЕ, я, ср. То, что назначено для выполнения, поручение. Дать, выполнить з. Производственное з. Боевое з. Домашнее з. (то же, что урок во 2 знач.). Толковый словарь Ожегова. С.И. Ожегов, Н.Ю. Шведова. 1949 1992 …   Толковый словарь Ожегова

  • ЗАДАНИЕ — ЗАДАНИЕ. Письменная или устная инструкция по работе с учебными материалами. Является одним из средств обучения. Формулировки З. во многом определяют эффективность упражнений …   Новый словарь методических терминов и понятий (теория и практика обучения языкам)

  • задание — — [http://www.iks media.ru/glossary/index.html?glossid=2400324] Тематики электросвязь, основные понятия EN job …   Справочник технического переводчика

  • ЗАДАНИЕ — основная единица работы ЭВМ. Оно состоит в осуществлении некоторого вычислительного процесса и для своей реализации требует выполнения одной или нескольких обрабатывающих программ, связанных между собой смысловым содержанием задачи. Каждое З.… …   Большая политехническая энциклопедия

  • задание — сущ., с., употр. сравн. часто Морфология: (нет) чего? задания, чему? заданию, (вижу) что? задание, чем? заданием, о чём? о задании; мн. что? задания, (нет) чего? заданий, чему? заданиям, (вижу) что? задания, чем? заданиями, о чём? о заданиях 1.… …   Толковый словарь Дмитриева

  • задание — выполнить задание • реализация выполнять задание • реализация дать задание • действие задание выполнить • реализация получить задание • действие, получатель получить новое задание • действие, получатель …   Глагольной сочетаемости непредметных имён

  • Согласно техническому заданию / Habr

    Добрый вечер, созидающая часть Хабра!

    Будучи разработчиком, я постоянно работаю с техническими спецификациями клиентов и мой первый пост — это небольшой очерк, анализ такой вещи, как «техническое задание».

    Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!

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

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

    Жаль только, что, полное неоспоримых преимуществ, Тех. Задание, содержит пару больших и жирных «но».

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

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

    Одна будет грязно-серой, другая – белоснежной; одна — стоить доллар, другая в три раза дороже! Выбрав одну – вы заработаете геморрой, выбрав другую – достигнете небывалых высот мысли.

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

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

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

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

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

    Разумное применение

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

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


    Я призываю Заказчика помнить, что ТЗ — это полезная штука, но она описывает низший уровень качества решения. Хороший, по-настоящему хороший продукт требует к себе человеческого отношения на всех этапах создания. Любите его, не торопитесь с релизом, и он непременно получится восхитительным!

    Изображения взяты с сайтов: pt.wikinoticia.com cultofmac.cultofmaccom.netdna-cdn.com, www.popwuping.com, www.thinkgeek.com

    P.S. Я не уверен в правильности выбранного блога, но не нашел более подходящего.

    Отправить ответ

    avatar
      Подписаться  
    Уведомление о