Comments 58
Красавчик! Бодро пишешь! Читать очень интересно и увлекательно.
Сложный вопрос.

Если мы говорим о реальном ТЗ на турбазу, то чистой работы 8-12 часов. Сам процесс длился более недели — тормозило общение с заказчиком.

Основное время заняло описание бронирования, т.к. остальное было сделано раньше.

Реальное ТЗ было не такое красивое как в статье, тут я постарался навести лоск. Реальное ТЗ затрагивало пару дополнительных моментов, но второстепенные страницы были прописаны хуже.
Это я просто что бы оценить стоимость его разработки :) Ведь много заказчиков, которые придя для разработки сайта для турбазы узнав, что 25% стоимости сайта будет стоить написание ТЗ, могут простой уйти и вобще не связываться с написанием ТЗ. А пойдут к другому, кто им на Joomla сделает сайт за 5000р, а не за 30 000 :)

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

По поводу джумлы, я вот долго по этому поводу думал, а нафиг ТЗ на джумловые сайты? В конце концов пришел к такому выводу. Джумловые сайты дешевы т.к. они шаблонны. И отступление от шаблона на шаг вправо или влево может сделать разработку просто не рентабельной для исполнителя. Соответственно на шаблонные сайты нужны шаблонные ТЗ, которые стоят так же дешево как сайты на джумле, но страхуют даже от мелких хотелок, которые могли бы поставить под угрозу рентабельность.
Всё, что описано в статье — и должно. Это пример отличного технического задания. Я решил к терминологии «придраться»)
Но случай частный на самом деле. Зачастую можно обходиться более простыми спецификациями, характерными для Agile, scrum и им подобным методикам разработки ПО.
Да, я согласен иногда можно и более короткими спеками обойтись. Но в данном случае я старался показать хорошее, по своему мнению, тз.

В реальности думаю ТЗ в основном будут проще.
Вам удалось показать очень хорошее ТЗ, статья удалась, спасибо)
Добавил в избранное, буду по мере необходимости подглядывать)
Если немного допилить вашу систему, то можно сайты прямо из неё генерировать ))
и можно будет вешать вирусную рекламу: «Запилю сайт за 3 дня», а клиенты будут приходить и говорить «Сайт мне запили, быстро»
В экспериментальном режиме я пробовал. Причем генерить можно на разных движках…
Нет, реальных сайтов нет, это пробы. Тестировал на rails и cakephp геренацию скафолда на основе описанных структур данных. Оно дает не сайт готовый, конечно, но всё равно здорово :)
Прикольная штука для прототипирования, зарегался, если будет удобной, то готов платить за нее.
Вы не представляете как вы меня радуете своими словами. Я аж готов забыть про то что сейчас вечер пятницы и сесть фиксить баги и допиливать новые плюшки :)
Я последние 2 недели искал удобный для себя инструмент для составления подобных ТЗ или прототипов. То что мне подходило либо работало под маком, либо под виндами, а у меня Ubuntu. Несколько вечеров убил чтобы протестить разные сервисы из ранее найденных топиков на хабре.

Ваш показался наиболее симпатичным, но, пока его не пощупал. Желаю успехов при его развитии. Сегодня вечером если не убегу отмечать пятницу, буду тестить azalo.net
Спасибо за отзыв, будет очень интересно услышать ваше мнение.
Насчет «ТЗ на Дропбоксе» — уберите, а то хабраэффект приведёт к бану вашей учетной записи. В пользовательском соглашении запрещено использовать ДБ как полномасштабный хостинг файлов.
UFO landed and left these words here
UFO landed and left these words here
Это странная любов ФФ к сертификатам от startssl
Даже не знаю кто виноват ФФ или startssl…
Немножко спалю тему.
ТЗ, тем более такого уровня, предполагает договор, приложением к которому оно собственно и будет являться.
А если есть официальный договор, то вступают в действие всякие ГК и прочие законы, которые у нас важнее договора.
Так вот, по этим самым законам исполнитель обязан за свой счет устранять недостатки (читай фиксить баги) в выполненных им работах в рамках ТЗ в течение двух лет после сдачи-приемки.
Так что ваши 30 дней на доработки это конечно хорошо, но не проканает, первый же грамотный юрист вас завернет — и хорошо если на этапе согласования, а не в суде. Лучше заранее сделать красивый жест и написать большими буквами «гарантия 2 года».
Может быть и так, не спорю, т.к. не знаю. Но я тоже немного спалю тему, текст про 30 дней поддается редактированию на ваш вкус. Т.е. его не трудно исправить на корректный и им пользоваться.
Ну я исходил из предположения, что годный продукт должен, нет — просто обязан, давать корректный результат при настройках по-умолчанию. ТЗ — это в первую очередь юридический документ, который потенциально будет рассматриваться в суде, поэтому оно должно не противоречить законам.
Впрочем, если вы считаете иначе…
Не, я с вами согласен, я такой тонкости про два года не знал, и у меня «прокатывало». Да и потом, возможно, это разница в законодательствах разных стран сказывается.
В Вашем ТЗ есть логика (обработка данных), и на мой взгляд, необходимо сделать еще один раздел — Приёмо-сдаточные испытания. А в нем расписать алгоритм тестирования системы бронирования. Т.е написать один или несколько сценариев действий пользователя и реакцию системы на них.
Еще один момент, который необходимо отразить в ТЗ — документирование системы. Если У Вас не описан этот пункт, то заказчик имеет право потребовать с Вас полный комплект документации, включая руководство программиста.
Мы обычно вписываем туда руководство оператора (на какие кнопки нажимать, чтобы управлять контентом) и руководство системного администратора ( как развернуть систему, основные настройки )
Опционально делаются: GuideLine дизайнера ( описание шаблонов, допустимых шрифтов, цветов, размеры картинок, шаблоны баннеров и.т.д. ), Руководство дизайнера (Что и где нажимать, для того, чтобы внести изменения в дизайн) Руководство программиста ( описание доступных API и интеграционных возможностей ).
Иногда отдельно требуются руководств по отдельным подсистемам.
В принципе вы правы, можно сделать еще раздел, это не сложно. Просто мне кажется что тестирование системы, это отдельный документ по объему сопоставимый с ТЗ.

А про документацию, вы совершенно правы, добавлю кусочек текста.
Прототип www.axure.com/ + комментариев достаточно для ТЗ. Все остальное обычно идет от ЧИСТОЙ бюрократии и ненужного формализма.

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

А ТЗ на верстку в полной мере можно сделать только после того как будет получен дизайн.
В общем я тут высказал свое мнение habrahabr.ru/post/138749/ на этот счет. Если коротко, то нет фомального способа определить сделан дизайн или нет.

Сам прототип соответсвует прототипу, но он же не может быть дизайном? Его не приймут как как дизайн, хотя соответсвует прототипу на 100%.
И опять же задание тезхническое, а не художественное. Представляете техническое задание на картину или стих?
Да. Запросто. Размер холста, тип красок — например.

Прототип это минимальный, а не достаточный критерий.
Only those users with full accounts are able to leave comments. Log in, please.