От Captain Africa
К bedal
Дата 22.11.2010 15:59:11
Рубрики Современность; Военные игры;

Грррр!

>ТЗ, по нынешним временам - обременение, вредно влияющее на конечный продукт.

Чтоб вам всем пусто было, кто считает что ТЗ -- обременение, вредно влияющее на конечный продукт.

Отсутствие ТЗ на гражданке это всегда следствие неграмотности управленцев. И только. И ВСЕГДА ведет к бардаку и затягиванию разработки. Собственно как только заказчик сказал "зачем ТЗ, сделайте оооооот так и красиво" и показал на пальцах как, можно заказчика посылать в далекое путешествие, ибо если деньги и удастся получить с него, то овчинка не будет стоить выделки, т.к. это "вооот так" обязательно будет сто раз меняться по ходу дела, и за те же деньги.

Грабли эти миллионы раз исхожены, и каждый раз находится новый гений, считающий что ТЗ не нужно.
От bedal
К Captain Africa (22.11.2010 15:59:11)
Дата 22.11.2010 16:49:43

Устарел такой взгляд, лет так двадцать тому (-)
От UFO
К Captain Africa (22.11.2010 15:59:11)
Дата 22.11.2010 16:40:20

У ТЗ масса достоинств, но один существенный недостаток...

Приветствую Вас!
>>ТЗ, по нынешним временам - обременение, вредно влияющее на конечный продукт.
>
>Чтоб вам всем пусто было, кто считает что ТЗ -- обременение, вредно влияющее на конечный продукт.

.....

>Грабли эти миллионы раз исхожены, и каждый раз находится новый гений, считающий что ТЗ не нужно.

У более-менее масштабных разработок не нулевой срок. За это время часто меняется "среда обитания", происходит и эволюция заказчика. Вот тут и начинаются проблемы.
Разработчик хочет всё закончить как есть и получить свои бабки. Заказчик уже не хочет получать это и начинается взаимное истребление. Хорошо, если изменения
не принципиальны, и их можно отыграть дополнениями и изменениями в ТЗ.
Однако, часто, от изначального ТЗ в "обнавленных" моозгах заказчика остаются рожки да ножки. В этой ситуации конфликт интересов неизбежен. Я такие вещи несколько раз разруливал на личной харизЬме. А несколько раз не вышло, да...



С уважением, UFO. aka Rider ww-2.info
От xab
К UFO (22.11.2010 16:40:20)
Дата 22.11.2010 16:50:31

Re: У ТЗ

>Разработчик хочет всё закончить как есть и получить свои бабки. Заказчик уже не хочет получать это и начинается взаимное истребление. Хорошо, если изменения
>не принципиальны, и их можно отыграть дополнениями и изменениями в ТЗ.
>Однако, часто, от изначального ТЗ в "обнавленных" моозгах заказчика остаются рожки да ножки. В этой ситуации конфликт интересов неизбежен. Я такие вещи несколько раз разруливал на личной харизЬме. А несколько раз не вышло, да...

Опять же это все намного проще разруливать, когда есть начальное ТЗ и делается процентовка.

Покрайней мере понятно насколько изменяется стоимость работ, какие подтвержденные бумагами объемы уже выполненны и кто, кому, сколько должен при измении первоначальных требований.

>С уважением, UFO. aka Rider ww-2.info
С уважением XAB.
От Claus
К Captain Africa (22.11.2010 15:59:11)
Дата 22.11.2010 16:09:04

Отдельные ситуации бывают, когда не нужно ТЗ, но в большинстве случаев оно необх

>>ТЗ, по нынешним временам - обременение, вредно влияющее на конечный продукт.
>
>Чтоб вам всем пусто было, кто считает что ТЗ -- обременение, вредно влияющее на конечный продукт.

Отдельные ситуации бывают, когда не нужно ТЗ, но в большинстве случаев оно необходимо.

У меня был проект, когда ERP дорабатывалась и внедрялась без ТЗ. Но были очень полные требования заказчика и активное участие в проекте и подрядчика и заказчика. Ну и главное - подрядчик входил в структуру группы компаний - его была возможность контролировать.

Другой пример - внедрение практически гововой системы (кстати разрабатывалась бывшими вояками). ТЗ делалось, но больше для проформы.

Но в большинстве случаев Вы абсолютно правы. Без ТЗ почти 100% вылезут вопросы по тому что входит в проект, а что нет и в каком виде проект должен реализовываться. А в итоге долгое и бестолковое разбирательство подрядчика и заказчика.
От Лейтенант
К Captain Africa (22.11.2010 15:59:11)
Дата 22.11.2010 16:08:28

В ряде случаев ТЗ вредно ( с точки зрения "интересов дела").

Когда нужно
1) Экстремально быстро.
2) Экстремально дешево.
3) Заказчик не может сформулировать требования потому что сам пока не понимает что ему надо.

Можно конечно сказать, что заказчики которым нужно (1) - авантюристы, которые (2) - жадины, а которые (3) - просто некомпетентные тупые кретины, но это уже совсем другая проблема.
От bedal
К Лейтенант (22.11.2010 16:08:28)
Дата 22.11.2010 16:50:53

