Пользователь
0,0
рейтинг
28 февраля 2012 в 17:23

Разработка → Техническое задание на сайт

UPD: Продолжение статьи с примером техзадания

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

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

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

1. Обоснование необходимости ТЗ


А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:




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



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

Если «вычесть» одну картинку из другой, сделать, так сказать, diff, то мы получим разницу в ожиданиях заказчика и планах разработчика. И разница эта может быть весьма существенной:



И вот здесь возникает конфликт, где каждая из сторон права: заказчик не получил то, что ожидал за оговоренную цену, его пытаются «прокидать»; исполнитель же считает, что сделал все в точности с заказом, а остальные «хотелки» — это попытка «прокидать» его. Этот конфликт может решиться по-разному: либо заказчик примет, то что есть, либо разработчик доделает все бесплатно, либо обе стороны пойдут на взаимные уступки. Но в любом случае, будут пострадавшие.

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

Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему.

И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д.
Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот.

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



Синяя линяя — стоимость ТЗ, она растет с ростом детализации, красная линия — стоимость diff-а, его стоимость, напротив, падает с ростом детализации.

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки



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

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

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

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

Формулировки должны быть «закрытыми», т.е. четко указывать границу нашей работы. В ТЗ не может быть написано «админка должна быть удобной». Удобство — субъективный фактор, кому-то удобно так, кому-то иначе, и в случае спора трудно будет установить, кто прав. Формулировка «админка должна быть удобной» может привести к бесконечным переделкам: «добавьте в админку к списку товаров сортировку по столбцам и фильтрацию. Без этого не удобно. И загрузку товаров из экселя, по одному добавлять не удобно».

«Всё, что не оговорено, выполняется на усмотрение исполнителя» — не смотря на суровость этого заявления, эта фраза должна присутствовать в ТЗ. Она проистекает из самой сути задания: заказчик хочет получить некий продукт, но он не может и не должен указывать каким образом будет достигнут конечный результат. Этот пункт защищает от вмешательства в глубины работы (не хватало, чтоб заказчик начал рассказывать, как именовать функции в коде и какие пакеты использовать), но также перечеркивает возможность заказчика иметь любые хотелки. На мой взгляд, стоит идти на встречу заказчику в хотелках, пока это не выходит за рамки приличия. Когда же терпение лопается, нам и пригодится этот пункт. Как в песне поется: «Мы мирные люди, но наш бронепоезд стоит на запасном пути». (Фразу «что не оговорено — на усмотрение исполнителя», лучше всунуть под конец ТЗ, в начале она может быть встречена в штыки. Но если ТЗ нормальное и в конце стоит эта фраза, против неё не будут протестовать).

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

3. Разделы ТЗ


3.1 Общие слова

Этот раздел вводит в курс дела. Исходите из того, что вам нужно отдать ТЗ стороннему программисту, и вас не будет на связи всё время работы над проектом вплоть до сдачи. Т.е. программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.

3.2 Эксплуатационное. назначение

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

3.3 Функциональное назначение

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

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

3.4 Термины и определения

Этот раздел дает уверенность, что заказчик и исполнитель говорят об одном и том же.
Термины могут «вводится» с двух сторон: от вас к заказчику, например вы ему втолковываете, что такое хостинг и SMTP-сервер, и от заказчика к вам.

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

3.5 Данные и списки


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

Данные

Этот раздел содержит перечень сущностей, которые используются в проекте. Это очень близко к описанию таблиц в базе данных или моделей, если говорить о фреймворках с MVC. Например, у нас на сайте есть новости. А что такое новость? Как гласит военное определение, куст — это совокупность веток и листьев торчащих из одного места. Так и новость, это совокупность заголовка, текста и даты публикации. Для чего нужно это определение? Как и всё в ТЗ — прояснить, что делать и подстраховаться от хотелок.

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

Для примера, та же самая новость:
  • Заголовок
  • Текст
  • Дата публикации

Предположим, в процессе работы выясняется, что забыли анонс новости (коротенький текст, который отображается в списке новостей). Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная.

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей.
Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список. А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи.

Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра. И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е. тут нужно подробно описывать алгоритм по определению сходства статей. Пропустив этот пункт на этапе оценки сроков можно промахнуться достаточно сильно.

3.6 Страницы с описанием


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

Тут будет уместно описать не только, что отображается, но и как. Не в том смысле, что мы описываем дизайн: «Большими красными буквами отображается название новости», а в смысле, как работает: «Слева плавно выезжает окошко с предложением ввести логин и пароль». Или так: «при нажатии кнопки „Отправить комментарий“, комментарий появляется на странице без перезагрузки, с помощью AJAX».

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

Естественно, будет очень здорово добавить к каждой странице эскиз вроде такого:

Стоит следить, чтобы текстовое описание не вступало в противоречие с тем, что нарисовано в эскизе.
Т.е. если на иллюстрации новость имеет «Категорию новости», а в разделе «Данные и списки» новость не имеет ее, то это проблема. Очень высока вероятность, что изучая ТЗ, заказчик запомнит именно картинку с эскизом новостей, в которой есть категория, и если в готовом проекте не будет категории (в соответствии с текстовым описанием новости), он расстроится.

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

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

3.7 Требования к надежности


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

Стоит отдельно сказать, что для надежности, необходимо настроить бэкапы, т.к. «случаи разные бывают» и никто не застрахован от злобных хакеров которые могут попортить базу данных или хостеров, которые могут сгореть синим пламенем, как это уже бывало.

