Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Хорошая статья.
Лучше для начала подготовить Опросный лист с основными вопросами для клиента, что бы их не забыть, примеры можно глянуть тут
Лучше для начала подготовить Опросный лист с основными вопросами для клиента, что бы их не забыть, примеры можно глянуть тут
а тут это http://mdesign.ru/services/docs
Интересная статья со всех сторон, даже психологии немного есть: "Кстати - тут Вам и первый звоночек - если заказчик угощает - это хорошо, иначе - работайте по предоплате." =)
и правда по психологии ... мне например почему-то кажется совершенно не приемлимо жрать за чужой счет, может у меня что-то не то с психикой? :)
У вас всё нормально с психикой, мне бы было тоже неудобно. Просто я хотел своим постом сказать, что в статье расписано всё со всех сторон.
одно дело "жрать" - совсем другое - заплатить за чашечку кофе - это уже просто вежливость...
с чего вдруг? мы на деловой встрече, я исполнитель, вы заказчик. почему кто-то должен быть вежлив настолько, что платить за другого.
Наглядно и доступно, мне понравилось, но есть один момент:
Если заказчик - серьезный человек и действительно ценит свое время, а ваше ТЗ не произвело на него впечатление, то он, скорее всего, найдет другого специалиста, поэтому я бы не рекомендовал делать ставку на этот метод )
В остальном же, материал стоящий. )
Вы должны убедить заказчика в том, что именно Вы пишите ТЗ, и он за него должен заплатить. Если таковое не получилось - пришлите ему образец - пусть помучается, в итоге, если он ценит своё время - он таки согласиться на Ваши услуги.
Если заказчик - серьезный человек и действительно ценит свое время, а ваше ТЗ не произвело на него впечатление, то он, скорее всего, найдет другого специалиста, поэтому я бы не рекомендовал делать ставку на этот метод )
В остальном же, материал стоящий. )
Очень хорошая статья о том как писать ТЗ есть на старом добром вебмасконе
Статья Юры есть и на хабре:
http://habrahabr.ru/blog/pm/7632.html
http://habrahabr.ru/blog/pm/7632.html
Вопросик, в чем структуру БД рисовали?
В наше время онлайн-коммуникаций встреча в "офф-лайне" имеет смысл больше чтобы познакомиться (фактор личной приязни клиента при выборе заказчика по-прежнему важен). Тратить время на поездку чтобы потом на коленках в пищерии рисовать макеты ИМХО не очень эффективно. Тогда уж лучше пригласить заказчика в офис (если он есть и своим видом повысит ваш рейтинг в его глазах) - дома и стены помогают.
Прошу прощения за въедливость, но я бы ещё добавил, что в ТЗ не должно быть грамматических ошибок, таких как в этом тексте:
попробывать, распологаться.
попробывать, распологаться.
Принцип отражен достаточно верно, но поверхностно. Насчет оплаты ТЗ - это верно, но не все заказчики могут на это пойти. Особенно, на периферии.
Кроме всего прочего я стараюсь (в последнее время) расписывать общий план проекта: что какие функции должны быть и как они должны работать. К этому плану прикладываю расширенную схему БД, в которой отмечаю функциональные взаимосвязи между полями: какие поля используються в тех или иных функциях и как.
Общий пример:
Кроме всего прочего я стараюсь (в последнее время) расписывать общий план проекта: что какие функции должны быть и как они должны работать. К этому плану прикладываю расширенную схему БД, в которой отмечаю функциональные взаимосвязи между полями: какие поля используються в тех или иных функциях и как.
Общий пример:
Так вы ТЗ пишите или БД проектируете?
БД на основе ТЗ проектируется, последовательно.
БД на основе ТЗ проектируется, последовательно.
Я проектирую CMS. Для того, чтобы самому проще было сформировал подробное ТЗ: что и как нужно сделать и как все должно работать. На основе ТЗ сформировал структуру базы. В процессе написания кода / тестирования корректирую ТЗ и структуру БД.
Понравилось как разработчику. Виртуально вам +1 :)
очень инетерсно
с удовольствием прочитал.
с удовольствием прочитал.
В закладки. Спасибо, интересно написано.
интересно. Главное чтобы не было чистого шаблона. Если проект стоит того, то и к созданию ТЗ нужно подойти творчески, одновременно балансируя на границе творчества и техничских терминов.
И ТЗ читаться будет как интересный рассказ и исполнителям будет понятно, что нужно реализовать
И ТЗ читаться будет как интересный рассказ и исполнителям будет понятно, что нужно реализовать
Возьмем на заметку.
Есть один тонкий момент. При написании ТЗ трудно определить как будут располагать блоки на сайте. Так как при разработке интерфейса может быть выявлено, что для данного сайта всё нужно делать по-другому.
Ну не знаю, писать такое ТЗ и встречаться с клиентом в кафе - бред. Для проектов "в кафе", нафиг не нужно ТЗ. Для этого хватает выяснить направление деятельности фирмы и цветовые пристрастия заказчика. А для крупных проектов такого ТЗ мало.
В данном посте и не расписано ТЗ в полном маштабе - тут лишь выдержки из документа на 28-ми страницах.
А это крупный проект? И для него нужно создавать ТЗ? Единственное что тут полезно и нужно, это диаграмма прецедентов. Все остальное - ненужное напрягательство клиента.
Может я не понял сути проекта из вашей статьи, тогда сорри.
Может я не понял сути проекта из вашей статьи, тогда сорри.
А в чём нарисована диаграмма прецедентов
"Диаграмма прецедентов" — очень хорошая штука, а вот по-поводу описания того что где должно находиться — это малость перебор (имхо).
У меня опыта "ведения" проектов нет (только участие), но как мне кажется (да и вы об этом писали в самом начале 1-го шага), что ТЗ должно в последствии использоваться остальными члена команды (в первую очередь), а что тогда, например, будет делать дизайнер после такого руководства?
Не лучше ли просто описать то, что должно быть на страницах сайта (обязательно, не обязательно), а к финальному варианту уже прикладывать отрисованые, на основе ТЗ макеты?
У меня опыта "ведения" проектов нет (только участие), но как мне кажется (да и вы об этом писали в самом начале 1-го шага), что ТЗ должно в последствии использоваться остальными члена команды (в первую очередь), а что тогда, например, будет делать дизайнер после такого руководства?
Не лучше ли просто описать то, что должно быть на страницах сайта (обязательно, не обязательно), а к финальному варианту уже прикладывать отрисованые, на основе ТЗ макеты?
«Кстати — тут Вам и первый звоночек — если заказчик угощает — это хорошо, иначе — работайте по предоплате.»
Я наоборот угощаю сам. Ведь я же услуги предоставляю, а не заказчик.
Представьте, приходите вы в автосалон, угощаете менеджера чашечкой чая…
Хотя, конечно, если заказчик настаивает на чае за свой счёт, это ему только в плюс.
Я наоборот угощаю сам. Ведь я же услуги предоставляю, а не заказчик.
Представьте, приходите вы в автосалон, угощаете менеджера чашечкой чая…
Хотя, конечно, если заказчик настаивает на чае за свой счёт, это ему только в плюс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ТЗ для web-разработчика