Comments 13
И вы все таки не ответили на вопрос (по технической части). Вот неясно что значит «всё»: описывать ли необходимые технологии? AJAX, Flash (HTTP, RFC-...). Как насчет рамок скорости работы страницы (каждой определенно страницы?), кол-во серверов (кол-во запросов), проверка на безопасность — SQL injections, XSS, CSRF (или раз клиент не вспомнил, то можно это в уме держать?), валидность/семантичность верстки, тип валидации форм (JS ли, PHP ли, оба ли, сообщения об ощибках), наличие функциональных и юнит-тестов, короче вся та внутренняя кухня которая для заказчика «черный ящик». Обычно всё это часто держится в уме (т.е. на совести подрядчика).
Ответ в том, что чем больше прописано и подписано заказчиком — тем лучше. Если заказчик в брифе не в состоянии прописать необходимые технологии, то это должен сделать разработчик (обсудив с заказчиком задачи, и выявив потребности). Но потом нужно прописать, что сайт будет разработан на с применением определенного флеш-аякса, нацеленого на такую-то скорость перезагрузки страниц и с такой-то нагрузкой на сервер. И это все прописывается в ТЗ уже вами, и подписывается…
А то выяснится внезапно, что заказчик планировал на своем корпоративном сайте через год сделать отраслевую социальную сеть, и ваш движок к этому как-то не приспособлен… Кто будет виноват? ;)
А то выяснится внезапно, что заказчик планировал на своем корпоративном сайте через год сделать отраслевую социальную сеть, и ваш движок к этому как-то не приспособлен… Кто будет виноват? ;)
Необходимость визуальных технологий описывается в Художественном задании. Если в рамках нестандартного проекта ведется работа еще и разворачиваением системы на нескольких серверах, то все это конечно же описывается. Безопасность так же описана в ТЗ. По многим вопросам, на рынке есть внегласные стандарты, которых все крупные компании придерживаются. Но это отдельная статься про стандарты :)
ГОСТов нет, каждая компания вводит свои внутренние стандарты, но ГОС стандартов нету.
практически все требования входят, данный документ в среднем около 100 страниц, описано максимально все.
практически все требования входят, данный документ в среднем около 100 страниц, описано максимально все.
Хочу уточнить что, нет ГОСТов на разработку именно сайтов. Есть ГОСТ на разработку программного обеспечения. У нас имеется опыт разработки документации по ГОСТ для сайта, подразумевая, что сайт является программным обеспечением (софтом), что является, в глубине своего понятия, правдой, но не всем клиентам это нужно, в большинстве случаев, они не хотят получить ГОСТовую документацию на сайт, так как она получается очень громозткой.
Больше бумаги – чище попа!
У автора ТЗ — да. У менеджера проекта и у студии целиком — нет. Давайте не будем кривить душой, ваше ТЗ из «многобумаги» на 99% есть копипаста из ТЗ предыдущих
Через какое-то время, ближе к релизу, оказывается, что заказчик хочет «такую же, но с перламутровыми пуговицами». И что дизайн должен быть резиновым. И на макете его всё устраивало, когда он видел страницу целиком, а в реальности на его ноутбуке всё выглядит не так. И еще логотип хотелось бы сделать покрупнее и подвинуть в правый угол. И еще сайт должен быть зеленым. И еще, несмотря на ТЗ, товары должно быть можно заказывать без регистрации.
И тут ловким движением руки вы достаете подписанный заказчиком талмуд, на 891-ой странице которого русским по белому написано, что «к оформлению заказа допускаются только пользователи, подтвердившие адрес электронной почты», то есть, прошедшие процедуру регистрации. В этот момент ваша попа становится мягкой и шелковистой. Зато она начинает болеть у ваших юристов, которые вынуждены составлять исковое заявление в суд, потому что заказчик не хочет оплачивать почти готовый сайт по 1000-страничному скопипасченному ТЗ. Сам заказчик тоже недоволен — он потерял деньги, время, силы и нервы, и в итоге его еще и выставили козлом. Короче кроме вас лично — все в минусе.
ТЗ на типовой интернет-магазин должно занимать одну, максимум две страницы. Не надо заморачиваться на мелочах, пока вы не можете показать наглядно, о чем идет речь. После утверждения макета и верстки ставится CMS с максимально «дефолтными» настройками, на неё вешается дизайн и вносится пробный десяток товаров. И уже в этот «недосайт» запускается клиент. Пусть он делает покупки разными способами, пусть учится добавлять товары, принимать заказы, размещать текстовые страницы и так далее. Всё хотелки и предложения — не описываются где-то там в 1000-страничной теории, а понятны тут же, на месте, и через пару часов можно посмотреть результат. Если какая-то хотелка требует слишком много времени — ну, объясняется, что это обойдется во столько-то времени и денег, решайте. У всех заказчиков бюджет и сроки ограничены и заранее известны вам, так чт количеством этих хотелок вы очень легко можете управлять) В-общем, как-то так. ИМХО разумеется, но…
у нас тз занимает одну страницу. в нем сформулировано лишь резиновость или нерезиновость, требования к кросбраузерности, движок на котром выполняется работа и последовательность работ.
А вот на этапе проработки эскизов начинаем все очень скурпулезно прорабатывать прорабатывать. Главное — сформудировать тз на дизайн с учетом всех ограничений движка.
Если заказчик внезапно захотел то чего нету, обьясняем что этого у нас нет готового и формулируем оплату как ХХХ тугриков в час.
Успех общения зависит именно от того насколько доходчиво мы обьяснили клиенту тех процесс.
А вот на этапе проработки эскизов начинаем все очень скурпулезно прорабатывать прорабатывать. Главное — сформудировать тз на дизайн с учетом всех ограничений движка.
Если заказчик внезапно захотел то чего нету, обьясняем что этого у нас нет готового и формулируем оплату как ХХХ тугриков в час.
Успех общения зависит именно от того насколько доходчиво мы обьяснили клиенту тех процесс.
А если заказчик будет вас убеждать, что «за это я и платил», «ведь на первой встрече я же вам сразу сказал, что вот это, чего нету, сразу должно быть!»
у нас есть не большое правило — если хотите что бы что то гарантировано входило в стоимость то напишите письменный список пожеланий которые мы должны подтвердить.
если заказчик дотошный — то затевается долгая переписка из которой рождается тз.
менеджер который ведет первое общение с клиентом должен обьяснить что его никто не собирается обманывать и плата идет только за вполняемую нами работу.
тяжелые
правда есть еще одна ообенность — а откуда заказчик знает что ему нужно…
если заказчик дотошный — то затевается долгая переписка из которой рождается тз.
менеджер который ведет первое общение с клиентом должен обьяснить что его никто не собирается обманывать и плата идет только за вполняемую нами работу.
тяжелые
правда есть еще одна ообенность — а откуда заказчик знает что ему нужно…
Спасибо за вашу позицию!
Вы совершенно правы, что ТЗ не стоит превращать в формальность!
И вы вдвойне правы, что нельзя исключать этап тестирования и отладки из процесса разработки сайта. В нашей практике этот этап собирает наибольшее количество вопросов, и позволяет решить «все эти мелочи и детали».
Важно, чтобы на этом этапе не возникло внезапного вопроса о смене CMS, например, или требований к нагрузке… Это не мелкое допиливание, а полная переделка. И именно от таких ситуаций защищает ТЗ!
Вы совершенно правы, что ТЗ не стоит превращать в формальность!
И вы вдвойне правы, что нельзя исключать этап тестирования и отладки из процесса разработки сайта. В нашей практике этот этап собирает наибольшее количество вопросов, и позволяет решить «все эти мелочи и детали».
Важно, чтобы на этом этапе не возникло внезапного вопроса о смене CMS, например, или требований к нагрузке… Это не мелкое допиливание, а полная переделка. И именно от таких ситуаций защищает ТЗ!
Читать Ваш текст невозможно. Работайте над стилистикой и орфографией. А ценность самого материала равна нулю.
Sign up to leave a comment.
Техническое задание: какие элементы должны быть прописаны, а какие – в уме