3.8 Требования к хостингу

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

Помимо таких очевидных проблем есть проблемы и потоньше. Например, для нормальной работы нужен cron, а хостер его не предоставляет (абсолютно реальный случай из моей практики). Или, скажем, специфический сайт, который не может работать на shared хостинге, ему нужен только VPS или VDS.

Сюда стоит включить требования к интерпретаторам, библиотекам, пакетам, гемам, требования к дисковому пространству, памяти, smtp, pop, ftp, внешним программам и прочему, что имеет значение для работы проекта.

3.9 Наполнение контентом

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

Если мы должны, например, залить в каталог 500 фотографий, предварительно их обработав, то это следует описать именно тут.

Описание этого раздела предостережет нас от разного понимания того, кто должен залить 500 фотографий и наполнить каталог товарами.

3.10 Сдача и приемка


Описание тех условий, при наступлении которых должен состояться расчет за работу.

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

Кстати, 100% оплата, я думаю, не должна означать окончание исправления багов. На мой взгляд, на баги должна даваться пожизненная гарантия, и исправляться они должны всегда и бесплатно. Хотя, думаю, тут будут и иные взгляды на эту проблему.

Заключение


Конечно, это ТЗ не охватывает все стороны сайта, но для очень большого числа проектов оно станет хорошим описанием.

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