Добавлю самое важное

Когда разработка даёт возможности, которых Заказчик не может предположить изначально.

А для скорости как раз лучше ТЗ иметь.
От RTY
К Лейтенант (22.11.2010 16:08:28)
Дата 22.11.2010 16:22:15

Re: В ряде...

>Когда нужно
>2) Экстремально дешево.

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

>3) Заказчик не может сформулировать требования потому что сам пока не понимает что ему надо.

Распространена практика, когда ТЗ пишет разработчик на основании общих пожеланий заказчика. Потом идет согласование конкретных положений и подписание документа.

>Можно конечно сказать, что заказчики которым нужно (1) - авантюристы, которые (2) - жадины, а которые (3) - просто некомпетентные тупые кретины, но это уже совсем другая проблема.

Достаточно распространена практика, когда надо максимально быстро и максимально дешево, а что конкретно - известно только в общих чертах.
Но без ТЗ разработано будет непонятно что, в результате в зависимости от того, кто лучше обладает даром "убеждения", или заказчик заплатит за то, что его не устраивает, или разработчик ничего не получит за свои труды.
От Лейтенант
К RTY (22.11.2010 16:22:15)
Дата 22.11.2010 16:37:13

Re: В ряде...

>В этом случае ТЗ необходимо для того, чтобы договориться о том, на какие параметры можно забить для получения этой самой экстремальной дешевизны.

Не забывайте, что ТЗ само по себе стоит денег.

>>3) Заказчик не может сформулировать требования потому что сам пока не понимает что ему надо.
>
>Распространена практика, когда ТЗ пишет разработчик на основании общих пожеланий заказчика. Потом идет согласование конкретных положений и подписание документа.

А потом заказчик говорит "я трактовал это совсем не так" или "я вашего птичьего языка не понимаю и просто доверился Вам". Дело в том, что многие заказчики могут понять "то это или не то чьл я хочу" только "потрогав руками" а для этого нужен прототип или хотя бы макет. Вот вместо бумажного ТЗ и занимаются прототипированием. Просто метод сбора требований такой, побочным результато мимеющий готовый продукт минуя стадию составления "бумажного" ТЗ.

>Но без ТЗ разработано будет непонятно что, в результате в зависимости от того, кто лучше обладает даром "убеждения", или заказчик заплатит за то, что его не устраивает

Еще бывает, что разрабочик опытный/умный, а заказчик - не очень и разработчик лучше понимает, что будет нужно заказчику в конечном итоге.

> , или разработчик ничего не получит за свои труды.

Если разработчик состоит в штате заказчика - за труды он получает. Если не состоит, но контракт оплачивается по принципу "время + материалы", например почасовая оплата, то тоже получает.
От Claus
К Лейтенант (22.11.2010 16:37:13)
Дата 22.11.2010 16:48:01

Re: В ряде...

>>В этом случае ТЗ необходимо для того, чтобы договориться о том, на какие параметры можно забить для получения этой самой экстремальной дешевизны.
>
>Не забывайте, что ТЗ само по себе стоит денег.
Как правило это относительно дешевый этап проекта.Финансовые риски на нем меньше, чем на остальных.

>А потом заказчик говорит "я трактовал это совсем не так" или "я вашего птичьего языка не понимаю и просто доверился Вам".
Это говорит лишь о том, что ТЗ плохо составлено. Правда как вариант о том, что Заказчик его толком не читал.
Но нормальный подряжчик, как и заказчик, включают ТЗ в договор. В этом случае разобраться кто и что кому должен гораздо проще.

>Дело в том, что многие заказчики могут понять "то это или не то чьл я хочу" только "потрогав руками" а для этого нужен прототип или хотя бы макет.
Прототип стоит как правило заметно дороже ТЗ, если речь не идет о доработки готовой системы под нового заказчика.

>Еще бывает, что разрабочик опытный/умный, а заказчик - не очень и разработчик лучше понимает, что будет нужно заказчику в конечном итоге.

Это очень редко, просто потому что заказчик лучше знает свою область работы.
От Claus
К Лейтенант (22.11.2010 16:08:28)
Дата 22.11.2010 16:12:09

По п3 Вы не правы - в таком случае разработка ТЗ это просто 1й этап проекта.

А после делается дибо допник, либо новый договор.

По пунктам 1 и 2 - в итоге скорее всего получиться дольше и дороже, из-за переделок. Хотя формально сдать систему и отчитаться могут запросто, а потом долго доводить до кондиции.
От Лейтенант
К Claus (22.11.2010 16:12:09)
Дата 22.11.2010 16:16:27

Re: По п3...

>По пунктам 1 и 2 - в итоге скорее всего получиться дольше и дороже, из-за переделок. Хотя формально сдать систему и отчитаться могут запросто, а потом долго доводить до кондиции.

В ряде случаев нужно "пусть плохо но сейчас", а "хорошо, но потом" вообще нафиг не нужно.
В другой части случаев нужен прототип, тобы понять "а оно вообще надо?".