Как стать автором
Обновить

Комментарии 29

Я лично не люблю ТЗ, и чаще всего они пустая трата времени. Но есть но…

Когда здаешь проект, тебе говорят — а можно мне вот такую маленькую фишку доделать, за которой идет еще одна и еще одна.

Имея ТЗ можно избежать такого конфуза.
О да, маленькая фишечка. Знакомо. Из-за них функционал программы иногда вырастает в разы :)
Можете дальше комменты не читать ;) Автор — настоящий тролль, а статья — пустая провокация, дабы вы возмутились и начали защищать необходимость написания ТЗ.

Все ниже написанные комментарии собственно так и делают кроме поддевок автора.

Внимательнее на дорогах хабра. Еще остались мошенники, которые пытаются украсть ваше время.
Как я вас понимаю… А если дедлайн из-за таких фишек перерастает в два раза запланированного, ипричем ВИНОВАТ ПРОГРАММИСТ! И его штрафуют на деньги!!! Вот это печально!
Сначала я очень удивился, а потом увидел тег «проектирование сайтов» — и мне сразу стало все понятно.

IT-разработка не заканчивается на сайтах на похапе.
Разработка веб-сайтов отличается от разработки чего угодно другого так же, как Христос отличается от Аллаха. То есть только вопросом религиозных предрассудков. Больше ничем.
Вот, теперь за версту видно эксперта с мировым именем по всему на свете.

К слову, проще сказать, чем Христос похож на Аллаха, чем в чем они различаются.
хз, но на мою короткую память, аналогом Христа в исламе был некий г-н Магомет. Я не путаю? :) А пост отличный, я долго смеялся.
Не соглашусь.
Я «рядовой» программист. Наше ПО достаточно быстро развивается и настроено на введение нового функционала, необходимого нашим далеко не маленьким клиентам (а ля «Газпром-нефт», «Мострансавто» и т.д). Так вот, к чему я веду: я, да и мои коллеги, уже устали переделывать интерфейсы и логики нововведений, которые были добавлены без внятного ТЗ. Теперь же всегда, подчеркиваю, всегда мы требуем нормальное ТЗ. Без ТЗ нет и работы. Пусть лучше менеджеры и клиенты создадут ТЗ, а мы в это время сделаем что-то новое или поправим найденные недочеты в старом, а уж после получения ТЗ мы сделаем то, что от нас хотят. Если им не понравилось то, что получилось, то это не наша вина, а их. Пусть меняют ТЗ, а мы пока будем делать новое другому клиенту. И так далее. Поверьте, это сильно экономит наше (разработчиков) время, а так же дисциплинирует клиентов, и уже не получаешь от них типа «Хочу тааакую фичу, чтобы было круто! Сделаете?».
Вот в этом и проблема вашего менеджмента. Когда клиент говорит «хочу ещё такую фичу», все должны прыгать от радости: ведь он хочет заплатить вам ещё больше! Как, разве он не заплатит дополнительных денег за дополнительные фичи? Вот в этом и проблема вашего менеджмента.
Мы работаем не на продаже продукта, а на продаже услуги, это значит то, что клиент нам платит все время. Так что если клиенту отказать в нужном ему функционале, то он уйдет к конкурентам. Но это не значит, что мы пытаемся удерживать всех.
Григорий, большинство людей хотят получить побольше, а заплатить поменьше.
вы только написали 500 тз… а были случаи когда возникали разного рода конфузы? или же у вас все клиенты идеальные молодые ничего не понимающие в сайтостроении девушки с деньгами? тогда мы идем к вам
НЛО прилетело и опубликовало эту надпись здесь
А как Вы оцениваете срок разработки и стоимость не имея ТЗ? Очень часто в ТЗ всплывают мелочи с точки зрения заказчика, которые для него на столько мелки, что он не говорил о них устно, а на реализацию такой «мелочи» уйдет человекомесяц. Не хотелось бы ошибиться в сроках и цене на пару месяцев из-за подобных «мелочей». Моя команда никогда не берется за работу не имея четкого ТЗ.
Классический тролль на хабре — клево, а я думал время таких уже ушло, остались только малолетние идиоты, которые только и могут орать %brandname% говно. А тут так чистенько, народ ведется.
Для сомневающихся, почитайте топики автора, грамотно и чисто поливается грязью все подряд :)
Автору +, хоть не скучно.
Автор и сам признается на своем жж, что его статьи — всего лишь провокация.
Что вы скажите заказчику: «я хочу такое изменение», а потом «мне это не понравилось, давайте попробуем этак». А что скажите разработчикам, которые выполнили задачу неправильно просто потому что не понимали что именно надо сделать и что именно требуется заказчику?
А структуру и логику работы проекта кто будет делать? Менеджер на коленках во время работы? А если вдруг он с ужасом поймёт, что не может это всё расписать? Или ещё хуже, поймёт что человек для реализации проекта в заданные сроки не хватает, а денег собственно больше не дадут? Вся концепция проекта, все механизмы работы внутри него, даже алгоритмы, по сути весь проект на бумаге это и есть полное ТЗ. Нет можно конечно работать методами ЭП, но я не думаю что получится что-то дельное, к тому же уже давно хорошо сочетаются и классическое ТЗ и концептология и ЭП. Автор вы пишите сущий бред. Если вы считаете что абсолютно все программисты, дизайнеры, тестеры и прочие члены команды мыслят в одном направлении и могут даже не разговаривать во время разработки (настолько хорошо понимают друг друга), то вы глубоко заблуждаетесь. Также вы глубоко заблуждаетесь если считаете, что каждый ПМ способен и вести проект и по ходу его додумывать и разбирать все проблемы. Такие есть, но их не так много.
В советское время была прослойка между заказчиком и программистом. Она называлась «постановщик задач». Странно, что она куда-то испарилась. А ведь все так логично — нельзя требовать ТЗ от заказчика, это не его компетенция. А программист (кодер) слишком туп, чтобы осознать задачу целиком. По логике функции постановщика задачи должны лежать на на том, что ныне называется «менеджер проекта».

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

