Что такое «хорошее» ТЗ на сайт?

    caricat.gifЯ могу припомнить на удивление мало материалов, посвященных проектированию сайтов и программ на русском языке, написанных русскоязычными авторами. Этому способствует и преимущественно экспортно-ориентированная разработка (оффшор) и отсутствие массового опыта создания информационных продуктов в нашей стране.
    Надеюсь, что эта статья пригодится тем разработчикам и IT-менеджерам, кто ощутил перед собой проблему составления качественных документов на разработку сайта. Документов, которые кроме испорченной бумаги были бы хоть чем-то полезны.

    Вводная


    Зачем составлять техническое задание (ТЗ) на сайт?
    Какую бы методику разработки вы не использовали, и какого бы размера ни был ваш сайт, вы в любом случае столкнетесь с вопросом: «А когда мы будем заканчивать работу, то как мы поймем, что мы ее действительно закончили?» В разработке как ПО, так и любого сайта частая проблема — никто не видит конечной точки. С одной стороны можно сказать, что конечным видением проекта должен обладать проектный менеджер. Но если конечный продукт совпадет с образом менеджера, но не совпадет с ожиданиями клиента? А если за время проекта меняется 3 менеджера?
    Следствие закона Паркинсона «девяносто-девяносто»:
    Первые 90% кода отнимают 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки.
    Из книги А.Купера «Психбольница в руках пациентов».


    ТЗ это не просто список требований, это документ. Если договор регулирует процесс организационных и финансовых взаимоотношений, то ТЗ регулирует процесс разработки и конечный результат.
    В этом случае не имеет никакого значения большой разрабатывается сайт или малый. Проблема рассогласования ожиданий может возникнуть в независимости от объема затраченных средств, вот только последствия могут быть разными.
    О чем эта статья.
    Эта статья о том, что может пригодиться в процессе написания ТЗ на сайт, а также что будет уж точно сделать желательно. Но эта статья не о том, как надо писать проектную документацию. В конечном итоге главная задача проектировщика не написать классный документ, а спроектировать сайт. Хороший документ лишь отражение подхода и уважения ко всем участникам разработки.
    Добавлю ограничения.
    Всегда когда я говорю о написании ТЗ, то имею в виду, конечно же, каскадную методику разработки. В случае других вариантов (например, экстремальное программирование) составляются другие документы и часто по другим принципам. Это — раз.

    Стоит разделять ТЗ для малых и больших сайтов. Это — два. Различия маленьких и больших проектов заключаются не в объеме документа на выходе, а в процессе их разработки. Если у вас всего 4 человека в проектной группе, все давно знают друг друга, то можно предполагать отсутствие формализма. Если же разработкой занимаются несколько «отделов», а проектная команда состоит из более 10-ка (до бесконечности) сотрудников, то управлять этой ордой может только процесс. Процесс рождает формализацию, а формализм накладывает свой отпечаток на формат документации.

    По сути, толщина документов зависит от сложности процесса в больше степени, нежели от размеров проекта.

    Мы будем следовать самому сложному пути.

    ТЗ отвечает на вопросы


    ТЗ изначально создается для нескольких участников разработки:
    1. Разработчики проекта (дизайнеры и программисты).
    2. Проект-менеджер.
    3. Клиент.
    4. Бюрократы (они могут не участвовать в проекте, но на них тоже надо рассчитывать).

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

    Итак, на какие вопросы отвечает ТЗ.

    Для кого создается сайт и для чего?


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

    Как будут решены задачи заказчика и пользователей?


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

    Как будет проходить создание проекта?


    Как я уже писал выше, ТЗ (а может и отдельный документ) иногда описывает процесс разработки проекта. Это совершенно необходимо, если принять во внимание, что сайт может разрабатываться по отличной от принятой в компании методики разработки, которая как правило не описывается ни одним документом. Можно сколько угодно долго мучить себя мечтами о стандартизации по ISO, но что показать дотошному заказчику?
    По ГОСТу предусмотрен отдельный раздел «Этапы разработки системы». В таком разделе можно не слишком подробно описать процесс и установить майлстоуны.

    Что будет приниматься на выходе?


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

    Что требуется для дальнейшего запуска проекта?


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

    Из чего состоит ТЗ


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

    Общая информация


    Первая часть ТЗ содержит введение и общую информацию о документе и проекте в целом. Введение надо написать один раз и на всю жизнь. Как правило, там пишутся на столько абстрактные фразы, что в каждом новом проекте надо лишь подправить пару слов.

    Общая информация включает в себя:
    • Информацию о заказчике и исполнителе.
      Обязательно указание ответственных лиц с каждой стороны. Указываются документы, на основании которых производится разработка. Как правило, подобным документом является договор. Статус текущего документа и конфиденциальность.
    • Назначение проекта.
      Указывается: для чего будет использоваться полученный продукт.
    • Цели создания и задачи, которые должен решить ресурс.
      С одной стороны это довольно короткий раздел, но по важности проработки он занимает первое место. Если цели и задачи поставлены не четко и неизмеримо, то может быть довольно сложно им следовать.
    • Описание аудитории проекта.
      Критично важная информация для разработки хороших и правильных сайтов. Ясно, что информацию об аудитории не только надо правильно собирать, но еще важнее это уметь этой информацией пользоваться.
      Описание аудитории должно содержать не только информацию, которую так любят маркетологи (демография, потребности, сегментирование и т.п.), но также информация которая пригодится дизайнерам и проектировщикам: какие задачи решает пользователь, какие его цели в работе с сайтом, что его привлекает. Алан Купер рекомендует описывать аудиторию сайта не в виде безликой массы, а выделять персонажи — описывать собирательный образ конкретных людей.
    • Термины и определения.
      В большом документе вы сможете употребить огромное количество терминов и сленговых выражений, которые редко понимают специалисты по маркетингу или крупные руководители. Они могут читать этот документ, поэтому лучше предусмотреть для них список определений. Я не тешу себя надеждой, что этот список хоть раз в жизни был прочтен, но зато я могу всегда сослаться на него.

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

    Рамки проекта


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

    Информационная архитектура и интерфейс


    Раздел посвященный информационной архитектуре (ИА) сайтов не стандартизируется ни одним известным стандартом (автору такие пока не знакомы). Но любой, кто разрабатывал сайты, понимает, что ИА это чуть ли не главное, что нужно знать для разработки сайта. ИА определят как будет выглядеть и работать сайт с пользователями.
    Для описания ИА потребуется описывать сверху вниз:
    1. Структуру сайта. Это так называемые высокоуровневые прототипы.
    2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
    3. Опись контента. Табличное описание содержания каждой страницы сайта.


    Структура сайта
    Карта сайта выполняется графическим способом в одной из известных нотаций: Visio или Garrett. Я советую именно рисовать карту сайта, потому как в этом случае полученная структура получается наиболее наглядной и удобной в дальнейшем использовании. С одной стороны может показаться, что в виде списка написать карту сайта будет куда проще, но когда вы сами задумаетесь над связями различных областей сайта между собой, вы волей неволей начнете чиркать квадратики на бумаге.
    О том, как можно рисовать структуру сайта с помощью нотаций, используя Visio написаны целые статьи, поэтому останавливаться на этом не будем. Статьи написаны, правда, на английском, но вы легко сможете воспользоваться ими.

    Не забывайте присваивать номер каждой отдельной странице карты сайта. Это потребуется на этапе описания контента.

    Полезные советы при рисовании карты сайта:
    • Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг то друга. Это поможет читабельности карты.
    • Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
    • Выравнивайте «квадратики» страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
    • Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
    • Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
    • Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

    Пример карты сайта
    Пример карты сайта.
    Карту сайта я обычно помещаю в раздел «Приложения». Как правило, она на столько большая, что поместить ее посреди ТЗ становится не реально.
    Шаблоны страниц
    На уровне карты сайта каждая страница представляет для нас только «квадратик» на листе бумаги. Для дизайнера, верстальщика и программиста этого недостаточно, чтобы разработать сайт. Надо еще знать наличие и расположение блоков информации и функций на страницах сайта. Поэтому мы переходим к шаблонам сайта. В идеале каждый квадратик должен быть детализирован до схемы каждой отдельной страницы. Это прототипирование сайта. Использование прототипирования зависит от принятой схемы работы в компании-разработчике, но стоит признать, что это становится для заказчика крайне не дешево.
    Для упрощения выделяют ряд шаблонов интерфейса сайта, которые описываются вслед за картой сайта.
    Описание шаблонов состоит из 3х частей:
    1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
    2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
    3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

    Оговорка: шаблоны интерфейса сайта не надо путать с шаблонами в программной системе, на которой будет работать сайт. Шаблоны интерфейса описывают количество типовых страниц, достаточное для дизайна сайта.
    wireframe.gif
    Пример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).
    Описание контента
    Самая долгая и нудная часть работы. Описание контента должно включать в себя перечень всех страниц сайта с точным указанием размещаемого на каждой странице текста, картинок и т.п. Также там указывается какой шаблон используется для данной страницы (см. выше). Я рекомендую использовать для этого таблицу.
    Далеко не всегда на момент написания ТЗ можно с уверенностью знать какой будет контент на сайте: точное количество информационных страниц, размещение графической информации, поэтому не думайте, что в данном разделе приводится самое точное описание. Часто это не так. Но если вы опишите требуемый контент на данном этапе, то далее проект-менеджер на его основе сможет составить план поставки контента и оценить объем внесения этой информации на сайт. У клиента же всегда перед глазами будет перечень того, что ему потребуется подготовить и отредактировать.
    Хорошее описание контента залог спланированной работы на этапе запуска сайта и внесения информации.

    Функционал


    Описание функционала сайта в техническом задании один из ключевых разделов. В особенности это касается сайтов с большим процентом программных работ: электронная коммерция, онлайн-сервисы и т.п.
    Хороший пример описания функционала дает ГОСТ. Рекомендую держаться стандарта при описании функционала разрабатываемого в рамках сайта программ. Должны быть описаны: общая система, общие функциональности подсистем и модулей, взаимосвязь подсистем и модулей между собой и, наконец, перечисление всех функций модулей с более или менее подробным описанием их работы. Для каждого модуля должны быть расписаны объекты, которые создаются или используются в работе программы.
    Можно также описывать структуру базы данных, предварительные алгоритмы работы, но само по себе техническое задание этого не требует. По ГОСТу подобные подробности должны описывать в дальнейших документах: эскизный и технический проекты.
    Иногда при разработке крупных сайтов приходится долго посидеть, чтобы описать весь функционал внешней и внутренней части сайта. Некоторые разработчики против такой детализации. Они считают, что функционал надо описывать поверхностно, чтобы «клиенту было понятно». Полная ерунда! По опыту могу сказать, что лишней детализации не бывает. В случае проблем в проекте менеджеры проекта с обоих сторон становятся редкостными буквоедами! Они вычитывают ТЗ вдоль и поперек стараясь доказать свою правоту. Поэтому если функционал в ТЗ прописан общими словами клиент все равно заставит сделать то, что ему надо.

    Требования


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

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

    Прочее


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

    Что дальше?


    ТЗ составлено, подписано и поступило в работу. Что дальше? Заканчивается ли работа с ним на этом этапе? Нет.
    Проект далеко не всегда идет по заранее запланированному пути. Мы стараемся что-то улучшить, изменить, часто меняются требования заказчика. Техническое задание это документ, а не скрижали. С изменением требований к проекту должно меняться и техническое задание. Обычно это делается дополнительными документами со списком изменений. Естественно, они составляются только в том случае если это действительно необходимо, на практике встречается редко.
    Также вы должны быть готовы, что в процессе глубокого изучения ТЗ всеми участниками разработки в процессе работы над проектом будут найдены ошибки. Количество ошибок в большом документе прямо пропорционально его объему и обратно пропорционально времени затраченному на его написание. Т.к. времени постоянно не хватает, следует ожидать, что ошибки в ТЗ будут возникать.

    В сухом остатке.


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

    Надеюсь, что информация будет полезна широкому кругу читателей.

    Полезные ссылки:

    Юрий Шиляев, проектировщик сайтов, консультант.
    Директор минского офиса компании
    Artics Internet Solutions.

    Оригинал: yuri.shilyaev.com/archives/2007/03/21/356/chto-takoe-%c2%abhoroshee%c2%bb-tz-na-sayt.html
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 88

      +5
      Спасибо. Уже в избранном.

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

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

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

        В общем, сплошные компромисы )
          +3
          В таком случае надо держать в прайсах строчку "Предпроектное исследование". По умному надо много вещей делать. Это большое подспорье и больша работа.
            0
            Строчка "предпроектное исследование" обычно пишется в столбце "Расходы" исполнителя.
            Столь подробное исследование на предпроектном этапе, конечно, накладно, но многое изучать, рассчитывать и описывать все равно приходится на стадии переговоров, результат которых не всегда известен.
              0
              Ммм... А как при этом выглядит весь проект в целом? С точки зрения трудоемкости написания ТЗ и последующей реализации?

              Приходилось участвовать в проектах, где постановка задачи занимала в 2-3 раза больше ресурсов, чем реализация. И, соответственно, постоянно объясняться с клиентом, который видел только реализацию (т.е. 1/4 всей работы) - в том числе, объясняться и по финансовым вопросам...

              Так вот, какие есть возможности составить более-менее полное ТЗ (и тем самым определиться с трудоемкостью проектных работ), при этом не вывалившись за какие-то разумные рамки (ну, скажем, в идеале 10-20% от реализации)?
                0
                На мой взгляд, затраты на составление ТЗ (с подробной проработкой функционала, определением средств реализации и бюджетированием) редко занимают 10-20% от общих затрат на разработку, обычно больше.
                Всю работу менеджера проекта и аналитиков оцениваю в 40-60% затрат, а если вебсайт нестандартный, то и 80% сил/времени может уйти. Если после этого программисту работать будет легко и результат предсказуемым окажется, то затраты оправданы.
                Клиенту обычно это преподносится как разработка концепции, аналитика, разработка архитектуры. Что из этого делать до заключения договора, а что после - каждый раз индивидуально надо смотреть. Можно много времени потратить на предпроектную подготовку, а потом клиент передумает. Это риски.

                Под впечатлением этой статьи я свой опыт минимизации затрат на ТЗ описал, но он годится только для хороших, разумных клиентов. http://audioweb.ru/webdesign/mindmap-for…
                  0
                  Другими словами, можно-таки документировать самые важные вопросы (чтобы хоть приблизительно увидеть размер проекта), и затем составлять смету с каким-то запасом на все остальное? В принципе, я и сам к этому склоняюсь понемногу...
                    0
                    Пардон, конечно, но 80% затрат на проектирование сайта... это какой-то анриал. Если опустить из ряда вон выходящие проекты, то вообще тратить на ТЗ больше 20% бюджета разработки сайта неоправдано.
                    Невозможно всего всегда предусмотреть. В проект всегда закладываются риски, чтобы успеть все сделать, даже если что-то оценили не верно изначально.
                    Вот у нас есть бюджет 10Х. На ТЗ потратили 8Х. Ну пусть даже 6Х. Где гарантия того, что на реализацию после получения ТЗ хватит 4Х?
                    А если пока писали это ТЗ на 6Х, скажем 6 месяцев, появился проект, который дублирует ваш, то что делать? Переписывать ТЗ и просить у заказчика еще минимум 2Х, чтобы что-то переделать? Когда не написано еще ни строчки кода. Заказчик будет счастлив. Мы описали несуществующую и ненужную систему.
                    А какой из этого выход?
                      0
                      Гибкие методики разработки.
                        0
                        Зафиксирована подсказка из зала!
                        Очко засчитываетс телезрителям, покиньте клуб! ;)))
                    0
                    Да, умножить оценку на 2.
                  0
                  Это "предпроектное исследование" и входит в цену ТЗ.
                  +2
                  А что такое полноценное ТЗ? Оно везде разное.
                  ТЗ не должно описывать все. Оно должно описывать все, чтобы не сделать больше. :)
                    +4
                    Вообще ТЗ - такой расплывчатый документ и надо иметь общее понимание его предназначения.

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

                    Я в ТЗ включаю:
                    1) Общие сведения
                    2) Основание для разработки (ссылка на договор)
                    3) Назначение разработки (цели и задачи)
                    4) Требования:
                    - к функциональным характеристикам (для сайта - общее описание структуры и интерактивных элементов);
                    - к надежности;
                    - условия эксплуатации;
                    - к информационной и программной совместимости;
                    - к поставке;
                    - к документации.
                    5) Стадии и этапы разработки (этапы и содержание работ)
                    6) Порядок контроля и приемки

                    Структура сайта и шаблоны страниц с той степенью проработки, что у вас в статье, это уже скорее часть эскизных или технического проекта (по госту), или Functional Requirements, а может и Software Requirements (по RUP-у).

                    У вас получается, что ТЗ - это такой супер-документ про "все сразу". Не понятно, когда его разрабатывать: до подписания договора и подписывать вместе с договором, или уже после подписания договора, но тогда что приложить к договору, чтобы ограничить обе стороны?
                      +3
                      Читайте выше: Мы будем следовать самому сложному пути.
                      В некотором роде может быть и есть пересечение с эскизным проектом, который может вообще не составляться, согласно тому же ГОСТу. Но технического точно нет. Там надо описывать алгоритмы решений.
                      Просто когда я работал с большими государственными структурами, то подобные документы были просто необходимы!
                        +1
                        Да с государственными структурами главное одно - побольше бумажек и с нужными людьми сходить в баню. :)

                        Думаю в составе и содержании проектной документации многое зависит от механизма продажи и клиента.
                          0
                          Чем больше потенциальных проблем от клинета, тем более внушительным и разноплановым должно быть ТЗ. Это своеобразная защита от клиента. Как в законе: шаг влево, шаг вправо "растрел".
                            +1
                            Заключить договор и срубить бабок за халтуру - одно, построить систему - другое.
                            Система заключения договоров с госструктурами не повод делать плохие ИТ системы для государства.
                            Если, конечно, не работаешь на другое государство:)
                              0
                              Я не знаю примеров, когда был просто выбран или "выбран в результате тендера" (тендер - в отдельных бОООльших кавычках) адекватный подрядчик для разработки IT-системы по госзаказу.
                    –2
                    Всегда стараюсь делать сайты со свободной структурой, чтобы не зажимать владельца сайта заранее заданными разделами. Нужен новый раздел? Создай его и работай дальше.
                    Порадовал в статье пункт 3 - Опись контента. Табличное описание содержания каждой страницы сайта.
                    Ага, бегу-бегу. Сейчас переделываю сайты - ulgov.ru 6000 страниц, gz.ulgov.ru 4500 страниц, уже предчувствую опись контента.
                      +1
                      думаю если категоризация есть - то можно описать только её.
                      статья же не о том как надо делать постоянно, а лишь пища для размышления, шаблон составления ТЗ и за шаг влево / вправо вас не расстреляют ;)
                        0
                        Про категоризацию совершенно верно.
                        +1
                        Не опись контента это не про то.
                        Опись контента, это то, что вы будете создавать или набивать сами. Тут отношение должно быть как во фруктовой лавке: арбузы пордаются штуками, а изюм килограммами.
                        Описывать 6000 страниц подробно может быть страшно, но это же опять смотря какая информация м какой процесс. В процессе создания компьютерной игры люди порой создают 3000 анимаций. И ничего все описывают. ;)
                        +2
                        к сожалению даже на небольших сайтах ТЗ необходимо.
                        у меня были случаи когда по пунктам сдаю проект, а мне говорят - пользователю неудобно делать так...
                        сделай. что бы было удобно пользователю. С одной стороны понятно что заказчику не нравится, но в основном маленькие проекты это фриланс, где оплата фиксированная и такой проект может затянутся на гораздо большее время работы за бесплатно :(
                          0
                          На этот случай у нас есть готовые наработки (стандартные решения). Если клиента оно устраивает он может посмотреть на демо-сайте как это работает и подхождит ли ему.

                          Если клиент хочет все сделать "под себя", то конечно ТЗ ну или по крайней мере описание функциональности надоделать.
                            0
                            да, это был мой первый опыт работы фриланса и я не поставил строчку "используя станадртные решения для этой CMS", за что в принципе и поплатился :)
                            но отрицательный опыт - тоже опыт :)
                        0
                        пасиб, в мемориз!
                          0
                          Спасибо, очень полезная и ценная информация.

                          P.S. Вот только в форматировании... я бы поубирал лишние пустые строки. Но это так... пожелание, не более.
                            0
                            Сделал с версткой, что мог. Исправил все параграфы на переводы строк, но заголовки в стилях хабра все равно с большими отступами. :(
                            0
                            отлично, в избранное.
                              +2
                              По моему опыту, ТЗ проходит некоторые эволюционные этапы:
                              - Этап переговоров и принятие решения заказчиком. Условия и критерии, принятые или озвученные заказчиком ни в коем случае не должны быть потеряны или искажены. Это по сути основа ТЗ. В терминах статьи это "Цели и задачи сайта", "Описание пользователей сайта, их цели и задачи", частично остальные пункты.
                              - Драфт. Первоначальный вариант ТЗ, который интенсивно обсуждается и исправляется.
                              - Рабочий вариант. Фактически старт боевых действий.

                              На первых двух этапах ТЗ у меня хранится преимущественно в текстовом виде и под управлением системы контроля за версиями. На третьем компилируется и становится красивым =)
                                0
                                Преговоры это Цели/задачи и рамки проекта.
                                Драфт безусловно. Черновики, наброски. Я не описывал процесс создания ТЗ. Но вы по всем правы.
                                0
                                в ссылочку на артикс добавьте http://
                                  0
                                  Спасибо, исправил.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +2
                                    Доступно написано. Для пущей полезности можно статью дополнить информацией о том, почему ТЗ пишет исполнитель, как трансформировать входящие клиентские требования в ТЗ (и почему клиент не должен писать ТЗ) и про классическую иерархию документов ТТ->ТЗ->ТП.
                                      +1
                                      Да интересная мысль.
                                      Было дело я трансформировал в ТЗ штук 20 анкет от начальников отделов компании-клиента. Каждая анкета страниц по 10.
                                        0
                                        очень грустная, и, к сожалению, нередкая ситуация
                                          +1
                                          Почему же грустная?
                                          Это была моя работа. В ином случае мы бы ТЗ на подпись таскали год. А так это была целая политическая акция. Кстати, вот об этом и стоит в следующий раз написать.
                                            +1
                                            Грустная - это я к тому, что не всегда есть у клиента единый "поставщик требований", который бы уже собрал, согласовал и свел в единый список все требования.

                                            А проделанная работа вызывает только уважение.
                                      +2
                                      Очень качественная статья. Порадовало то, что во многом я угадываю и двигаюсь в нужном направлении. Конечно есть спорные моменты, из них можно выделить два:

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

                                      2. Раздел «Требования». Если честно в большинстве подразделов я не знаю что писать, не Ваш уровень, наверное.

                                        +1
                                        Отрисовка типовых шаблонов можно делать отдельным этапом работы. Я это делал в ТЗ. Т.к. сам занимался юзабилити и проработкой интерфейсов.
                                        Требования надо научиться писать. Фактически получалось так, что с каждым новым проектом мы дописывали что-то в ТЗ. Возникала проблема, мы видели, что это не описано в ТЗ. И вносили исправления.
                                        0
                                        Отличный текст. Видимо автор перед написанием материала составил хорошее ТЗ на сочинение текста )))
                                          0
                                          Кстати, вы недалеки от истины:
                                          http://yuri.shilyaev.com/archives/2005/0…
                                          Там правда картинка была. Она пропала безвременно после падения сайта. :(
                                            0
                                            Сам переодически наступаю на грабли под названием: «Очередное ТЗ». Согласен практически с каждым словом.
                                              0
                                              Немного офтопа: ваш сайт в FF2 без картинок плохо смотрится.
                                                0
                                                Мда. Мне кажется его без картинок будет смореть грустно. :)
                                                  0
                                                  фон под текстом нужно задать
                                                    0
                                                    Валодька, ты мне друг? %)
                                                    Думаешь я знаю, где это сделать? :)
                                                      0
                                                      Сделаем.
                                            0
                                            "..Итак хорошее ТЗ на стай должно содержать в себе:..."

                                            Рекомендую в состав ТЗ добавить check-list в котором описать последовательный сценарий работы с системой.
                                            Пример:
                                            1. Зайти на главную страницу
                                            2. Перейти на страницу "Контакты"
                                            3. Открыть схему проезда в новом окне.

                                            Позже, по этому чек-листу сдавать работу заказчику. Он видел сценарий до, он воспроизвел его после разработки.
                                              0
                                              Спасибо. Исправил.
                                              Кстати, о сценариях подобных мы тоже когда-то задумывались, но вот только я думаю, что для этого можно какой-то документ составить отдельный. Это же по сути тест-кесы. Поэтому в виде тест-кейсов и можно оформить.
                                                0
                                                Очень полезное дополнение. Это называется use-case и обычно прорабатывается в самом начале проекта наряду с целями проекта. Описывает куда приходят пользователи, зачем, почему, что делают, куда переходят и т.д. После этих кейсов уже можно составлять структуру и писать тз дальше.
                                                0
                                                Очень хорошая и интересная статья. Большое Спасибо.
                                                  0
                                                  Огромное респектище! Всем заказчикам в руки.
                                                    0
                                                    Великолепный текст! Спасибо!
                                                      0
                                                      спасибо, полезная статья.
                                                      В "избранное"!
                                                        0
                                                        Спасибо автору! Очень полезная и хорошо поданная информация )
                                                          0
                                                          статья нормальная. описаны основные пункты ТЗ для клиентов/ПМ.

                                                          но для разработчиков такое ТЗ будет не очень информативным ;)
                                                            0
                                                            ТЗ есть часть договора между клиентом и компанией-разработчиком.
                                                            Для разработчиков должна ставить задача. Это для клиента распиывается: на сайте должен быть модуль новостей, куда добавляются... А для разработчика: "Вася, исталлируй модуль новостей на сайт, там надо картинки загружать к каждой новости, макеты у Наташи."
                                                              +1
                                                              а если вы пишете ТЗ для проекта, который с нуля надо разрабатывать?

                                                              для мелких однотипных сайтов и такого уровня, какой вы описываете, будет вполне достаточно
                                                                +1
                                                                Тогда все то, что я описал выше в статье только оччень подробно. В части функционала и требований.
                                                                Для мелких однотипных сайтов подробное ТЗ, которое описывается в статье будет очень объемным. 50-100 страниц для небольших сайтов , которые фрилансеры могут разработать это уже через чур.
                                                            0
                                                            Отличная информация!
                                                            Срочно даю почитать всем друзьям, знакомым заказчикам сайтов и знакомымм девелоперам :)
                                                              +1
                                                              Почему-то при словах "Пишите ТЗ" люди энергично кивают головами, горячо прощаются и уходят, чтобы потеряться.
                                                                0
                                                                Спасибо. в мемориз!
                                                                  0
                                                                  Спасибо! Отличный текст!
                                                                    0
                                                                    А кто пишет/должен писать ТЗ?
                                                                      0
                                                                      Консультанты. :)))
                                                                        0
                                                                        Согласно ГОСТу ТЗ пишут либо заказчик, либо исполнитель, либо совместно.
                                                                        Так это понимать и надо, т.к. это коллективный труд. Коллектиыный труд т.к. его подписывают обе стороны. А перед тем как подписывать необходимо прочитать, понять и т.д....
                                                                        0
                                                                        Исправтье, если не прав.
                                                                        Здесь вы рассматриваете ТЗ, как единственный документ в проекте, связывающий три звена: заказчик, менеджер проекта, разработчики. Возможно, для малых проектов этого достотачно, но для больших: я убежден, что Техническое Задание — документ исключительно для разработчиков. Зачем там "аудитория проекта"? Вы же не станете давать тех. задание каменщику, делающему карниз, с описанием всех пород голубей, которые на него вследствии слетятся. Видимо, имеет смысл разделять проектную документацию на отдельные элементы. Как-то: бриф,концепция проекта, ТЭО, ТЗ etc...Зачем все мешать в одном ТЗ?
                                                                          0
                                                                          Что это меняет в сущности? Надо один документ утвердить с заказчиком или 3? У одного заказчика на документе по проекту надо было поставить 12 виз. Если бы надо было провести 3 документа, то пришлось бы на всех собирать по 12 виз.
                                                                          Это вообще вопрос не документа скорее, а процесса. Когда я писла ТЗ, то нам было удобно так работать. Иногда выделяли отдельно бриф и концепцию. Нельзя написать решения на все возможные задачи.
                                                                          0
                                                                          Спасибо за статью, очень помогла при написании ТЗ.
                                                                            0
                                                                            Спасибо. Для того и писалась.
                                                                            0
                                                                            Спасибо!
                                                                            Статья оказалось очень полезной!
                                                                              0
                                                                              где бы такое найти на английском языке?
                                                                              как ТЗ вообще звучит по-английски?
                                                                                0
                                                                                Не в курсе, но там это все называют "Спецификацией".
                                                                                0
                                                                                Я, например, всегда отрывал руки менеджерам, которые планируют размещение информационных блоков на страницах сайта, т.к. не их это работа, вообщем-то. РМ не Бог, уж извините, и не знает, ни какой дизайн будет, ни какая информация является главной, ни какая - второстепенной. Про юзабилити я ничего не говорю, это вообще отдельная тема. Вывод: если вы пишете ТЗ для утверждения, то максимально оградите себя от представления визуальной части в адрес Заказчика. Схема сайта? - не вопрос, алгоритм? - согласен, дизайн?! - боже упаси.

                                                                                Требования к дизайну сайта должны включать в себя:
                                                                                Описание схемы верстки шаблонов типовых и заглавных страниц в текстовом.
                                                                                Описание графических материалов, обязательных к использованию на странице шаблона. (Фирменный стиль)
                                                                                Цветовое решение сайта. Основной цвет в RGB
                                                                                Требование к размеру страницы в Kb

                                                                                А вообще, я ограничился бы простой выкладкой всей серии 34 гостов и 50-го РД.

                                                                                Как-то вот так...
                                                                                  0
                                                                                  1. Я описывал всегда страницы с позиции информационного архитектора, которым и являлся в проектах.
                                                                                  2. Есть вариант не описывать схему расположения четко. Иногда просто прорисовываются отдельные элементы, но не разрисовывается вся схема. Особо актуально для проектов креативного характера.
                                                                                  3. ГОСТы это конечно прикольно, но ладно я в них разобрался, но далеко не все заказчики и некоторые разработчики будут читать ГОСТы 80х годов на автоматизированные системы и пересматривать их на сайтостроение... Я вообще творчески переработал ГОСТы под использование для сайтов. В чистую использовать их это жесткого.
                                                                                    0
                                                                                    Однажды Заказчик позволил себе орать на моего менеджера на одном из совещаний. Смысл крика лежал в оформлении документа, который менеджер передал для ознакомления Заказчику ранее. После того, как я открыл ГОСТ Заказчику, показал ему правильно оформленный документ и спросил его, есть ли у него возражения относительно принятых государством, хоть и не законодательно, а лишь в форме рекомендации, правил? Заказчик почему-то заткнулся и ответил, что - нет, не имеет. Поэтому самостоятельное творчество - хорошо, но для междусобойчика, а с людьми, которые платят деньги надо действовать только в рамках государственных бумаг. В любом суде будет проще сказать: сделано по ГОСТу номер такой-то.

                                                                                    Вы уж меня простите, я, возможно, прав только для себя, и никоим образом не претендую на объективность. Каждый живет и работает в рамках тех принципов, которые придумал для себя он сам. По мне так ничего умнее и лучше, чем гос.бумага - нет, и никогда не будет.
                                                                                      0
                                                                                      Ничего против гос.бумаг не имею.
                                                                                      В общем и целом все это понятно и правильно. Я всегда придерживался в этой связи рекомендациями, но не доводил их до четкому следованию букве. Т.е. по ГОСТу надо документы оформлять рамкой, как на конструкторской документации. Выглядит это может быть и солидно... но мне кажется что это уже перебор. Слишком уж по-советски, не по-корпоративному сделано... Вот что касается сквозной нумераций картинок и таблиц, нумераций абзацев, системности построения разделов, специальных листов с номерами версий, авторами, процессом утверждения документа и прочего что обычно рекомундует ГОСТ — это использовалось. Ну и работать с таким документом было понятно.
                                                                                  +1
                                                                                  Дайте пожалуйста ссылку на готовое ТЗ которое на ваш взгляд является образцовым ну или по крайней мере хорошим) заранее благодарен)
                                                                                  ps: гугл и прочее юзал, но все что мной было найдено мне показалось не исчерпывающим :)
                                                                                    +1
                                                                                    Ссылок у меня к большому сожалению нет. :( Все большие и серьезные документы относятся к какому-то проекту и не подлежат разглашению, поэтому в интернет в свободный доступ их никто не выкладывает.
                                                                                    Исчерпывающего ТЗ вообще наверное не существует. На то оно и исчерпывающее. Всегда остается то, что не учли.
                                                                                      0
                                                                                      А вы бы могли обезличить какое либо ТЗ и выложить у себя на сайте или еще где я думаю вам был бы признателен не только я ...
                                                                                        0
                                                                                        Я у себя а сайте писал недавно по этому поводу. По некоторым причинам делать этого не буду.
                                                                                          0
                                                                                          - Более 10ка примеров ТЗ тут http://www.antula.ru/weborder-tz.htm
                                                                                          - Тема "ТЗ сайта" на форуме состава http://www.forumsostav.ru/6/24768/
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                        0
                                                                                        Не видно специально, потому что это был коммерческий проект. Я специально выбрал такой размер, где понятно, как это рисовать но не видно названий страниц. Они у вас будут другие. Свои.
                                                                                        0
                                                                                        где нить встречали выложенные ТЗ социальных сетей?
                                                                                        с интересом бы посмотрел...

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

                                                                                        Самое читаемое