Буду рад услышать критику и, особенно, описание случаев, когда подобное ТЗ не подходит.
Борис Михайленко @stg34
карма
103,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (138)

  • +15
    Вот спасибо! Честное слово, безумно хорошо и доходчиво для определенного круга лиц написано. Надеюсь, что те, кому я ссылку дал впитают информацию и больше не будут допускать ошибок, совершаемых ранее.
    • +3
      Буду очень рад если эта статья хоть чуть-чуть изменит ситуацию с заданиями на сайт :)
    • 0
      Вот бы ещё посмотреть составленное ТЗ на разработку сайта от автора.
  • +5
    Why so comic sans?
    • +17
      Pencil Project uses Comic sans by default
      • +1
        Уже не первая программа, где он по-умолчанию. Это — заговор.
        • +12
          Шрифт Comic Sans был сделан для текста в комиксах. Данные скетчи стилизованы под карандашные наброски и этот шрифт прекрасно к ним подходит. Глупо было бы использовать тут шрифт стилизованный под матричный принтер.
      • 0
        Спасибо за наводку. Что-то что не смотрел подобное — всё платное и под винду.… Жаль нельзя два плюса в карму ставить :(
    • –11
      Мне кажется, это специально, чтобы показать нубство этих картинок
    • 0
      Для иллюстрации «То как видит проект заказчик» это и есть самый правильный шрифт!
  • +3
    Картинки к статье были самостоятельно нарисованы или есть какой-то сервис?
  • –48
    если разработчик представляет интернет-магазин (назовем это так) как показано на первой картинке, то он херовый разработчик. Не предусмотреть «скидку», «количество для заказа», «бэйджик „новинка“, „нет на складе — оставить заявку“, „скидка в корзине“ — это банальная некомпетентность и на водит на мысли, что разработчик не только ни разу не делал подобное, но и не удосужился посмотреть интернеты на эту тему.

    Заказчик в этом случае прав.
    • +31
      Вы знаете чем отличаются иллюстрации для пояснения принципа от реальных вещей?
      • –25
        ну извините, нарисовали бы в первом случае круг, а во втором квадрат, тогда бы было вообще абстрактно и не придерешься.
    • +11
      Для футболок еще обязательно размер, например, с наличием каждого размера, а для автозапчатей цвет, а для школьных тетрадей — в клеточку они или линейку, а для детской одежды еще примерный рост-возраст ребенка, а для кошачих кормов породы кошек, а для резиновых членов длину, форму и флажок ХИТ СЕЗОНА.

      Суть в том, что программист все равно никогда не сможет учесть и предусмотреть все необходимые нюансы заранее и сам, если ему о них не рассказать.
      • –3
        «тёртый» программист\дизайнер не будет делать первую картинку основываясь на опыте, он сразу выбьет у заказчика описание и сделает вторую.
        • +5
          Это должен делать менеджер
          • –1
            смотря какую ситуацию рассматривать. фриланс или большую студию.
            А менеджер, который знает тонкости баз данных, разбирается в дизайне, верстке и еще куче вещей — золотой человек. таких не бывает.
            чаще всего менеджер — ведет проект, звонит заказчику, прикрывает жопу дизайнера\программиста, согласует сроки.
            • +3
              смотрите, есть разделение: аккаунт-менеджер и проджект-менеджер. Вот первый общается с заказчиком, а второй ведет проект. Проджект ОБЯЗАН знать основы БД, разбираться в юзабилити и верстке. Имхо. И да, эти два человека должны быть разными.
              • 0
                ну, приближаемся к идеалу. еще есть сэйл-менеджер и еще куча людей. Для крупных студий -да. Но насколько я понял статься не для монстров сайтостроения, которые уже во всем в курсе. Но я не к тому.
                Проджект ОБЯЗАН знать основы БД, разбираться в юзабилити и верстке.
                основы! я тоже знаю основы бд, но этого недостаточно, чтобы не сделать ошибок как в примере топика. про остальные области тоже самое можно сказать.
          • +3
            Это должен делать аналитик со стороны заказчика, если заказывают разработку сайта. Или аналитик со стороны исполнителя, если заказывают решение бизнес-задачи. А оно может состоять и в открытии оффлайнового магазина.
          • 0
            Это должен делать проектировщик интерфейса.
    • +4
      Вы не правы, как и заказчик.
      • 0
        хороший комментарий, я как-то о нем забыл, многое объясняет.
    • +1
      Думаете, что у каждого программиста есть менеджер? Обычно фрилансер — это программист и немного менеджер. Этого «немного» хватает лишь для общения и составления документов. Но обычно не для поверхностного изучения сферы деятельности заказчика.
      • 0
        Этого «немного» хватает лишь для общения и составления документов.

        а большего и не надо.
        Менеджер в программисте нужен для того, чтобы цену отстоять и на телефон ответить, а программист в программисте — как раз для того, чтобы первой картинки не было.
        • +3
          Программист выполняет по спецификации, которую сделал его «недоменеджер»(не оскорбление). Как пример из картинки выше — эти фишки опциональны и у ресурса их могло не быть.

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

            «доработки не по тз бесплатно» — это в идеальном мире. Незначительные вещи в большинстве случаев делаются, если это конечно не зажравшаяся студия.
        • +4
          А чем Вам так не нравится первая картинка? Вполне себе рабочий, простой магазин. Полно случаев когда нужно именно это. Достаточно идиотическая ситуация, если программист будет единолично додумывать что нужно заказчику, попутно увеличив срок реализации в несколько раз. В итоге всё кончится тем, что заказчик, увидев реализацию по второй картинке, скажет «я этого не заказывал» и будет на 100% прав.
          С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
          • –1
            Так в данном случае он не додумывает. Он делает так, как правильно, он же профессионал и знает, что и как будет лучше. Ну, по причине, например, собственной гордости или как это назвать. Если просят сделать кнопку, то ясно, что на кнопке будет текст, и она должна, по хорошем, иметь 3 визуально отличающихся состояния. Заказчик об этом и не думает, а грамотный исполнитель — да.
            Ну, а сделать «наотъебись» в начале проекта никто не пытается.
            • +5
              Почему программист (технический специалист) должен знать как решать задачу увеличения продаж? Конструктор автомобиля должен придумать его рекламную компанию, а конструктор танка боевую задачу для него?
            • +1
              > Он делает так, как правильно, он же профессионал и знает, что и как будет лучше.

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

              > Ну, по причине, например, собственной гордости или как это назвать.

              Я бы назвал эту причину раздутым самомнением.
              • 0
                обсуждаем не интерфейс, а функционал.
                • 0
                  Функционал — это не самоцель.
                  Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
                  Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
    • +5
      И бюджет сто баксов.
      • +1
        я рассчитывал на 150
    • +1
      Это удовлетворение требованиям ТЗ, сформированному на базе бизнес-требований. Заказчик сформулировал бизнес-требования, аналитики выразили их в требованиях к проекту, разработчик составил ТЗ на их основе, заказчик его утвердил. Всё что вы назвали — это термины предметной области, их должна вводить сторона заказчика. Если, конечно, вы берётесь за разработку сайта, а не решение проблемы низких продаж у заказчика.
  • +1
    Отличная статья!

    [мечтательно]
    Вот бы еще перевод на английский, уж я бы нашел ему применение :)
    • +1
      Ну, тут я не силен. К сожалению.
      А вы ТЗ на английском пишете?
      • +1
        К сожалению, вокруг меня обитают люди, которые в принципе не понимают необходимости ТЗ. И по-русски не читают :(
  • +1
    Спасибо.
    Очень полезный текст, вдохновили на написание шаблона ТЗ и дальнейшей его эксплуатации )
    • +8
      Не спешите, у меня их есть…
      Я чуть позже выложу продолжение про шаблоны.
      • +1
        Очень очень хотелось бы взглянуть на ваши шаблоны. Если есть возможность, добавьте в пост пару ссылок на них.
        • +2
          Думаю меня за это выкинут в блог «я пиарюсь», а не хотелось бы.
          Я немножко подготовлюсь и покажу.
  • +4
    Соглашусь с каждым словом. Работать без ТЗ — себе дороже.
    Отличная статья, спасибо :)
  • –4
    Извечная проблема. Потихоньку приходим к её решению. Ключ к этому — магическое слово Agile.
    • 0
      Ну и причем тут Agile? Вас не зря ведь минусуют
      • 0
        Отход от досконального ТЗ в сторону подхода сделали итерацию-заплатили/договорились заплатить. А то, что описывается в статье — водопадная схема работы.
        • +1
          Отход от константы в понятии «объём необходимого функционала» в сторону констант времени и/или стоимости.
        • +11
          Блин, ну и к чему это?
          Я четко говорю, что статья про водрпадную модель. Вы статью хоть читали? Или сразу комментируем?
        • +1
          Сделали итерацию — заплатили, пришла вторая итерация, которая требует для своей реализации доработки/переделки первой, пришла третья итерация, ради которой доработки/переделки первых двух?

          Простите, я не знаком с Agile, просто мысли такие возникли на основе ваших слов. Если нет продуманного и досконального ТЗ, то каждый раз будут доработки/переделки сверху вниз, дико усложняя разработку с каждой итерацией.
          • +2
            Продуманного досконального ТЗ на крупных проектах в принципе не может быть…
            В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
            • +3
              Мечтаю попасть к тимлиду, который будет способен заранее не допустить серьезных ошибок для жизни такого проекта. К сожалению, таких очень немного…

              НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
              1. Предварительное, которое, как ожидалось, размытое.
              2. Детализированное, на каждую итерацию.

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

              И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
              • +4
                То, что Вы написали, никак не противоречит моему высказыванию…
                За исключением терминологии.
                В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
                А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
                Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
                • +4
                  Я даже не думал с вами спорить :) надеюсь сопоставление «терминологии» окажутся полезными не только нам :)
  • +7
    на редкость замечательная статья среди вороха подобных :)
    • +5
      спасибо :)
  • +6
    Какое бы подробное ТЗ не было, всегда найдется возможность сделать работу странным способом, формально заданию соответствующим, но приводящему к неудовольствию заказчика. И наоборот тоже.

    Надо закрывать почаще актами!

    Дизайн-концепция — акт.
    Сверстанные макеты — акт.
    Прототип — акт.
    Все работает на рыбном тексте — акт.
    Наполнение — акт.

    Когда подписан очередной акт и нашелся конфликт со столь прекрасным техническим заданием — разница в понимании за счет заказчика.

    • +2
      всегда найдется возможность сделать работу странным способом


      Наверное можно так сделать, но зачем?
      • 0
        Потому что так кажется лучшим, чем очевидное: «Всё, что не оговорено, выполняется на усмотрение исполнителя» ;) «Лучшесть», кстати, может вовсе не заключаться в оптимизации (по любому критерию) «профита» заказчика. Иногда так можно получить опыт реального применения новой технологии/фреймворка/платформы. Или завалить проект :(
    • 0
      Заказчик может остаться недоволен, если всё к актам сводить, да и сам разработчик где-то может был бы не против подправить.

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

      Тут главное пресечь две вещи: 1) желание заказчика порулить (еще бы, подчиненных, что дух захватывает), 2) многоитерационные творческие флуктации (по-простому говоря, бесконечные правки — пока безымянному пальцу правой ноги дизайн не понравится, в производство не пустят).
  • +1
    Что вы в этом свете скажете о Scrum?
    • +1
      Ничего не скажу. Имхо гибкие методологии они несколько для других задач. Для «обычных» сайтов не уверен в необходимости выбора Scrum.
      • +2
        Верно, зачем применять методологию если она будет в ущерб разработке. А для маленьких проектов скрам действительно будет излишним.
        • 0
          Интересно, что именно вы относите к понятию маленький проект? И как переформулируете высказывание, если этих проектов 5, 10, 20 параллельно…
          • +1
            Я думаю что все могут понять что такое маленький проект и без цифр и оценочных характеристик.
            Параллельность в случае с 10-20 проектами одновременно — это что-то странное. На моей памяти было много небольших компаний, которые разрабатывали сайты-визитки. Такие проекты можно считать маленькими. Но я не представляю как можно одновременно схватиться и вести разработку, допустим, 10 проектов. Это, на мой взгляд программиста, ошибка менеджера.

            Если уйти от декомпозиции и считать пул из 10-20 проектов одним множеством, то можно разработать совершенно новую методологию, наверное.

            Если я неправильно понял вопрос или мой ответ для Вас кажется странным, пожалуйста, сформулируйте задачу конкретнее.
            • 0
              Нет, в целом, в большинстве своем я с Вами согласен, однако я не согласен с подходом «проект маленький -> к черту методологию» (в данном случае я горю про скрам, но на его месте может стоять любая другая)

              То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.

              По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
              • +1
                На этот раз мой ответ прост как никогда — живое общение внутри команда разработчиков во благо любому проекту. Это основной принцип Agile, если ничего не путаю.
              • 0
                Предыдущий оратор неточно выразился, «отметая методологию». Водопад — это тоже методология, развитая и даже стандартизированная на уровне государства.
                • 0
                  Я возможно недосказал. Если я не ошибаюсь, то где-то было красиво сказано waterfall methodology is a description of the natural, and the most dangerous approach to the management of projects, but do not sew the fly's trunk (мог допустить ошибку, ибо по памяти). Другие методологии могут быть эволюционированием или комбинированием. Взглянем на тот же MSF.

                  Это я к тому, что не может проект выжить без применения какой либо методологии и вполне естественно, если по дефолту будет водопад:

                  . Пришел заказчик, высказал пожелания
                  … Команда села, подумала
                  …… Уточнили все детали
                  ……… Сели делать и сделали
                  ………… Сдали.

                  Согласен, при малом опыте у команды — будут итерации, вполне оправданные, но, не хочу накручивать, вполне естественно, что по дефолту упоминается водопадная модель.

                  К тому же, про отрицание всех методологий я не говорил. Я сразу уточнил, что речь идет именно о какой-то конкретной методологии, а не о всех сразу. Это так, если уж цепляться к словам.
  • +2
    Спасибо, отлично написано — легко и весело читать.
    Отдельное спасибо за юмор!
    У себя используем практическую такую же схему ТЗ, что была описана.
    Жалко только, что дошли до нее на своем опыте — набивая шишки.
    • +2
      Спасибо за отзыв. Видимо в самом деле удобная схема, раз мы пришли к похожим схемам. А в чем у вас отличия?
      • +5
        Обязательно указываем какие браузеры будет поддерживать сайт.
        А такие пункты как:
        • 3.9 — наполнение контентом и
        • 3.10 сдача и приемка

        у нас указан в договоре на разработку, т.к. заказчик может пойти с нашим ТЗ к другим разработчикам, а этот пункт касается только наших с ним договоренностей.
        Последнее, кстати, было довольно важным шагом — выделить ТЗ в отдельный этап отношения с заказчиком. Т.е. сначала заказчик оплачивает ТЗ, получает его, и потом уже решает, будет ли он разрабатывать проект с нами.
        • +5
          Про браузеры у меня в сдачу и приемку: «должно работать в таких-то браузерах». В статье не упомянул, вылетело из головы.

          Как вы верно говорите про вынесение ТЗ в отдельный этап! Имхо это очень правильно и нужно.
          • 0
            Зависит от ориентированности ТЗ. ТЗ пишется для двух сторон: заказчика и исполнителя. ТЗ более ориентированное на заказчика, большой ценности не имеет. Это часто приложение к договору. Ну и про детальность в статье уже упоминалось. Глубоко проработанное ТЗ — это этап в ражработке и должно оплачиваться.
          • +1
            > Как вы верно говорите про вынесение ТЗ в отдельный этап! Имхо это очень правильно и нужно.

            Да, вот только далеко не все заказчики маленьких проектов готовы платить за ТЗ. Более того, они сильно удивляются когда узнают о том, что на составление ТЗ потребуется некоторое время.
            • 0
              Они удивляются даже, что его нужно составлять.
            • +1
              Да, полностью согласен. Для маленьких проектов такая схема редко подходит. Хотя и тут бывают исключения — все-таки уж слишком разные попадаются заказчики…
  • +4
    Понравился график высчитывания оптимальной стоимости проекта. Очень просто и в то же время очень эффективно резюмируют необходимость в составлении ТЗ.
    • +3
      Спасибо.
      Да, на самом деле это ключевой момент в обосновании необходимости ТЗ.
  • 0
    Отлично.

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

    Плюс, срок «опытной эксплуатации» подстегивает клиента начать эксплуатацию быстрее. А чем быстрее он ошибки найдёт, тем проще их править.

    Но это нюансы.
    • +3
      Да, я как-то упустил некоторые моменты. Надо будет подправить текст.
      • +2
        Зато очень многие моменты нашли, систематизировали и хорошо расписали. Спасибо.
  • –2
    Вы не поверите, сколько времени я потратил на прочтение и переваривание статьи. Вы говорите о заказчике-исполнителе на уровне отделов компании и ТЗ выступает внутренним циркуляром? Хотел было пожаловаться вам на то, что у вас самое ценное в процессе производства ТЗ — само ТЗ. Вы как продавец пылесосов Кирби или менеджер RationalRose. Такое ощущение от статьи, что вы участник передачи, где нужно показать слово, не произнося его в слух. Потому я зашел на сайт, указанный в вашем профиле и все встало на свои места.

    Что ж, вот вам и живой пример, когда diff — оптимален, а сайт — не будет работать. Я попозже зайду внутрь, но если бы не мое природное задр… тство и уже убитое на переваривание статьи время — не стал бы смотреть даже видео на главной. Переделать! А все потому что diff вы не там мерили, оценивая ценность ТЗ.

    Хотя график и вышил почти идеально. С маркетинговой точки зрения.
    • +4
      А мне понравилось. А я проработал системным аналитиком с десяток лет.

      Но за упорство респект, я обычно как понимаю, что статья — потерянное время тут же её прекращаю читать. Или дочитываю «по диагонали». На что мне секунд 20 не особо жаль.
      • +1
        Да, спасибо, за поддержку. В статье выражен мой опыт, к которому я пришел с потом и кровью и убитыми нервными клеткам и сорванными сроками.
      • +1
        Из графика следует, что стоимость проекта, сделанного по идеальному «дорогому» ТЗ сводит на нет все «хотелки» и «переделки, при этом стоимость предельных „хотелок/переделок“ и стоимость „идеального ТЗ“ — равны, что само по себе заблуждение. Собственно „нафига ТЗ тогда надо“? При этом под стоимостью мы имеем ввиду, как и автор — все чаяния страждущих. Идеальный мир ТЗ, это когда мальчик, с невысокими интеллектуальным потребностями ловит золотую рыбку, просит её сделать ему большое ухо, второе большое ухо и большой нос, а по „завершению проекта“ рыбка в ответ на вопрос, почему тот не попросил ума слышит в ответ: „а можно было?“ И все счастливо расходятся, как в море корабли. Остальное — ниже.
        • 0
          Мне кажется что формула тут не главное. Хотя задуматься стоит. А вот структура ТЗ с объяснениями многим окажется полезной. Я сам пришел примерно к такой структуре для веб ТЗ. И за такую статью некоторое время назад был бы безумно благодарен.

          А если кто не в курсе, то есть понятие Частное ТЗ, которое дополняет основное или часть. Кстати в проектах с дорогими ТЗ именно так и работают.
        • 0
          Из графика следует, что стоимость проекта, сделанного по идеальному «дорогому» ТЗ сводит на нет все «хотелки» и «переделки, при этом стоимость предельных „хотелок/переделок“ и стоимость „идеального ТЗ“ — равны, что само по себе заблуждение.


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

          Про мальчика с ушами я опять не понял :)
    • 0
      Как то ход ваших мыслей мне не очень ясен. Какие отделы заказчиков-исполнителей? Какие пылесосы? Почему сайт не будет работать? Причем тут видео на сайте?
      • +4
        Потому что при соприкосновении ТЗ с реальностью возникают совершенно другие правила игры, каким бы развеселым не был интерфейс конструктора ТЗ. Не каждый заказчик (плательщик) сможет его освоить. Следовательно, идеальное применение проекта — взаимодействие внутри команды разработчик/дизайнер/проджект/аккаунт/продавец, где они выступают клиентами и исполнителями вашего примера, выше. Иначе на одном «обучении» заказчиков можно потерять больше, чем заработать. Т.е. стоимость владения этой системой не так низка, чего кривить душой или позиционирование (простите) не четкое.
        «Пылесос Кирби — это такой пылесос, который решит все ваши проблемы, всего лишь за 100500 рублей, сейчас я покажу как он соберет целый мешок пыли в этой только что убранной комнате».
        У вас на сайте проекта копирайт с 2008-го, ни одного отзыва клиента, ни одного живого человека из создателей системы, ни одного дизайна — успех на лицо. Вы только не подумайте, что это какой-то наезд, скорее добрая критика. Как без видео понять, о чем вы вообще и кто вы такие? Продолжить? Будто бы вы сказали «продолжить»:
        Нафига вам моя фамилия и имя при регистрации, причем в принудительном порядке с подтверждением почтой по ссылке? Если вы решаете проблему, то покажите её решение, а не увеличивайте мою головную боль постоянным переходом из окна в окно ради того, что бы я увидел 156 новых букв, я среднестатистический, у вас на меня максимум 3-5 минут. Больше модальных окон, всяких драг-н-дропов и аяксов, вы же интернет-приложение сделали: на моих многодюймовых задолбаешься головой мотать от главного нода на схеме страниц до компонентов справа, онМаусОва доложны быть все эти тултипы и т.д. Запланируйте Undo или начните с малого — удобный фидбэк, типа «реформал» и живого приглашения потрепаться с вашими продавцами. Проект интересный, весь по ТЗ, это его слабость. У вас типичные недостатки технарских стартапов — решаете свою проблему, а пытаетесь выдать её за вселенскую. Даже не смотря на схожесть моей и вашей модели бизнеса, из которого система и выплыла, мы по разному её решаем, либо убедите, что мне выгодно пойти за вами, а я — дурак, либо не будьте столь категоричны в своем продукте. И все это с искренним пожеланием успеха в развитии этого интереснейшего продукта!
        • 0
          А вот тут эмоциональнт, но по делу
        • –1
          Извините, а нафига заказчику сдалась моя программа? Я её делаю для исполнителей: фрилансеров и студий. На заказчиков я и не расчитываю, это глупо. Так, что ваш комментарий опять мимо кассы.
          • 0
            Тише-тише! Вот вы в статье своей 37 раз слово «заказчик» произнесли. Он у вас приходит, приносит дизайн в конце проекта, платит 100%, а я вас тут сразу просил уточнить, зачем вы пример ТЗ внутреннего «межкомандного» взаимодействия и внешнего, который с договором и оплатой, путаете. А вы — не слышите и продолжаете гнуть свою линию. Потому я и на статью начал наезжать. Посмотрите на сайт продукта. Видите, там написано «КОМУ?» И ниже: веб-дизайнерам, веб-разработчикам, веб-студиям, веб-заказчикам. «Раскашомалаште» пожалуйста последнее утверждение в комментарии вашем про заказчика, на которого вы не рассчитываете под предлогом «это глупо» и отделите мне его от заказчика на вашем сайте и в статье он у вас тусуется плотно именно как плательщик. Не для меня, а для себя и стройности идеи. Видите, я с вами говорю, пытаясь показать какие-то ошибки очевидные, который вы «не рекламируете», а вам кажется, что я куда-то целюсь и хочу попасть, а ваша задача — увернуться. Нет — ну и уворачивайтесь пожалуйста. ) Ниже вам хорошо сказали про различие клиентов. Сравнивать внутренних и внешних, как сравнивать плановую экономику и рынок. Т.е. функционально вы все сделали правильно, даже продаваться программа ваша должна, но как вы о ТЗ рассказали выше — это против вас работать будет на том рынке, куда вы с такой статьей и сайтом выйдите.
            • 0
              Мне трудно вам отвечать, т.к. статья про одно, а ваши комментарии идут в разрез с ней. Мы просто говорим на разных языках и видимо о разном.
  • +3
    Толково разложено по полочкам. Хочу добавить, что очень важно помнить, что есть ТЗ которое пишется заказчиком для того что бы исполнитель понял что от него хотят (назовем это «предварительным ТЗ»), еще это можно назвать расширенным брифом, а есть ТЗ которое будучи основанным на этом самом расширенном брифе пишется уже совместными силами, согласовывается и заверяется как приложение к договору.

    Вот пример брифа, а вот пример технического задания. Как правило любого из вариантов достаточно для того что бы оценить не сложный проект и в последствии разработать более детальное ТЗ, на основе которого будет разрабатываться сайт.
    • 0
      у вас ошибка тут
      pornradio.me/tmp/i/216710656eb1e657bcde39544f7c.png

      не брифинга, а брифа, скорее всего вы имели ввиду.
      • 0
        Вы правы, спасибо, исправили.
    • 0
      Я наверное вас удивлю, но документы «постановка задач» и «функциональные требования» существуют.
  • +1
    Спасибо за отличную статью. Видно, что написано со знанием дела, что в голове некоторое время складывалось, а потом уже было выдано другим. Спасибо за твой труд.
  • +1
    По своему опыту могу сказать, что как бы «хорошо» не было написано ТЗ, итоговый результат на практике отличается сильно. И главное назначение ТЗ — это аргумент разработчика в пользу того, что эта разница должна быть (и будет) оплачена.
    Тем не менее пост весьма нужный. Он расставит по полочкам некоторые вещи в голове менеджера (если таковые его здесь прочтут).

    PS: Свое самое «тяжелое» ТЗ я писал не одну неделю и общее время, потраченное на его написание составило не менее 20% от времени работы над проектом. После этого случая я объявляю цену за написание ТЗ и нередко Заказчик, пытаясь съэкономить, пишет его сам ;)
  • 0
    Спасибо. Сайтами не занимаюсь, но пару важных мыслей о ТЗ получил.
  • +2
    Давно хотел вставить эту картинку. ekimoff.ru/download/job/1.jpg
  • +1
    Есть один маленький нюанс.
    Кто будет писать ТЗ? Заказчик? Я вас умоляю! 90% клиентов знать не знают чего они хотят. Вы сами? Отлично, вариант хороший. Но вы ведь понимаете, что ТЗ будет стоить вам времени, оплату которого никто не гарантирует, да?

    Вот вам ситуация, классическая до банальности — вам стучит, звонит, телеграфирует клиент. И говорит — хочу мол сайт по продаже футболок. Ваши действия? «Уважаемый, мы ждём от вас подробное ТЗ на 20 страницах с эскизами иначе идите нахуй»? Если вы — Артемий Лебедев, то да. Если нет, то у вас есть следующие адекватные варианты романа с клиентом:
    1. 1. Пришлите нам ТЗ на ваш проект по форме 0-16, которую вы можете скачать на нашем сайте.
    2. 2. Опишите пожалуйста подробнее ваш проект и бюджет. По итогам разговора мы составим ТЗ и вышлем вам на согласование. Стоимость составления оценок проекта — 100$
    3. 3. Опишите пожалуйста подробнее ваш проект и бюджет. По итогам разговора мы составим ТЗ и вышлем вам на согласование (идеально-бюрократический вариант)
    4. 4. Покажите пожалуйста дизайн проекта (если заказчик, конечно, не хочет сайт под ключ)
    5. 5. Покажите пожалуйста 2 или 3 сайта в интернете, которые больше всего вам нравятся и соотвествуют вашим представлениям о том, как сайт должен работать

    Рассмотрим эти ситуации подробнее:
    1) Всё круто, но вы потеряли процентов 80% клиентов, которым ни в жисть не интересно составлять какие-то там ТЗ по форме.
    2) Отлично, но вы потеряли 95% клиентов.
    3) Идеальный вариант для студии, работающей в ключе «поставщик-исполнитель-грузополучатель». Фейл для тех клиентов, которым нужна примерная стоимость ваших услуг ± 100$ прямо сейчас.
    Из тех, кто согласился на схему с ТЗ вы отсеите не меньше половины обратившихся. А с каждым ТЗ вы потеряли 2-3 часа своего времени и столько же времени вашего разработчика на оценку.
    4) и 5) — основная на мой взгляд линия поведения при беседе с заказчиком.
    Я не соглашусь с тезисом автора статьи о том, что ТЗ и дизайн не коррелируют. Практика показывает, что в нашем бизнесе дизайн и есть ваше самое подробное и полное ТЗ. Именно на нём виден ВЕСЬ оплаченный функционал. Так же, как и на примере понравившегося сайта (хотя тут есть свои подводные камни).
    В общем и целом формализацию процесса в нормальных условиях можно свести к следующему:
    1. 1. Если у вас нет дизайна — вы пишите смету. Она будет и вашим гарантом, и путеводной звездой для клиента. Смету составить проще и быстрее, чем полное и красивое ТЗ.
    2. 2. Вы профессионал. И должны закладывать в каждый проект возможность внести любые правки бесплатно в некотором оговоренном объёме. Например мы вносим в условия работы от 4х часов бесплатных правок любого характера (в зависимости от проекта)
    3. 3. Обязательно оговорите момент про доработки. Объясните, что «Вот тут баннер добавить» будет стоить ваша_ставка * трудозатраты по задаче. Кстати, после таких объяснений есть шанс, что клиент таки инициирует работы над ТЗ.
    4. 4. Подчеркните тот факт, что вы правите баги бесплатно как минимум 2-3 недели после сдачи проекта (но лучше править их бесплатно 2-3 месяца после сдачи), и тот факт, что вы всегда готовы дописывать проект за отдельную плату

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

    Если кого заинтересовали детали подхода — могу себе закинуть в план статью на эту тему.
    • +3
      Я проходил мимо, но вас понял. Пишите. Сейчас тут образовалось две секты: «рационалы» и «эмоционалы», при чем и те и другие считают друг-друга..., но при этом зарабатывают одни и те же деньги на одном и том же рынке продавая совершенно разные продукты. Вы теперь на контроле. Ждем-с! )
      • 0
        Кстати, ваш комментарий выше мне показался весьма адекватным. Рационализм и практицизм технарей (а ведь я и сам технарь в большей мере, хоть и закидываю удочки в юзабилити и apple-style дизайн :) уже давно «не рулит». Просто люди таки начали понимать, что компьютер и софт для него были изобретены для упрощения решения задач, а не для того, чтобы пользователь год учил новый способ взаимодействия с гипер-крутым аппом, написанным по самым последним парадигмам ООП. Пользователю в общем-то плевать на язык, парадигмы и т.д. Он будет взаимодействовать с интерфейсом и дизайном ВСЁ время работы с программой или вебсайтом. Значит это камень преткновения, и абстрагироваться от дизайна в ТЗ — это весьма опрометчиво. Собственно проект автора статьи — наглядный тому пример.
        • 0
          Если дизайн всех страниц у заказчика уже есть, то по нему и можно писать ТЗ детальное. Если нет и это не наша задача, то или ждём дизайна, или уточняем функциональные требования сами, а потом наше ТЗ (выжимки из него) пойдут дизайнеру.
    • +1
      Я попробую выразить свое видение процесса работы с заказчиком.

      1. Приходит клиент и говорит «Я хочу сайт».

      2. Мы выясняем, что есть у клиента «Что у вас есть по сайту? Какой сайт, есть ли ТЗ, бриф или похожие сайты? Если есть — хорошо, если чего-то нет или нет вообще ничего, тоже не страшно, давайте поговорим про то, что вы хотите.»

      3. Рассказ клиента про сайт.

      4. Мы сразу даем начальную очень грубую оценку с погрешностью от -50% до +100% Если масштаб цен подходящий, мы выясняем все требования, пишем ТЗ, называем точную стоимость и сроки.

      5. Написание, утверждение ТЗ

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

      7. Утверждается ТЗ, и параллельно идет прорисовка всех страниц дизайнером.

      8. Вступает в работу программист и верстальщик. Программист может начать работу несколько раньше, когда уже понятна общая картина.

      9. Завершение работ, исправление верстки, багов, пожеланий, выкладывание на хостинг клиента.

      В схеме бывают отклонения, по обстоятельствам.

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

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

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

      Т.е. ТЗ уменьшает простои, паузы; дает предсказуемость и возможность лучше планировать деятельность.
  • –1
    Часто сталкиваюсь с такими программистами, которые рисуют как на первой картинке. От таких лучше держаться подальше — это не профессиональные разработчики. Поясню.
    Как часто вы приходя в салон с фразой: " мне нужен автомобиль " слышите: " вот есть Жигули "? Как часто выбирая тур вы слышите: " вот отличный двухзвездочный номер " и т. Д
    Тот, кого вы описали первой картинкой — индус, к индусу нужен прораб, нет смысла учить индуса тому чему он сам не научился до вас.
    • +4
      Ну если речи о фрилансе, то это скорее:

      — У меня есть две тысячи рублей и три бутерброда. Где мне забрать мой BMW?

    • +2
      Если программист рисует как художник, ему за 30 и он — счастлив, ему нужно перестать курить психоактивные вещества и заняться поделками на node.js, или забросить программирование полностью. Как говорил один хороший человек — нельзя одной рукой держаться и за сисю и за писю. Так что если отличный программист рисует абстрактную живопись — это не страшно.
      • 0
        Не страшно если его программирование не зависит от его рисунков.
  • 0
    А стоимость проекта от детализации ТЗ не зависит? Или Вы рассчитываете не почасовую оплату, а за проект целиком?
    Из моего опыта как раз удобнее фиксировать время и бюджет, а функционал варьировать.
    • 0
      Я говорю о фиксировании и цены, и функционала.

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

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

      Для разработчика, конечно идеальный вариант — почасовая оплата, только мало кто из заказчиков согласится на условия типа таких: «мы будем работать по 10 уе/час, пока всё не сделаем».
  • +1
    Я недавно задумал один небольшой проект и в роли заказчика решил написать ТЗ на веб-сервис. Знаете, это отличный способ для заказчика разобраться в собственном проекте. Сделать из Идеи что-то более близкое к реализации. Понять какие-то нюансы, скорректировать бизнес-процессы, даже внести какие-то изменения в Идею. Очень полезно, я считаю.

    PS: Кстати ТЗ еще ждет своего исполнителя ;)
    • +2
      Это хороший и правильный комментарий.
  • 0
    Достойная вдумчивая статья. Было бы вообще шикарно, если бы она «подкрепилась» не менее достойным примером.
  • +1
    Большое спасибо за статью!
    Нашёл много новых пунктов применительно к своему ТЗ на создание сайта. Хотелось бы услышать ваши размышления насчет ТЗ на продвижение.

    И, по-моему, это самый быстрорастущий топик в избранном у хабраюзеров за всю историю! Автор — молодец! Затронул действительно важную для каждого из нас тему. Спасибо!
    • 0
      Спасибо за хороший отзыв. Продвижением серьезно не занимался, не скажу.
  • 0
    Хорошоая статья. Я думаю она показана к прочтению как заказчиком так и исполнителем.
    Чтение статьи и комментариев напомнило мне недавно прочитанную книгу о роли творчества в программировании и вечное противостояние между формальным и творческим подходам. Сильный перегиб в ту или уную сторону, как правило фатален, поэтому, всегда стоит искать компромисс, а это, к сожалению, не всегда просто.

  • 0
    Пропущен важный момент — стоимость самого техзадания, на его написание тоже нужно потратить время, и иногда немало + заказчик может взять ваше ТЗ и потом спокойно уйти к другим разработчикам.
    • 0
      Мы делаем так: в приложении к договору прописываем стоимость и сроки разработки технического задания, к которому приступаем после предоплаты, а в самом договоре пишем, что ТЗ после утверждения сторонами является неотъемлемой частью договора. Обычно его оформляем как Приложение №2. В принципе, тут тоже есть некоторая несуразица, но по крайней мере мы уверены, что клиент не убежит с нашим ТЗ к другому. Пока никто не убегал. :)
    • 0
      Стоимость разработки технической документации. Часть I
      За статью либо хорошо, либо ничего. Предпочту ничего.
  • 0
    Привет из 2016-го) Большое спасибо за статью!

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