Но вот ТЗ внутри компании — спорный вопрос. Если разработчику нужно что-то разработать для внутреннего проекта, например, сайт для компании, в которой он работает. И он требует с начальника написать ему ТЗ. Мне кажется, в этом случае, ТЗ — лишняя трата времени на формальности.
НЛО прилетело и опубликовало эту надпись здесь
У нас на проекте ТЗ не является статичной единицей — добавляются новые разделы заказчиком, старые правятся ввиду неактуальности начальной версии (благо заказчик очень и очень вменяемый — не требует сделать вчера и хочет вполне реализуемых вещей). Сейчас вышла некоторая заминка и ТЗ уже как пару месяцев не модифицируется, хотя работы идут полным ходом. И уже начались проблемы — по сути само ТЗ находится в головах двух человек — заказчика и нашего главного программиста — мы стали просто забывать некоторые нюансы работы разделов проекта. Было бы актуальное ТЗ — открыл, посмотрел, подправил что надо. А так приходится рыться в багтрекере в поисках зацепок, разбираться в коде, хотя нужна просто документация на проект.
Полный бред написали.
Я по своему опыту знаю, что делать что-то, даже малюсенький флэш компонент без ТЗ — это раскладывать перед собой грабли. Самое минимальное ТЗ на страничку позволяет избежать кучи проблем в будущем. Особенно опасны устные договоренности, типа «сделай вот как тут». Совсем недавно был очередной тупой видеоплеер, который пришлось полностью переделывать с нуля именно из-за таких вот договоренностей. Если заказчик или манагер не предоставляет мне ТЗ, я трачу свое оплаченное время на его составление и согласование, что в последствии избавляет меня от неимоверной кучи геморроя.
И можете вычеркнуть меня из специалистов. Я буду работать с более вменяемым и понимающим что ему нужно заказчиком.
Веб-разработка такая разработка… )
Я пишу ТЗ за деньги
Если не хотите заработать на ТЗ — передавайте заказчика мне

лучше один раз прочитать Getting Real и не тратить свое время на такие псевдо-статьи…
Офигенный подход. Сделайте мне сайт визитку за 10 000 р. с статическими страницами. А по ходу — добавьте туда функционал портала, социальной сети и космической программы НАСА за все эти годы.
Стоимость? Так мы же договор на 10 000 р. заключили. Вот и воспринимайте все правки как ману божью — главное — не подавитесь.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории