Что такое тз в программировании
Перейти к содержимому

Что такое тз в программировании

  • автор:

Как составить ТЗ программисту

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

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

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

Как составить ТЗ программистуКак составить ТЗ программисту

Получи грант, покрывающий 50% стоимости обучения
И обучайся новой профессии онлайн из любой точки мира
Получить грант

Как составить грамотное ТЗ

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

Что дает качественно составленное техническое задание:

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

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

Какие советы предлагают эксперты на тему “Как составить тз для программиста”:

  • Чем более сложный и требующий основательного подхода и времени проект, тем более детально следует прописать его элементы и составляющие. К примеру, ТЗ по разработке интерфейса главных страниц требует, чтобы расписали все элементы и способы их выполнения. А для создания сайта-визитки можно расписать основы, составляющие интернет-страницу.
  • ТЗ для специалиста по программированию должно включать в себя задачи только для этого профиля. Не следует добавлять туда задачи, адресованные дизайнеру или другому специалисту.
  • Сделайте описание отдельных задач граничными. То есть, точно обозначьте окончание пунктов одного задания и начало другого.
  • Не используйте в ТЗ обобщенные и абстрактные фразы. Это вводит в заблуждение исполнителя и может быть воспринято неправильно. К примеру, фраза “удобный список функций на сайте”. Слово удобный для каждого воспринимается по-разному, конкретизируйте, что вы хотите видеть в своем проекте.
  • Добавляйте в ТЗ примеры и макеты того, что должно быть в проекте. По возможности покажите исполнителю, что конкретно должно быть на сайте (платформе). Размеры, шрифты, цвета, изображения и т.д.

Правильная структура ТЗ

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

  • Определитесь с целью (целями) проекта. Если у вас нет понимания, для чего разрабатывается проект и какие функции он должен выполнять, то крайне сложно будет заниматься его разработкой. Когда исполнитель видит цели работы, он лучше понимает всю суть задач и видение финального результата.
  • Опишите бюджет проекта. Исполнитель, видя прописанный бюджет, может сверить все задачи и необходимые расходы. Иногда изначально запланированный бюджет может не укладываться в рамки требуемых расходов, и тогда его необходимо пересмотреть и изменить.
  • Список необходимых задач. В виде пунктов и подпунктов распишите все задачи, которые необходимо выполнить в ходе работы над проектом. Разработчик таким образом видит, какую технологию лучше использовать в работе над заданием, применение какого программного кода будет актуальным. Четкое расписание по пунктам в какой-то степени дает гарантию, что все запросы заказчика будут выполнены. А если после сдачи проекта у последнего возникнут вопросы, исполнитель всегда может проверить, включены ли были эти правки изначально в ТЗ.
  • Основательное описание готового продукта. Чем точнее вы опишите конечный продукт, тем большее понимание и уверенность в выполнении работ получает разработчик.
  • Оценка результата проекта. Можно оценивать ход работы поэтапно, а можно это сделать после окончания работы над проектом полностью. Как происходит оценка: для этого существуют специальные программы тестирования. Финальный результат от исполнителя необходимо соотнести с теми требованиями, которые были предписаны в техническом задании. Таким образом, исполнитель может сравнить свою работу и процесс выполнения задач с требованиями, и убедиться в правильности своих действий. Заказчик сможет принять работу, оценивая ее по всем параметрам, и понять, насколько вложенные средства окупили себя.
  • Сроки выполнения работ. Необходимо установить четкие сроки и дедлайны для выполнения всех задач и сдачи финального проекта. Когда заранее установлены сроки, исполнители сразу могут более точно оценить собственные возможности, необходимое количество времени и сил на работу над тем или иным пунктом. Заказчик таким образом может лучше ориентироваться в сроках выполнения работ, и это помогает составлять план всех других проектов. Зачастую работа над определенным ТЗ – это только часть одного крупного проекта или рабочего плана. И точные дедлайны выполнения позволяют установить сроки и планировать выполнение следующих задач.
  • Включите в свой ТЗ возможные форс-мажоры и пути действия в таких ситуациях. Определите заранее сложности и слабые стороны вашего проекта и условий, в которых он будет создаваться.
  • В пункте “Как написать ТЗ для приложения” необходимо вписать будущую работу над обслуживанием проекта. Если заказчик планирует привлекать исполнителя в дальнейшей поддержке сайта, это нужно оговорить и прописать в ТЗ.

