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

В итоге надо составить два ТЗ

1) Технологичное.
Как этот проект должен функционировать внутри и по каким протоколам.

2) Формошлепное.
Где какие формочки должны заполняться и как вводиться данные, собираться статистика, и т.д.

Т.е. придется изрядно потрудиться только для того чтобы это все подробно описать.

Какой процент от проекта закладывать на ТЗ?

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

Здравствуйте, c3p0, Вы писали:

C>Какой процент от проекта закладывать на ТЗ?

процентов 65

Здравствуйте, c3p0, Вы писали:

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

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

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

P.P.S. В ГОСТе откуда пришло ТЗ есть еще и такой документ как "эскизный проект", вы решили видимо всё в ТЗ сделать.

UPD
Кстати, в чём смысл вопроса "какой процент" если итоговую трудоемкость проекта можно (пытаться) оценивать только после согласования ТЗ/эскизного проекта?

Здравствуйте, c3p0, Вы писали:

C>Какой процент от проекта закладывать на ТЗ?

У нас 25%

_>UPD
_>Кстати, в чём смысл вопроса "какой процент" если итоговую трудоемкость проекта можно (пытаться) оценивать только после согласования ТЗ/эскизного проекта?

Можно сделать оценку, основываясь на требованиях любой детализации. Заложить в оценку риски.
Например, оценить в 3 млн. рублей. На тз декларировать 15-25%.

Ну и далее, получаем предоплату, скажем 20%.
Делаем ТЗ. После того, как ТЗ готово — уточняем оценку.

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

По этой схеме у разработчика есть риск остаться без проекта и недополучить 80% контракта.
У заказчика есть риск потерять 20% контракта в том случае, если разработчик окажется некомпетентным и а) Не сможет составить нормальное ТЗ б) Резко задерёт стоимость после его составления.

Основных способов снижения рисков для заказчика, в данном случае три

1) Подготовка детальных требований со своей стороны.
Чем детальнее требования, тем меньше будет закладываться рисков, тем точнее будет оценка.
2) Снижение процента за ТЗ до 10 и менее процентов. В идеале 1%.
3) Внимательно выбирать разработчика. Чем релевантнее опыт разработчика, тем меньше рисков.

Мой вопрос о том, какой процент считается "приличным" и "профессиональным".

65% — явно не прилично и не профессионально

5% — субъективно мало. Большой рик для разработсика — поработать аналитиком и отдать проект на сторону.

10-25% кажется приемлемым. Вокруг них можно договариваться.

>P.S. Значение "ТЗ" для успеха проекта не надо преувеличивать, всё равно самое главное это диалог с заказчиком и заинтересованность обеих сторон в результате.

Заинтересованность обоих сторон в результате — вещь нематериальная. Сегодня она есть завтра ее нет.
Без ТЗ или с поверхностным ТЗ можно легко работать по итерациям, но каждый заказчик желает заранее знать свои затраты. Поэтому без ТЗ тут никак. Это материальный актив, на котором держится проект.

У нас 25%

Спасибо.

Здравствуйте, c3p0, Вы писали:


C>65% — явно не прилично и не профессионально

не согласен. если под ТЗ понимать нахрен никому не нужную формальность или делать его спустя рукава, то да — 10-20%
при грамотно разработанным ТЗ, исполнитель средней квалификации сделает работу, поэтому хорошее ТЗ -основа основ и как правило одна из дорогих составляющих любого проекта.

Здравствуйте, c3p0, Вы писали:


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

тут противоречие, вроде "без ТЗ никак" и "на этом держится весь проект", ваша оценка 10-15%.
не логично. я же говорю 65% и не меньше!

Здравствуйте, c3p0, Вы писали:

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

Парадокс в том, что пока не напишете Т.З. -- вы не знаете сколько реально стоит разработка. А раз не знаете сколько она стоит -- то какой разговор о проценте?

Вообще Т.З. -- это уровня всяких там яндексов, когда само Т.З. -- сотни тыс. у.е. стоит.

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

Очень хорошая система MS TFS. Многие не понимают ее и сразу называют дерьмом. Разберитесь как работает и будет вам счастье.

Здравствуйте, c3p0, Вы писали:

C>Можно сделать оценку, основываясь на требованиях любой детализации. Заложить в оценку риски.
C>Например, оценить в 3 млн. рублей. На тз декларировать 15-25%.

C>Ну и далее, получаем предоплату, скажем 20%.
C>Делаем ТЗ. После того, как ТЗ готово — уточняем оценку.

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

Всё что вы описали звучит хорошо, но мне кажется такого клиента хрен найдешь. Мне встречались такие — хочу результат за фиксированную стоимость и не хочу платить за разбитое корыто (ТЗ отдельно от результата). Назовите стоимость я пройдусь по рынку и сравню, с поправкой на репутацию исполнителей.

Шарпкодер про 25% пишет, интересно что он конкретно имеет в виду. Возможно они типовое решение кастомизируют, там рисков связанных с оценкой меньше.

Здравствуйте, sr_dev, Вы писали:

_>Шарпкодер про 25% пишет, интересно что он конкретно имеет в виду. Возможно они типовое решение кастомизируют, там рисков связанных с оценкой меньше.

Конечно типовое.

Если проект требует предварительных научных исследований, то Т.З. может стоить 99% от стоимости всего проекта.

_>Всё что вы описали звучит хорошо, но мне кажется такого клиента хрен найдешь. Мне встречались такие — хочу результат за фиксированную стоимость и не хочу платить за разбитое корыто (ТЗ отдельно от результата). Назовите стоимость я пройдусь по рынку и сравню, с поправкой на репутацию исполнителей.

Я таким называю стоимость результата без ТЗ.
Они проходятся по рынку и если цена устраивает, начинаем с ними писать ТЗ.

_>Шарпкодер про 25% пишет, интересно что он конкретно имеет в виду. Возможно они типовое решение кастомизируют, там рисков связанных с оценкой меньше.

Да, я тоже типовое решение кастомизирую. Т.е. продаю свой софт плюс кастомизацию.
Все риски и подводные камни, связанные со своим софтом известны. Остается ТЗ на кастомизацию.

Парадокс в том, что пока не напишете Т.З. -- вы не знаете сколько реально стоит разработка. А раз не знаете сколько она стоит -- то какой разговор о проценте?

У меня давно уже нет такого парадокса. Я знаю, сколько стоит разработка с какой-то вероятностью и точная стоимость мне не требуется.
Разговор о проценте нужен
1) Для того, чтобы обосновать заказчику стоимость ТЗ.
2) Чтобы дать заказчику понять, что ТЗ — это один из этапов проекта.