От bedal
К xab
Дата 22.11.2010 15:42:56
Рубрики Современность; Военные игры;

На гражданке всё же распространяются проекты без ТЗ

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

Более современный подход - циклическая разработка, полноценное ТЗ появляется только на финальном этапе.

От xab
К bedal (22.11.2010 15:42:56)
Дата 22.11.2010 16:13:19

Re: На гражданке...

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

Вам сильно повезло, если при таком подходе вы умудряетесь закрывать проекты не себе в убыток.

>Более современный подход - циклическая разработка, полноценное ТЗ появляется только на финальном этапе.

Как же вы при таком подходе бюджет проекта планируете?

С уважением XAB.

От Лейтенант
К xab (22.11.2010 16:13:19)
Дата 22.11.2010 16:17:39

А как Вы планируете бюджет на составление ТЗ? (-)


От xab
К Лейтенант (22.11.2010 16:17:39)
Дата 22.11.2010 16:23:37

Re: А как...

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

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

С уважением XAB.

От Лейтенант
К xab (22.11.2010 16:23:37)
Дата 22.11.2010 16:45:12

Бу-га-га

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

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


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

Вообще-то стадия сбора и анализа требований в зрелых методологиях рзработки занимает 30-40% общего времени, отводимого на проект и сравнимую с этим показателем долю денег. ТЗ котрое стоит "на порядки" (т.е. в 100 и более раз) меньше чем сам проект - ничем иным, кроме имитации и профанации быть не может. По крайней мере, если речь идет о нетиражируемых бизнес-приложениях.

От Юрий А.
К bedal (22.11.2010 15:42:56)
Дата 22.11.2010 16:04:00

Может я не в той России живу..... :))

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

Полнейшая ерунда.

>Более современный подход - циклическая разработка, полноценное ТЗ появляется только на финальном этапе.

Интересно, а как Вы смету на проект составляете?

От Claus
К Юрий А. (22.11.2010 16:04:00)
Дата 22.11.2010 16:15:07

Это от проекта зависит - на некоторые и без ТЗ сметы составляются.

Мало того, встречаются и чудеса, когда на очень сложные и очень дорогостоящие проекты договора без сметы заключаются. Результат, правда, у таких чудес предсказуем.

От Лейтенант
К Юрий А. (22.11.2010 16:04:00)
Дата 22.11.2010 16:11:22

Смету на проект без ТЗ составляют премерно так же как смету на ТЗ :-)

Или кто-то думает что хорошее ТЗ это быстро и дешево?



От Secator
К Лейтенант (22.11.2010 16:11:22)
Дата 22.11.2010 16:47:02

Re: Смету на...

>Или кто-то думает что хорошее ТЗ это быстро и дешево?

Без ТЗ это либо дойка заказчика либо кидание исполнителя.
С уважением Secator

От Captain Africa
К bedal (22.11.2010 15:42:56)
Дата 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 - в итоге скорее всего получиться дольше и дороже, из-за переделок. Хотя формально сдать систему и отчитаться могут запросто, а потом долго доводить до кондиции.

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

От RTY
К bedal (22.11.2010 15:42:56)
Дата 22.11.2010 15:54:30

Re: На гражданке...

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

>Более современный подход - циклическая разработка, полноценное ТЗ появляется только на финальном этапе.

Когда пройдено по всем граблям, которые можно было обойти, если бы ТЗ писалось изначально?

От bedal
К RTY (22.11.2010 15:54:30)
Дата 22.11.2010 16:49:07

Да невозможно ТЗ написать изначально

то есть возможно, если делать "для прошедшей войны". Пример без-ТЗ разработок, при этом вполне функциональных и не совсем гражданских - DARPA-проекты, да хоть тот же интернет :-)

От Secator
К bedal (22.11.2010 15:42:56)
Дата 22.11.2010 15:51:06

Re: На гражданке...

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

>Более современный подход - циклическая разработка, полноценное ТЗ появляется только на финальном этапе.

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

С уважением Secator

От bedal
К Secator (22.11.2010 15:51:06)
Дата 22.11.2010 16:47:51

не, не так

Всё чаще изготовители могут сделать больше, чем Заказчик может предположить на стартовом этапе.

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


От Лейтенант
К Secator (22.11.2010 15:51:06)
Дата 22.11.2010 16:01:43

Все не так одзначно

Четкие и формализованные процедуры разработки (включая сбор требований по формализованным методикам и составление ТЗ) при приаввильном применении дают следующие приемущества:
- ниже риски полногой неудачи проекта
- выше качество продукта
Однако треугольник качество-сроки-стоимость никто не отменял. Роэтому очень качественно получается долго и дорого. Поскольку долго и дорого заказчика как правило в принципе не устаривают, то получаем на практике попытку сделать вс е качественно (с примененим серьезной методологии) но быстро/дешево. Результат полкчается сами понимаете получается хуже чем в случае когда все осознанно делается "на коленке", поскольку при этом энергия не тратится на обман и самообман.