Комментарии 8
ТЗ никому не нужен
ТЗ = техническое задание, т.е. это средний род! Соответственно, правильно писать «ТЗ не нужно».
> Только при наличии подробного ТЗ
> На небольших проектах ТЗ не нужен
В первом варианте подробное ТЗ, во втором без ТЗ. Нет варианта не подробного тех. задания. Документ в котором описываются основные моменты, без него как раз не понимаю как можно выполнять работу. Хотя и в этом случае скорей всего до момента возникновения первого конфликта с заказчиком, который приведет в последующем к варианту «Только при наличии подробного ТЗ».
> На небольших проектах ТЗ не нужен
В первом варианте подробное ТЗ, во втором без ТЗ. Нет варианта не подробного тех. задания. Документ в котором описываются основные моменты, без него как раз не понимаю как можно выполнять работу. Хотя и в этом случае скорей всего до момента возникновения первого конфликта с заказчиком, который приведет в последующем к варианту «Только при наличии подробного ТЗ».
К большому сожалению, между тем, как необходимо работать и между тем, как оно на самом деле, лежит пропасть. Писать ТЗ должен профессионал, а не тот, кто видит проект у себя в голове, вроде все понимает, и считает, что разработчики тоже все уже видят и понимают, без лишних документов и пояснений. Большинство могут просто картинки страниц прислать, которые им сделал дизайнер. Абсолютно не понимая, что это не ТЗ, а лишь один из пунктов этого ТЗ, при чем на предпоследней стадии. А еще заказчики абсолютно не делят специалистов на продакт менеджеров, аналитиков, архитекторов, тимлидов и простых разработчиков. Для многих — это один человек, ТЫЖПРОГРАММИСТ! И это я говорю не просто про рынок СНГ. Это также касается ЕС и США. По уму работают считанные единицы (в общемировом объеме).
Вы так говорите как будто это что то плохое.
Заказчик не должен разбираться в составление ТЗ для программного продукта и делить продукт на разработчиков, менеджеров и всех остальных кто участвует в разработке. Он разбирается в своей сфере на все остальное чаще всего у него просто нет времени. Он ставит задачу в общем представление, а задача исполнителя ее уточнить и описать(а потом уже выполнить).
Составлением ТЗ занимается исполнитель с правками от разработчиков, дизайнеров и всех остальных кто задействован на проекте и в конце от самого заказчика. Скриншоты(хотя в нашем случае максимум это были наброски или прототип на бустрапе) от дизайнера в ТЗ тоже не плохо, они дают представление о конечном продукте заказчику(что есть хорошо).
P.S. Конечно это все мое имхо, того что было на практике. Если у кого то работает что то другое, то и отлично. Менять это только из-за того что так написано на хабре не стоит.
Заказчик не должен разбираться в составление ТЗ для программного продукта и делить продукт на разработчиков, менеджеров и всех остальных кто участвует в разработке. Он разбирается в своей сфере на все остальное чаще всего у него просто нет времени. Он ставит задачу в общем представление, а задача исполнителя ее уточнить и описать(а потом уже выполнить).
Составлением ТЗ занимается исполнитель с правками от разработчиков, дизайнеров и всех остальных кто задействован на проекте и в конце от самого заказчика. Скриншоты(хотя в нашем случае максимум это были наброски или прототип на бустрапе) от дизайнера в ТЗ тоже не плохо, они дают представление о конечном продукте заказчику(что есть хорошо).
P.S. Конечно это все мое имхо, того что было на практике. Если у кого то работает что то другое, то и отлично. Менять это только из-за того что так написано на хабре не стоит.
Вы говорите о простых сайтах. О блогах, интернет-магазинах, каталогах и т.д. А представьте, что ваш заказчик — это крупный банк, которому нужна целая информационная сеть по всей стране, с серьезной криптозащитой данных, биг дата и т.п. А вам дадут только конечные скриншоты. И что вы с этим будете делать? Плюс не стоит путать такие понятия, как сайт и программный онлайн комплекс, с доступом через домен. Это совсем разные вещи и разный подход в разработке. И когда, ничего не понимающий заказчик, обращается за помощью к людям, которые просто программисты, то лично я, знаю, чем все это заканчивается. Программист пишет код, он не разбирается в построении архитектуры (иначе бы он работал архитектором), и не разбирается в бизнесе (иначе бы он был бизнесменом), и не умеет видеть всю картину целиком (иначе бы он работал аналитиком). Именно по этой причине, корпоративный клиент и не работает с мелкими компаниями, которые занимаются разработкой. А если вы мне описываете пример про разработку сайта за 500 долларов, то это не тот случай. Я говорю о программных комплексах, которые стоят миллионы!
Тогда мы с вами говорим на разные темы. Ваш случай я вообще не рассматривал. Разработка ведется только при наличии подробного ТЗ. Что тут обсуждать? Я говорил о проектах где этот вопрос имеет смысл.
Да и в вашем случае с крупным банком сам заказчик проект не ведет, с его стороны этим занимаются такие же «манагеры».
Да и в вашем случае с крупным банком сам заказчик проект не ведет, с его стороны этим занимаются такие же «манагеры».
Отлично написано. Хочу поблагодарить автора за квинтэссенцию мыслей. Зачастую, на мой взгляд, подобные статьи подвергаются критике за очевидность смысловой нагрузки. Я же хотел вместо критики сказать автору спасибо за текст, который субъективно является, скажем так, стимулятором для повторного переосмысления. Повторяя в структурированной виде тезисно очевидные и логичные доводы «за», такие тексты лично мне помогают в очередной раз обратить внимание на все уровни проектирования. +
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От идеи до реализации. Часть третья — создаем ТЗ (техническое задание)