Пример техзадания на сайт. Сэкономит время и нервы

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

    Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…

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

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



    Пример концепции сайта: narod.ru/disk/7515328001/konc_orbita.doc.html (doc, 3,5МБ)

    Что включает приведенный файл примера концепции сайта одной из региональных компаний (кусок, который может самостоятельно сделать будущий владелец сайта):
    1. Анализ целевой аудитории.
    2. Потребность ЦА в определенных материалах.
    3. Действия, которые должны совершить на сайте посетители.
    Исходя из п.1-3 мы понимаем, какой должна быть структура сайта, какими должны быть тексты, и расположение элементов навигации.

    4. Продуманные тексты для страниц сайта.
    5. Отрисованные шаблоны страниц (не дизайн, но уже руководство к действию для дизайнера) с написанными текстами.
    6. Текстовые пояснения к лайаутам страниц.
    7. Краткий анализ статистики посещений старой версии сайта.
    8. Основные требования к админке сайта.

    Что не включает:
    1. Вопросы оптимизации сайта.
    2. Вопросы привлечения аудитории.
    3. Требования к дизайну.
    4. Требования к хостингу.
    5. Аудит старой версии сайта и сайтов конкурентов.

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

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

    Если есть подобные примеры, поделитесь!
    НеВсем
    17.88
    Company
    Share post

    Comments 38

      +10
      Заголовок говорит о техзадании, текст — о концепции как об основе для техзадания. Вы бы определились :)
        +1
        Скажем так, термин «техническое задание» подразумевает возможность разной детализации и формата. Поэтому в некоторых случаях это синонимы, а в некоторых — очень близкие понятия.

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

        По порядку откомментирую некоторые моменты:

        1. Целевая аудитория — раздел вообще не проработан. А фраза «Точнее аудиторию смысла описывать нет, т.к. отдыхать хотят все.» — вообще не верная. Есть конкретная ЦА и профиль рыночного сегмента. Есть конкретная ниша, которую тоже можно выделять. В данном случае нужно плотно работать с маркетологами заказчика, если таковых нет — вообще не писать такой воды.

        2. «Целевые действия посетителей» — у Вас там задачи описаны, которые должен решать сайт, но не действия. Действия, которые будет выполнять посетитель во многом зависят от уровня дизайна ресурса и целей создания ресурса, которые не прописаны вообще.

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

        3. «Недружелюбность к посетителю» — смешная формулировка. Таких нет. Каждые выводы должны быть закреплены цифрами, а не фразами общими.

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

        5. Макеты страниц представлены в документе — самые обычные макеты сайтов. Явного успеха в виде конверта посетителей в клиентов думаю наблюдаться не будет.

        =========================

        Общий вывод: документ не полный, написан с несколько некорректными формулировками, которые не имеют прочного «фундамента» в виде статистических данных.

        ИМХО: просто вода.

        Я бы оставил только макеты — все остальное ни к чему в данном случае.

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

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

          Но комментарий в любом случае полезен. Огромное спасибо!
            +1
            ТЗ всегда делается основываясь на пожеланиях заказчика.

            Как раз задача пишущего — писать понятно для заказчика и без двоякого смысла. В этом вся и сложность документа с которой не многие справляются.
            0
            > Явного успеха в виде конверта посетителей в клиентов думаю наблюдаться не будет.

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

                На самом деле, мы решили, что эффективность работы будет отслеживаться так:
                1. Число звонков
                2. Число обращений в аську
                3. Число оформленных договоров (в договоре вставили пункт «откуда узнали» и указали там несколько основных источников)
                4. Средняя стоимость договора
                5. Доля клиентов из интернета в отношении остальных источников
              0
              не могли бы вы привести примеры правильно составленных документов?
                +1
                Да, конечно. Хочу подготовить отдельный топик по этой тематике и проанализировать все на примере собственного ТЗ.
                  0
                  Думаю, здесь многие были бы благодарны за такую подсказку.
              +1
              Надо достаточно четко писать, сначала делается дизайн — это отдельное ТЗ, что где будет и как это будет функционировать части сайта или вообще любой системы. ТЗ на мой взгляд это юр. документ, потом что бы проблем не было и голова не у кого не болела. Знаю одно ТЗ в воздухе лучше не создавать, минимум письменно, что бы потом можно было тыкать, а уже задача исполнителя написать его максимально точно, что бы потом по размытости с тебя не стребовали большего, если до этого дойдет. Знаете, разные клиент бывают, с одними устно договоришься, все окей, а с другими просто беда одно слово — жадные. Ну как то так.
                0
                Совершенно верно!

                В ТЗ не должно быть двоякого смысла! 100% это должен быть документы не ниже по уровню самого договора на создание сайта.

                Я, например, в своих ТЗ указываю пару моментов, которые в какой-то мере меня страхуют:

                Кол-во работ, которые выполняются не по ТЗ не должны превышать 5% от общих трудовых затрат.

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

                — Все же выделю в двух словах пару моментов, которые могут предотвратить «непонятки» с клиентом и исполнителем:

                1. До заключения договора расскажите о сущности каждого этапа работы. Остановитесь на ТЗ. Дайте понять клиенту, что это как договор. Подписали — значит должны выполнить;

                2. Индивидуальный подход. Если п №1 не помог и вы видите постоянные предложения «играть» — пишите дополнительные ТЗ и только потом делайте блок работ.

                3. Старайтесь все же отстаивать свои идеи. Вы ведь профессионал!

                –3
                Привет Пенза!
                • UFO just landed and posted this here
                    0
                    У ТЗ есть своя целевая аудитория:

                    — менеджер клиента
                    — менеджер студии
                    — дизайнер
                    — верстальщик
                    — программист

                    У каждой аудитории свои потребности, нужно их для себя расписать и по ним составить ТЗ — тогда будет шедевр.
                      +1
                      + аналитик и тестировщик
                      +5
                      Прикрепленный документ не является ни ТЗ ни концепцией сайта.
                      Почему это не ТЗ:
                      — много лишнего — содержит отчеты о работе, предложения и ликбез, которым в ТЗ не место;
                      — неинформативные заголовки — пример, «Основные моменты» — о чем этот раздел?
                      — повествовательный формат изложения, нечеткие формулировки. К примеру — «Возможно, что список клиентов должен формироваться так:». Автор как бы обсуждает с заказчиком возможный функционал.

                      Почему это не концепция:
                      — в документе нет ничего, что бы четко описывало концепцию сайта — принципы коммуникации с пользователями, принципы привлечения посетителей, принципы получения прибыли.
                        –1
                        Спасибо. Идеей этого поста не было показать, какой я крутой составитель ТЗ. Интереснее другое — поделиться опытом составления подобных документов, поэтому примеры ваших работ были бы кстати.

                        И еще один факт: сайт-то получился. И главное, все довольны результатом, включая посетителей.
                        +1
                        «Фактически, больше половины людей сразу уходит с сайта.
                        В основном, приходят посетители из поисковиков, которые ищут именно вашу компанию(за текущий месяц)»

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

                            Размещенный по ссылке документ уже отработал свою задачу, поэтому в его публикации ничего криминального нет.
                            +4
                            Все умничают, а выложить образец грамотного ТЗ — рука не поднимается?
                              0
                              Google Docs удобен для публикации проектных документов ИМХО. Скачивать с народа и вводить капчу вы и клиентов заставляете? =)
                                0
                                Вы с клиентами работаете? Многие не знают, что такое Google Docs. Некоторые не умеют распаковывать архивы.
                                  +1
                                  Да, я работаю с клиентами.
                                  Те из них, кто не знает что такое Google Docs, способны кликнуть на ссылку, как минимум.
                                  А там и удобный вид, и сохранение в любом нужном формате, и совместное редактирование…
                                  Архивы я не предлагал.
                                    +1
                                    Ясно. Привычка — сильная штука. Если сказать человеку, что документ в формате Word, к которому он за 10 лет привык, это одно. Другое — если дать ему ссылку на сервис, который он никогда не видел.

                                    Знаете, что обычно получаю в ответ? «Пришлите на e-mail в формате doc».
                                      0
                                      Ну от каменных топоров мы ведь как-то отвыкли =)

                                      Лично я просьб переслать что-либо в формате doc не получал ни разу. Хотя конечно, мой частный случай не показателен, я вообще стараюсь не иметь дел с «дремучими» клиентами =)
                                        0
                                        Если клиент адекватный, то со временем его можно научить всему. А вот если «дремучих» не обучать (когда они действительно чего-то хотят), то ничего и не изменится в нашей сфере.
                                    +1
                                    Публиковать, кстати, можно прямо на странице вашей студии (в личном кабинете клиента, к примеру), там выдается код с iframe.
                                      0
                                      Ээх… Пока не в регионах, к сожалению.
                                  +2
                                  Ну что же, почин хороший — к сожалению, судя по моей и моих коллег практике, если изначально не было жесткого требования заказчика по созданию документации к проекту, она либо не пишется совсем, либо пишется задним числом(хотя бывают и исключения из правил). Поэтому, обсуждения в этом ключе можно только приветствовать.

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

                                  Обычно в документе нас интересуют, как минимум, следующее:
                                  — документ должен быть настолько коротким, насколько это возможно;
                                  — язык должен быть понятным всем сторонам;
                                  — перечень функций;
                                  — как именно будут реализованы те или иные функции;
                                  — что делать не нужно. Подстраховка, часто бывает полезно специально указать, что система не будет петь и танцевать (резервное копирование заказчик будет делать своими силами, браузер IE6 поддерживаться не будет, на iPhone/Android приложение будет работать с ограничениями).

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

                                  Это что касается содержания. Теперь по форме. Как уже было указано, есть ГОСТ ГОСТ 34.602-89
                                  www.info-system.ru/tech_doc/gost_is_34602_89.html. Многих критических стрел можно было бы легко избежать, приведя документ по форме к этому ГОСТ:

                                  1) общие сведения;
                                  2) назначение и цели создания (развития) системы;
                                  3) характеристика объектов автоматизации;
                                  4) требования к системе;
                                  5) состав и содержание работ по созданию системы;
                                  6) порядок контроля и приемки системы;
                                  7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
                                  8) требования к документированию;
                                  9) источники разработки.

                                  В целом же продемонстрированный документ гораздо, гораздо лучше, чем «ничего», и вполне может служить как базой для разработки проекта, так и отправной точкой для дальнейшей эволюции «шаблона ТЗ на сайт».
                                    0
                                    Отличный комментарий! К сожалению, ГОСТ детализацию не описывает…
                                      +2
                                      Верно, ГОСТ описывает форму, у вас — содержание. Облечение нужного содержания в нужную форму обычно дает неплохой эффект :), тем более, что в таком виде форму соблюсти достаточно легко — тут ведь нет специальных требований к колонтитулам, отступам и так далее.
                                      +1
                                      Кстати, в тему «как именно будут реализованы те или иные функции» — 6 причин, по которым вам не стоит писать функциональные спецификации
                                        +1
                                        Как говорил т. Рычагов, правда, несколько по другому поводу: «Авиацию противника нужно уничтожать не только в воздухе, но и на аэродромах. Выступавшие тт. Кравченко и Штерн склонны считать, что основное уничтожение противника будет осуществляться в воздухе, а не на земле. Я всегда был противником этих крайностей. Мы обязаны одинаково хорошо бить воздушного противника одинаково хорошо и на земле и в воздухе.».

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

                                    Only users with full accounts can post comments. Log in, please.