Привет!

Расскажите как правильно, красиво и грамотно писать ТЗ для веб-разработчиков?
Есть какие-нибудь мануалы, коллективный опыт и лучшие практики на эту тему?

Что почитать?

8 Responses to ТЗ для веб-разработчиков

  1. HTnsuper:

    Главное, пиши так, чтобы это:

    1. можно было читать
    2. можно было использовать
    3. не приходилось тратить кучу времени, чтобы вытащить из данного ТЗ суть.

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

    Лично мне очень нравится получать спецификации на разработку в виде Given When Then (было делаем стало).

  2. 367enko:

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

    Например «Сделать блог» и «сделать тип материала «блог» с полями <ляляля> и выводом материалов по 15 штук на странице, полным пейджером и выводом кратких содержаний записей» — это две разных задачи. Программист понимает по своему, заказчик понимает по своему. То есть чем плотнее установить рамки того, что мы разрабатываем — тем лучше, тем меньше будет недопониманий. Потому что в итоге может выясниться, что заказчик видел блог а-ля хабрахабр, а мы сделали страницу с обычным выводом категории и т.д.

    И конечно же баянистая картинка, описывающая суть проблемы лучше любых слов

    image

  3. HTnsuper:

    > Да, очень будет тяжелым для понимания

    И поэтому, его никто не будет читать.

  4. HTnsuper:

    > Да, очень будет тяжелым для понимания

    И поэтому, его никто не будет читать.

  5. 367enko:

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

  6. HTnsuper:

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

  7. VokApp:

    чаще всего я делаю в виде:
    1. макеты
    2. Описание разделов и юзерстори по каждому с указанием методов и страниц макетов (по сути, текстовое описание контроллеров)
    3. Если нужно, описание предлагаемой структуры данных
    4. Обзор рекомендуемых технологий.

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

  8. VokApp:

    а, 5. еще обычно спецификация для будущего протокола взаимодействия с продуктом (api или что-то еще), если оно будет

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