Получите профильные знания из сферы информационных технологий на курсах DevEducation.

Как грамотно составить ТЗ программисту на доработку сайта?

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

Почему важно зафиксировать весь процесс работы в виде технической документации?

  1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
  2. Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
  3. Документ позволит четко разделить зоны ответственности между сторонами проекта.
  4. ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
  5. Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
  6. С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
  7. Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

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

Участники проекта

Заказчик Менеджер проекта Разработчики
Ставит задачу Ставит задачу разработчикам Выполняют задание в соответствии с ТЗ
Согласовывает ТЗ Контролирует ход работы и расставляет приоритеты
Принимает работу Осуществляет взаимодействие с заказчиком и разработчиком
Тестирует выполненную работу (если нет тестировщиков)

Если проект большой, дополнительно могут добавиться участники:

  • Product Manager
  • Руководитель проекта
  • Спонсор проекта
  • Тестировщики
  • Технические писатели
  • Кураторы
  • Пользователи/потребители (например, для финального тестирования)
  • И др.

Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.

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

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

Проверка работы проекта по программе тестирования на соответствие требованиям задания

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Последствия составления некачественного задания

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

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

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

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

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

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

Основные рекомендации и пояснения по написанию ТЗ

  1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
  2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
  3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, — неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
  4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
  5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
  6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

  1. Нечеткие цели и задачи.
  2. Мало деталей в технической информации.
  3. Размытые или неустановленные сроки.
  4. Нет согласованности по всем вопросам между сторонами.
  5. Нет регламента взаимодействия.
  6. Нет ответственных лиц.
  7. Нет критериев оценки результата.

Пример правильного технического задания на доработку проекта

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

  1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
  2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
  3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
  4. ЧТО? Структура страницы следующая:
    • заголовок: Ваш консультант — по центру (в стиле других заголовков страниц сайта);
    • 3 блока в ряд, имеющие поля:
      • с фотографиями продавцов размером 400*600 (выравнивание по центру);
      • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
      • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
      • электронный адрес под телефоном (e-mail: site2@mail.ru );
      • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru ).
  5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

  1. ГДЕ? Под списком консультантов, над футером.
  2. ЧТО? Три поля:
    • Имя
    • Номер телефона
    • Содержание заявки
  3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
  4. КУДА? Заявку отправлять на email заказчика: info@common.com
  5. КАК? Оформление письма в свободной форме.
  6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
    При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
  7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
    Проверить:
    • На странице не должно быть незакрытых HTML-тегов.
    • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280×1024.
    • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Читать дальше подобные статьи

  • Что такое внутренние ошибки сервера 500 Internal server error и как их исправить?
  • Проверка сайта на ошибки 404. Как исправить ссылки на страницу?
  • Проверить ошибки HTML кода с помощью валидатора Labrika
  • Требования к CMS для SEO сайта интернет-магазина или форума

Что такое тз в программировании

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

    Техническое задание позволяет:
  • исполнителю — понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;
  • заказчику — осознать, что именно ему нужно;
  • обеим сторонам — представить готовый продукт;
  • исполнителю — спланировать выполнение проекта и работать по намеченному плану;
  • заказчику — требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;
  • исполнителю — отказаться от выполнения работ, не указанных в ТЗ;
  • заказчику и исполнителю — выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний);
  • избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний).

В зависимости от ожиданий заказчика существует три альтернативы для выбора шаблона Технического задания. Если заказчик требует оформления документации в соответствии с государственным стандартом, выбор делается в сторону стандарта ГОСТ 34.602-89. Подготовка Технического задания по ГОСТ 34.602-89 требует значительных временных затрат.

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

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

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

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

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

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

image

Проблема

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

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

Переводим на понятный язык

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

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

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

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

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

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

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

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

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

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

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

image

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

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

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

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

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

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

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

  • техническое задание
  • разработка сайтов
  • цели и задачи
  • методологии разработки по
  • Управление проектами
  • Agile
  • Управление продуктом

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *