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

11 Responses to написать ТЗ для нескольких сайтов

  1. Begun:

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

    Поэтому, техническое задание на сайт пишется досконально, в Ворде, на пятидесяти листах. Хотя это и на самом деле сильно тормозит процесс. Но нам же важен результат, верно?

  2. Oked:

    Понятно, спасибо. Может, какие-то макросы в ворде есть типа автозаполнения? Много повторяющихся терминов, которые лень набирать с нуля.

  3. Oked:

    А результат — да, важен, конечно.

  4. Begun:

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

  5. Oked:

    Как и обещала, оставлю пару ссылок. Мастер Технических Заданий: http://www.freetz.ru/master-tz/ и обзор программ для проектирования страниц: http://habrahabr.ru/post/132403/

  6. Oked:

    Я примерно так и решила сделать. Сначала Глоссарий. Только аббревиатуры не подойдут, потому что их будет слишком много и есть опасность, что непонятна будет иерархия элементов (кто кого танцует, скажем так — статический URL имеет навигационный путь или наоборот 🙂 Решила попробовать функцию Автотекст, добавлю туда термины из глоссария.

  7. Ffoon:

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

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

    А «Бизнес-задачи» и «Метрики их выполнения»? А Пользовательские задачи, Роли, Варианты использования, Сценарии, Информационная архитектура, Аналитика, Интерфейсы в разных состояниях? Для этого не может быть шаблонов. А если вы это не делаете — то это не проектирование, это «мысли о сайте на салфетке».

  8. Norno:

    У меня mac os и там есть простое решение — софтина для работы со снипетами text expander. Если понимаешь, что нужно, то за счет этого многостраничный док не проблема.

    Думаю и под винду есть аналог

  9. Oked:

    Я сейчас занимаюсь только фронт-эндом. Но попытаюсь ответить на вопрос. «Бизнес–задачи», «Метрики их выполнения», Информационная архитектура, Аналитика — есть в коробке. Пользовательские задачи, Роли, Варианты использования, Сценарии — задаются отдельно, для этого в системе управления сайтом есть готовые возможности (по факту поставить птичку там, поставить тут, создать макрос). Интерфейс в различных состояниях — статический только в некоторых частях, а вообще нужна модульная структура страницы, а потом в модулях отображается динамический контент, который «собирается» на странице в зависимости от профиля пользователя или истории кликов (если пользователь не залогинился, но серфит по сайту).

  10. Oked:

    да, phraseexpress, спасибо)

  11. Ffoon:

    Ответ взрывает мой мозг.

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

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

Добавить комментарий

Ваш e-mail не будет опубликован.