Почему техническое задание на сайт — не панацея?

В закладки

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

Когда разработка технического задания не нужна?

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

На подобных проектах нужно составить структуру сайта, кратко описать функционал страниц и зафиксировать базовые технические требования к проекту (поддерживаемые браузеры, требования к серверу и системе управления сайтом и т.д.). Хватит нескольких листов A4, чтобы это описать. Остальные нюансы (например, анимации) обсуждаются после сдачи дизайна.

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

Когда техническое задание необходимо?

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

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

Ошибки при разработке технического задания

Перечень ошибок, которые часто встречаются в техническом задании:

  1. Много «воды» и абстрактного текста. Например — описание задач сайта и целевой аудитории, фиксация излишних требований к дизайну, чрезмерное использование канцелярского языка и т.д.
  2. Подробное описание каждой страницы текстом, вплоть до требований по дизайну к каждому элементу, вместо использования графики, прототипов или дизайна (если он уже подготовлен).
  3. Копирование кусков технических заданий без понимания сути текста. Например, устаревшие технические требования (поддержка браузеров Internet Explorer).
  4. Сложное графическое оформление: мелкий шрифт, разный размер текста, неправильное выравнивание и т.д.

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

Хорошее техническое задание содержит:

  1. Четкое описание результата проекта.
  2. Этапы проекта, сроки, правила приемки каждого этапа.
  3. Ссылку на прототип. Возможно краткое описание структуры и функционала, если потребуется.

Главный вывод — ни в каком проекте нельзя предусмотреть все заранее. И техническое задание — не панацея. Но оно может упростить процесс разработки проекта для обеих сторон, если будет составлено правильно.

{ "author_name": "Александр Смирнов", "author_type": "self", "tags": [], "comments": 11, "likes": -5, "favorites": 0, "is_advertisement": false, "subsite_label": "design", "id": 127334, "is_wide": false, "is_ugc": true, "date": "Fri, 15 May 2020 13:51:44 +0300", "is_special": false }
Дарина Фролова
«Если вас двое, то вы в 10 раз сильнее»: интервью с президентом «Клуба 500» Дмитрием Портнягиным
Пока все паникуют, скупают валюту и совершают прочие глупости, можно открыть новые возможности для своего бизнеса…
Объявление на vc.ru
0
11 комментариев
Популярные
По порядку
Написать комментарий...
3

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

Ваша статья содержит на половину воду, а на половину какие-то предрассудки. Также крайне странно требовать от клиента прототипа (он по вашему должен спроектировать варйфреймы, сам все продумать, натянуть первичный ui и еще и прототипировать? Это редкость.

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

А уж то, что в описываете как минусы, это вообще user story, говорить что это минус... Ну не знаю, как минимум овер странно.

Ответить
0

Артем, спасибо за комментарий. Отвечу сразу на этот и следующий.

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

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

Я думаю, просто недостаточно правильно донесли мысль, не раскрыли суть, но наша статья, повторюсь, для клиентов, которые, как правило, вообще не разбираются во всех тонкостях.

Что касается наличия прототипов в техническом задании. Мы считаем, что это обязательная функция, поскольку читать текстом состав каждой страницы довольно сложная задача с точки зрения восприятия и понимания. Куда проще "потыкать" готовый прототип со всем функционалом.

User story это часть аналитического этапа, который мы тоже делаем. Он к техническому заданию никак не относится.

Ответить
1

согласна, что все должно быть по существу. Но описывать все пожелания и требования обязательно, чтобы потом не было "Мы это видели по-другому"...

Ответить
0

Мы пишем о том же самом. Вопрос лишь в том, как это описывать, насколько сложно и нужно ли описывать слишком развернуто.

Ответить
1

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

Ответить
0

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

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

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

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

Ответить
0

У нас был печальный опыт в этом вопросе, как с нашей стороны (отсутствие компетенций), так и со стороны заказчиков (непонимание процессов). В результате, мы хотели найти такое решение, которое бы обезопасило нас и клиента, но не усложняло никому жизнь. Об этом мы и попытались написать.

Ответить
0

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

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

А про «заказчик должен ощущать, что исполнитель заебался» я вообще не понял. Какой смысл в этом? Показать, что вы лох и нихуя не умеете, что «эта» задача вызвала у вас жёпную боль и реки пота? ИМХО, весьма сомнительная «психологическая-уловка», которая скорее граничит с самодурством.

Клиенту нужен результат, рамки которого описываются в группе специальных документов, совокупно именуемых «техническим заданием». Если итог соответствует задуманному и решает поставленные бизнес-задачи, значит всё «ок», а если клиент хочет «поиграть со шрифтами», то это или отдельной задачей или в рамках этапа доработок (которые обычно оцениваются в 25% от общей стоимости), либо в ущерб сроков.

И мой опыт показывает, что бОльшая часть всех хотелок как-то сразу испаряется :)

Ответить
0

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

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

Ответить
0

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

Ответить
0

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

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

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

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

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

Лично я в агрегацию требований пихаю:
* брифование заказчика на предмет всех хотелок,
* формулирование и/или фиксация основных целей и задач по сайту,
* анализ ниши, конкурентов и смежных тематик,
* изучение ЦА клиента,
* разработка базовой структуры сайта в виде mindmap со всей хуйнёй,
* согласование и фиксация плана работы, мол, если проект простой, то иногда сразу можно сказать, что работа по проектированию и дизайну займёт 15 дней и ещё 15 дней на тех. часть (вёрстка, интеграция, программирование). Или, если задача мудрёная, очерчиваем последовательность шагов, мол, согласовываем этап 1 — агрегация требований, далее приступаем к этапу 2 — проектирование, и т.д.

Как я уже писал выше, агрегация требований это пред-этап разработки прототипа. Сам же по себе прототип, в совокупности с ранее проделанной работой, уже является «техническим заданием». При чем, его «действенная сила» куда могущественнее, чем обоссаный талмуд из 100500 страниц, даже написанный самым художественным и живым языком :)

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

Не говоря уже о том, что вносить правки и согласовывать прототип куда проще и приятнее, чем опять переписывать/дописывать/согласовывать новую редакцию/спорить и судиться в рамках классического ТЗ.

А если речь идёт о простых задачах, типа обычных корпоративных сайтов, визиток и прочих промо-сайтов, то и как таковой агрегации требований не надо, достаточно всё согласовать на этапе прототипа.

Такая хуйня, тз не нужОн. Имхо.

Ответить

Прямой эфир