Мы часто сталкиваемся с тем, что техническое задание написано просто потому, что нужно. В итоге, оно либо написано слишком сложно, либо накладывает ненужные ограничения на проект. Важно также понимать, что техническое задание не дает гарантию отсутствия изменений в процессе разработки проекта. Поэтому, важно составить такое техническое задание, которое будет полезно обеим сторонам и уменьшит риски на проекте.
Когда разработка технического задания не нужна?
Если кратко — техническое задание необходимо только на сложных проектах. В остальных случаях — это пустая трата времени. Нет смысла разрабатывать техническое задание для несложных корпоративных сайтов, промо-сайтов и лендингов. Это также ограничит решения по дизайну на проекте.
На подобных проектах нужно составить структуру сайта, кратко описать функционал страниц и зафиксировать базовые технические требования к проекту (поддерживаемые браузеры, требования к серверу и системе управления сайтом и т.д.). Хватит нескольких листов A4, чтобы это описать. Остальные нюансы (например, анимации) обсуждаются после сдачи дизайна.
На нашей практике не было ни одного проекта в процессе разработки которого не происходило изменений. Главный принцип — не менять количество страниц и функциональную составляющую. Если это происходит — то стоимость проекта увеличивается.
Когда техническое задание необходимо?
Если проект сложный — например, корпоративный сайт с личным кабинетом и разными типами пользователей или интернет-магазин — то в этом случае рекомендуется написать техническое задание. Также для такого проекта лучше выбрать поэтапную реализацию.
На первом этапе происходит исследование и разрабатывается техническое задание на функционал проекта. Затем происходит финальный просчет проекта, где каждый сложный этап разбивается на части. После этого проект реализуется по частям. Таким образом, клиент в быстрый срок получает готовую часть проекта.
Ошибки при разработке технического задания
Перечень ошибок, которые часто встречаются в техническом задании:
- Много «воды» и абстрактного текста. Например — описание задач сайта и целевой аудитории, фиксация излишних требований к дизайну, чрезмерное использование канцелярского языка и т.д.
- Подробное описание каждой страницы текстом, вплоть до требований по дизайну к каждому элементу, вместо использования графики, прототипов или дизайна (если он уже подготовлен).
- Копирование кусков технических заданий без понимания сути текста. Например, устаревшие технические требования (поддержка браузеров Internet Explorer).
- Сложное графическое оформление: мелкий шрифт, разный размер текста, неправильное выравнивание и т.д.
Как выглядит идеальное техническое задание?
Хорошее техническое задание содержит:
- Четкое описание результата проекта.
- Этапы проекта, сроки, правила приемки каждого этапа.
- Ссылку на прототип. Возможно краткое описание структуры и функционала, если потребуется.
Главный вывод — ни в каком проекте нельзя предусмотреть все заранее. И техническое задание — не панацея. Но оно может упростить процесс разработки проекта для обеих сторон, если будет составлено правильно.
Прочел статью и остался в недоумении. Вроде бы автор работает в сфере дизайна и веб-проектирования, но при этом имеет какие-то фундаментальные ошибки в представлении о том что такое ТЗ, когда и для чего оно пишется.
Ваша статья содержит на половину воду, а на половину какие-то предрассудки. Также крайне странно требовать от клиента прототипа (он по вашему должен спроектировать варйфреймы, сам все продумать, натянуть первичный ui и еще и прототипировать? Это редкость.
Первые 2 пункта из вашей "рекомендации" для "хорошего" тз, это вещи, которые должны быть в уставе проекта, на худой конец в концепции. То что вы описываете как прототип, который должен быть в ТЗ, это вообще отдельный материал, почему он должен быть в ТЗ загадка.
А уж то, что в описываете как минусы, это вообще user story, говорить что это минус... Ну не знаю, как минимум овер странно.
Артем, спасибо за комментарий. Отвечу сразу на этот и следующий.
В статье мы нигде не указали, что написание ТЗ на стороне заказчика. Естественно, это наша задача. Особенно, когда речь касается прототипов и всех технических вопросов. Поэтому, я с вам тут полностью согласен.
Цель статьи была в другом — опровергнуть известный миф о том, что ТЗ спасает от всего, для сложных проектов оно лишнее и как раз, что писать ТЗ нужно грамотно, а это смогут сделать только специалисты. Т.е., по сути то, о чем вы пишете.
Я думаю, просто недостаточно правильно донесли мысль, не раскрыли суть, но наша статья, повторюсь, для клиентов, которые, как правило, вообще не разбираются во всех тонкостях.
Что касается наличия прототипов в техническом задании. Мы считаем, что это обязательная функция, поскольку читать текстом состав каждой страницы довольно сложная задача с точки зрения восприятия и понимания. Куда проще "потыкать" готовый прототип со всем функционалом.
User story это часть аналитического этапа, который мы тоже делаем. Он к техническому заданию никак не относится.
согласна, что все должно быть по существу. Но описывать все пожелания и требования обязательно, чтобы потом не было "Мы это видели по-другому"...
Мы пишем о том же самом. Вопрос лишь в том, как это описывать, насколько сложно и нужно ли описывать слишком развернуто.
Ожидать от обычных клиентов профессионального ТЗ также крайне странно, как минимум вы должны или предоставлять шаблон и рекомендации, как максимум сами реализовывать это как платную услугу.
Комментарий недоступен
У нас был печальный опыт в этом вопросе, как с нашей стороны (отсутствие компетенций), так и со стороны заказчиков (непонимание процессов). В результате, мы хотели найти такое решение, которое бы обезопасило нас и клиента, но не усложняло никому жизнь. Об этом мы и попытались написать.
Две недели писать ТЗ — это пиздец, ребята :)
Если клиент не профи в разработке (а таких 99%), не разбирается в тонкостях ведения проекта и тем более не готов заказывать (что?), то даже самое подробное ТЗ не спасёт вас от фиаско и походов в суд.
К слову о судах, что мешает заложить в доп. соглашение на этап четкое кол-во итераций? А клиенту строго так, красненьким, сообщить, что если он хочет вносить правки, то ему надо хорошенько так подумать и выдать всё единым документом, аргументировано и без противоречия предыдущим этапам. Ну и конечно же, промежуточные акты на этап, что мешает их высылать и требовать подписать?
А про «заказчик должен ощущать, что исполнитель заебался» я вообще не понял. Какой смысл в этом? Показать, что вы лох и нихуя не умеете, что «эта» задача вызвала у вас жёпную боль и реки пота? ИМХО, весьма сомнительная «психологическая-уловка», которая скорее граничит с самодурством.
Клиенту нужен результат, рамки которого описываются в группе специальных документов, совокупно именуемых «техническим заданием». Если итог соответствует задуманному и решает поставленные бизнес-задачи, значит всё «ок», а если клиент хочет «поиграть со шрифтами», то это или отдельной задачей или в рамках этапа доработок (которые обычно оцениваются в 25% от общей стоимости), либо в ущерб сроков.
И мой опыт показывает, что бОльшая часть всех хотелок как-то сразу испаряется :)
Комментарий недоступен
Согласен. Поэтому мы стараемся работать со всеми по соответствующим шаблонам. Опять же, зачем небольшому проекту большое и сложное ТЗ.
В наше время, — время гибких методологий, — классическое ТЗ нахОй не нужОн.
Львиная доля всех вопросов закрывается на этапах агрегации требований и разработке прототипа. Причём, эти два этапа связаны, как ниточка с верёвочкой.
И под агрегацией требований, лично я понимаю довольно большой, но не такой унылый, скучный, пресный и обоссаный процесс, как с разработкой «классического тз».
Опять таки, тут надо сделать ремарку, что есть ТЗ, в которых каждый раздел сайта описан тезисно, мол, эта главная, тут должна быть презентация продукта, о компании и форма обратной связи. Или вот каталог, тут должны быть (сверху вниз): шапка с контактами и развитой навигацией, блок с развитым поиском, фильтры, сам каталог товара, блок с сео-текстом, блок с инстой и блок со статьями.
То есть у исполнителя есть пространство для манёвра и демонстрации своих компетенций, умений, ловкости и силы :) Зачастую же клиент приходит именно за тем, чтобы ему сделали заебись, а не рассказать нам, как нам делать свою работу.
Возвращаясь к агрегации требований.
Как я уже написал, сам по себе этап объемный, но не такой выматывающий, как разработка обычного ТЗ.
Лично я в агрегацию требований пихаю:
* брифование заказчика на предмет всех хотелок,
* формулирование и/или фиксация основных целей и задач по сайту,
* анализ ниши, конкурентов и смежных тематик,
* изучение ЦА клиента,
* разработка базовой структуры сайта в виде mindmap со всей хуйнёй,
* согласование и фиксация плана работы, мол, если проект простой, то иногда сразу можно сказать, что работа по проектированию и дизайну займёт 15 дней и ещё 15 дней на тех. часть (вёрстка, интеграция, программирование). Или, если задача мудрёная, очерчиваем последовательность шагов, мол, согласовываем этап 1 — агрегация требований, далее приступаем к этапу 2 — проектирование, и т.д.
Как я уже писал выше, агрегация требований это пред-этап разработки прототипа. Сам же по себе прототип, в совокупности с ранее проделанной работой, уже является «техническим заданием». При чем, его «действенная сила» куда могущественнее, чем обоссаный талмуд из 100500 страниц, даже написанный самым художественным и живым языком :)
И могущество его заключается в особенности человеческой психики — рассматривать картинки интереснее, проще и быстрее, чем читать и разбираться. То есть, клиенту проще принять работу, объяснить, что не так и поделиться своими мыслями и новыми хотелками, когда он видит и может пощупать хоть что-то.
Не говоря уже о том, что вносить правки и согласовывать прототип куда проще и приятнее, чем опять переписывать/дописывать/согласовывать новую редакцию/спорить и судиться в рамках классического ТЗ.
А если речь идёт о простых задачах, типа обычных корпоративных сайтов, визиток и прочих промо-сайтов, то и как таковой агрегации требований не надо, достаточно всё согласовать на этапе прототипа.
Такая хуйня, тз не нужОн. Имхо.