Комментарии 38
Заголовок говорит о техзадании, текст — о концепции как об основе для техзадания. Вы бы определились :)
Скажем так, термин «техническое задание» подразумевает возможность разной детализации и формата. Поэтому в некоторых случаях это синонимы, а в некоторых — очень близкие понятия.
Не хотел в любом случае никого путать. Спасибо за ремарку.
Не хотел в любом случае никого путать. Спасибо за ремарку.
Техзадание это часть договора, я стараюсь в нем аккуратно прописывать моменты восприятия или необходимых действий. Одно дело, когда пишите, что меню должно быть текстовым, а не графическим, это однозначно идентифицируемо, а другое вопросы типа — пользователь должен совершить такое-то действие, где вы потом его будете искать, чтобы он доказал соответствие своего поведения выдержке из вашего ТЗ?:)
Посмотрел Ваше ТЗ.
По порядку откомментирую некоторые моменты:
1. Целевая аудитория — раздел вообще не проработан. А фраза «Точнее аудиторию смысла описывать нет, т.к. отдыхать хотят все.» — вообще не верная. Есть конкретная ЦА и профиль рыночного сегмента. Есть конкретная ниша, которую тоже можно выделять. В данном случае нужно плотно работать с маркетологами заказчика, если таковых нет — вообще не писать такой воды.
2. «Целевые действия посетителей» — у Вас там задачи описаны, которые должен решать сайт, но не действия. Действия, которые будет выполнять посетитель во многом зависят от уровня дизайна ресурса и целей создания ресурса, которые не прописаны вообще.
П.С.: на этом я вообще не совсем понял в чем суть документа. Это ТЗ на что? Заголовок тоже нужно формулировать правильно. Полная каша. Сейчас читаю что-то похожее на анализ сайта. Но какие цели этого? Нужно было тогда цели и задачи исследования Вашего писать, а не задачи сайта.
3. «Недружелюбность к посетителю» — смешная формулировка. Таких нет. Каждые выводы должны быть закреплены цифрами, а не фразами общими.
4. «Чтобы сделать сайт дружелюбным» — нет понятий «дружелюбный», «красивый», «приятный». Все это подразумевает ряд технических характеристик, которые вы не указали.
5. Макеты страниц представлены в документе — самые обычные макеты сайтов. Явного успеха в виде конверта посетителей в клиентов думаю наблюдаться не будет.
=========================
Общий вывод: документ не полный, написан с несколько некорректными формулировками, которые не имеют прочного «фундамента» в виде статистических данных.
ИМХО: просто вода.
Я бы оставил только макеты — все остальное ни к чему в данном случае.
По порядку откомментирую некоторые моменты:
1. Целевая аудитория — раздел вообще не проработан. А фраза «Точнее аудиторию смысла описывать нет, т.к. отдыхать хотят все.» — вообще не верная. Есть конкретная ЦА и профиль рыночного сегмента. Есть конкретная ниша, которую тоже можно выделять. В данном случае нужно плотно работать с маркетологами заказчика, если таковых нет — вообще не писать такой воды.
2. «Целевые действия посетителей» — у Вас там задачи описаны, которые должен решать сайт, но не действия. Действия, которые будет выполнять посетитель во многом зависят от уровня дизайна ресурса и целей создания ресурса, которые не прописаны вообще.
П.С.: на этом я вообще не совсем понял в чем суть документа. Это ТЗ на что? Заголовок тоже нужно формулировать правильно. Полная каша. Сейчас читаю что-то похожее на анализ сайта. Но какие цели этого? Нужно было тогда цели и задачи исследования Вашего писать, а не задачи сайта.
3. «Недружелюбность к посетителю» — смешная формулировка. Таких нет. Каждые выводы должны быть закреплены цифрами, а не фразами общими.
4. «Чтобы сделать сайт дружелюбным» — нет понятий «дружелюбный», «красивый», «приятный». Все это подразумевает ряд технических характеристик, которые вы не указали.
5. Макеты страниц представлены в документе — самые обычные макеты сайтов. Явного успеха в виде конверта посетителей в клиентов думаю наблюдаться не будет.
=========================
Общий вывод: документ не полный, написан с несколько некорректными формулировками, которые не имеют прочного «фундамента» в виде статистических данных.
ИМХО: просто вода.
Я бы оставил только макеты — все остальное ни к чему в данном случае.
Еще раз подчеркну: документ делался совместно с заказчиком, который совершенно не разбирается в веб. Ему нужны были понятные и простые формулировки.
То, что для нас может быть двояким, или наоборот, очевидным, видится по-другому для тех, кто мало связан с Интернетом.
Но комментарий в любом случае полезен. Огромное спасибо!
То, что для нас может быть двояким, или наоборот, очевидным, видится по-другому для тех, кто мало связан с Интернетом.
Но комментарий в любом случае полезен. Огромное спасибо!
> Явного успеха в виде конверта посетителей в клиентов думаю наблюдаться не будет.
Не угадали. Сайт был выложен в конце февраля:
Не угадали. Сайт был выложен в конце февраля:
Это длительность посещения. Тут тяжело что-то сказать о конверте. Интересней бы от Вас узнать статистику звонков с сайта и графиком экстраполировать на тот, который Вы сейчас показали.
Результаты Вас удивят, когда мы увидим определенную зависимость. Попробуйте!
Результаты Вас удивят, когда мы увидим определенную зависимость. Попробуйте!
Вчера был у заказчика. За две недели отметил рост обращений из Интернета (они опрашивают звонивших) примерно в 2 раза.
На самом деле, мы решили, что эффективность работы будет отслеживаться так:
1. Число звонков
2. Число обращений в аську
3. Число оформленных договоров (в договоре вставили пункт «откуда узнали» и указали там несколько основных источников)
4. Средняя стоимость договора
5. Доля клиентов из интернета в отношении остальных источников
На самом деле, мы решили, что эффективность работы будет отслеживаться так:
1. Число звонков
2. Число обращений в аську
3. Число оформленных договоров (в договоре вставили пункт «откуда узнали» и указали там несколько основных источников)
4. Средняя стоимость договора
5. Доля клиентов из интернета в отношении остальных источников
не могли бы вы привести примеры правильно составленных документов?
Надо достаточно четко писать, сначала делается дизайн — это отдельное ТЗ, что где будет и как это будет функционировать части сайта или вообще любой системы. ТЗ на мой взгляд это юр. документ, потом что бы проблем не было и голова не у кого не болела. Знаю одно ТЗ в воздухе лучше не создавать, минимум письменно, что бы потом можно было тыкать, а уже задача исполнителя написать его максимально точно, что бы потом по размытости с тебя не стребовали большего, если до этого дойдет. Знаете, разные клиент бывают, с одними устно договоришься, все окей, а с другими просто беда одно слово — жадные. Ну как то так.
Совершенно верно!
В ТЗ не должно быть двоякого смысла! 100% это должен быть документы не ниже по уровню самого договора на создание сайта.
Я, например, в своих ТЗ указываю пару моментов, которые в какой-то мере меня страхуют:
Кол-во работ, которые выполняются не по ТЗ не должны превышать 5% от общих трудовых затрат.
Конечно, и это не всегда помогает. Если клиент начинает «играть шрифтами», «играть цветами» и т.п. — тогда составляю отдельное, дополнение к ТЗ на конкретную функцию сайта. Пусть даже самую маленькую деталь. Но когда Вы эту деталь 10 раз переделаете — уйти может день.
— Все же выделю в двух словах пару моментов, которые могут предотвратить «непонятки» с клиентом и исполнителем:
1. До заключения договора расскажите о сущности каждого этапа работы. Остановитесь на ТЗ. Дайте понять клиенту, что это как договор. Подписали — значит должны выполнить;
2. Индивидуальный подход. Если п №1 не помог и вы видите постоянные предложения «играть» — пишите дополнительные ТЗ и только потом делайте блок работ.
3. Старайтесь все же отстаивать свои идеи. Вы ведь профессионал!
В ТЗ не должно быть двоякого смысла! 100% это должен быть документы не ниже по уровню самого договора на создание сайта.
Я, например, в своих ТЗ указываю пару моментов, которые в какой-то мере меня страхуют:
Кол-во работ, которые выполняются не по ТЗ не должны превышать 5% от общих трудовых затрат.
Конечно, и это не всегда помогает. Если клиент начинает «играть шрифтами», «играть цветами» и т.п. — тогда составляю отдельное, дополнение к ТЗ на конкретную функцию сайта. Пусть даже самую маленькую деталь. Но когда Вы эту деталь 10 раз переделаете — уйти может день.
— Все же выделю в двух словах пару моментов, которые могут предотвратить «непонятки» с клиентом и исполнителем:
1. До заключения договора расскажите о сущности каждого этапа работы. Остановитесь на ТЗ. Дайте понять клиенту, что это как договор. Подписали — значит должны выполнить;
2. Индивидуальный подход. Если п №1 не помог и вы видите постоянные предложения «играть» — пишите дополнительные ТЗ и только потом делайте блок работ.
3. Старайтесь все же отстаивать свои идеи. Вы ведь профессионал!
Привет Пенза!
НЛО прилетело и опубликовало эту надпись здесь
У ТЗ есть своя целевая аудитория:
— менеджер клиента
— менеджер студии
— дизайнер
— верстальщик
— программист
У каждой аудитории свои потребности, нужно их для себя расписать и по ним составить ТЗ — тогда будет шедевр.
— менеджер клиента
— менеджер студии
— дизайнер
— верстальщик
— программист
У каждой аудитории свои потребности, нужно их для себя расписать и по ним составить ТЗ — тогда будет шедевр.
Прикрепленный документ не является ни ТЗ ни концепцией сайта.
Почему это не ТЗ:
— много лишнего — содержит отчеты о работе, предложения и ликбез, которым в ТЗ не место;
— неинформативные заголовки — пример, «Основные моменты» — о чем этот раздел?
— повествовательный формат изложения, нечеткие формулировки. К примеру — «Возможно, что список клиентов должен формироваться так:». Автор как бы обсуждает с заказчиком возможный функционал.
Почему это не концепция:
— в документе нет ничего, что бы четко описывало концепцию сайта — принципы коммуникации с пользователями, принципы привлечения посетителей, принципы получения прибыли.
Почему это не ТЗ:
— много лишнего — содержит отчеты о работе, предложения и ликбез, которым в ТЗ не место;
— неинформативные заголовки — пример, «Основные моменты» — о чем этот раздел?
— повествовательный формат изложения, нечеткие формулировки. К примеру — «Возможно, что список клиентов должен формироваться так:». Автор как бы обсуждает с заказчиком возможный функционал.
Почему это не концепция:
— в документе нет ничего, что бы четко описывало концепцию сайта — принципы коммуникации с пользователями, принципы привлечения посетителей, принципы получения прибыли.
«Фактически, больше половины людей сразу уходит с сайта.
В основном, приходят посетители из поисковиков, которые ищут именно вашу компанию(за текущий месяц)»
Если посмотреть ваши же данные, то в основном как раз происходит наоборот, большинство людей более 80 человек приходят по разным низкочастотным запросам и только половина от этого числа за просе имеют название Орбита. Так что большинство это не первая по популярности фраза, а реально большинство всех запросов.
В основном, приходят посетители из поисковиков, которые ищут именно вашу компанию(за текущий месяц)»
Если посмотреть ваши же данные, то в основном как раз происходит наоборот, большинство людей более 80 человек приходят по разным низкочастотным запросам и только половина от этого числа за просе имеют название Орбита. Так что большинство это не первая по популярности фраза, а реально большинство всех запросов.
если ответ на вопрос о привлечении аудитории вы зададите после концепции сайта будет не ага
В конечном документе есть все, что касается привлечения аудитории из поиска, региональных сайтов, контекстной рекламы. Просто это уже сугубо коммерческая информация и я решил, что ее публиковать не стоит.
Размещенный по ссылке документ уже отработал свою задачу, поэтому в его публикации ничего криминального нет.
Размещенный по ссылке документ уже отработал свою задачу, поэтому в его публикации ничего криминального нет.
Все умничают, а выложить образец грамотного ТЗ — рука не поднимается?
Google Docs удобен для публикации проектных документов ИМХО. Скачивать с народа и вводить капчу вы и клиентов заставляете? =)
Вы с клиентами работаете? Многие не знают, что такое Google Docs. Некоторые не умеют распаковывать архивы.
Да, я работаю с клиентами.
Те из них, кто не знает что такое Google Docs, способны кликнуть на ссылку, как минимум.
А там и удобный вид, и сохранение в любом нужном формате, и совместное редактирование…
Архивы я не предлагал.
Те из них, кто не знает что такое Google Docs, способны кликнуть на ссылку, как минимум.
А там и удобный вид, и сохранение в любом нужном формате, и совместное редактирование…
Архивы я не предлагал.
Ясно. Привычка — сильная штука. Если сказать человеку, что документ в формате Word, к которому он за 10 лет привык, это одно. Другое — если дать ему ссылку на сервис, который он никогда не видел.
Знаете, что обычно получаю в ответ? «Пришлите на e-mail в формате doc».
Знаете, что обычно получаю в ответ? «Пришлите на e-mail в формате doc».
Публиковать, кстати, можно прямо на странице вашей студии (в личном кабинете клиента, к примеру), там выдается код с iframe.
Ну что же, почин хороший — к сожалению, судя по моей и моих коллег практике, если изначально не было жесткого требования заказчика по созданию документации к проекту, она либо не пишется совсем, либо пишется задним числом(хотя бывают и исключения из правил). Поэтому, обсуждения в этом ключе можно только приветствовать.
Зачем вообще нужен документ такого плана, особенно если заказчик не выставляет обязательного требования его составить(а заказчика часто интересует лишь результат, если ему скажут — вот ТЗ, он его, возможно, прочитает, если нет, то и не надо)? Бывает, что это требование к проекту, особенно при работе на государственные структуры типа ГНИВЦ, но если такого требования нет? В этом случае документ все равно нужен, чтобы иметь возможность обосновать оценку работ и подстраховаться на случай «а почему вы не сделали вот это? — А потому, что это не включено в ТЗ».
Обычно в документе нас интересуют, как минимум, следующее:
— документ должен быть настолько коротким, насколько это возможно;
— язык должен быть понятным всем сторонам;
— перечень функций;
— как именно будут реализованы те или иные функции;
— что делать не нужно. Подстраховка, часто бывает полезно специально указать, что система не будет петь и танцевать (резервное копирование заказчик будет делать своими силами, браузер 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) источники разработки.
В целом же продемонстрированный документ гораздо, гораздо лучше, чем «ничего», и вполне может служить как базой для разработки проекта, так и отправной точкой для дальнейшей эволюции «шаблона ТЗ на сайт».
Зачем вообще нужен документ такого плана, особенно если заказчик не выставляет обязательного требования его составить(а заказчика часто интересует лишь результат, если ему скажут — вот ТЗ, он его, возможно, прочитает, если нет, то и не надо)? Бывает, что это требование к проекту, особенно при работе на государственные структуры типа ГНИВЦ, но если такого требования нет? В этом случае документ все равно нужен, чтобы иметь возможность обосновать оценку работ и подстраховаться на случай «а почему вы не сделали вот это? — А потому, что это не включено в ТЗ».
Обычно в документе нас интересуют, как минимум, следующее:
— документ должен быть настолько коротким, насколько это возможно;
— язык должен быть понятным всем сторонам;
— перечень функций;
— как именно будут реализованы те или иные функции;
— что делать не нужно. Подстраховка, часто бывает полезно специально указать, что система не будет петь и танцевать (резервное копирование заказчик будет делать своими силами, браузер 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) источники разработки.
В целом же продемонстрированный документ гораздо, гораздо лучше, чем «ничего», и вполне может служить как базой для разработки проекта, так и отправной точкой для дальнейшей эволюции «шаблона ТЗ на сайт».
Отличный комментарий! К сожалению, ГОСТ детализацию не описывает…
Кстати, в тему «как именно будут реализованы те или иные функции» — 6 причин, по которым вам не стоит писать функциональные спецификации
Как говорил т. Рычагов, правда, несколько по другому поводу: «Авиацию противника нужно уничтожать не только в воздухе, но и на аэродромах. Выступавшие тт. Кравченко и Штерн склонны считать, что основное уничтожение противника будет осуществляться в воздухе, а не на земле. Я всегда был противником этих крайностей. Мы обязаны одинаково хорошо бить воздушного противника одинаково хорошо и на земле и в воздухе.».
Ну т.е., проводя аналогию, в проектах хорошо сочетать и спецификации, и гибкость, дожна быть пропорция, в каждом проекте разные коэффициенты сочетания, нужно быть максимально готовым встретить во всеоружии любой вариант. В проектах с фиксированной ценой без ТЗ затруднительно. Хорошо, конечно, договориться с заказчиком так — мы будем делать, когда и что сделаем, неясно, а вы нам платите пока. Но не всегда это удается.
Ну т.е., проводя аналогию, в проектах хорошо сочетать и спецификации, и гибкость, дожна быть пропорция, в каждом проекте разные коэффициенты сочетания, нужно быть максимально готовым встретить во всеоружии любой вариант. В проектах с фиксированной ценой без ТЗ затруднительно. Хорошо, конечно, договориться с заказчиком так — мы будем делать, когда и что сделаем, неясно, а вы нам платите пока. Но не всегда это удается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример техзадания на сайт. Сэкономит время и нервы