В праве ли программист требовать от клиента подробное техническое задание где будет прописано всё вплоть до расположения реквизитов на форме и цветов ячеек отчета?

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

Когда терпение лопнуло и стало ясно, что здесь что то изначально пошло неверно предложил клиенту составить точное техническое задание чтобы не приходилось ничего переделывать до сдачи проекта, а списки правок делать уже после за отдельную оплату (кроме тех правок, которые нужно делать по вине ошибки программиста).

Правильный ли это подход или клиент может в ходе разработки проекта подкидывать дополнительных хотелок так чтобы программист это всё делал в рамках той же цены?

И правильно ли в таком случае перейти на почасовую оплату с фиксированной чтобы избежать снижения себестоимости своей работы?

Чем менее детализировано ТЗ, тем выше ценник.

Как рынок диктует так и правильно.
Если видишь риски но клиент хочет фиксированный ценник - закладываешь риски в стоимость.
Или почасовка.

(0) На проектах программисты с клиентами не работают, а на шабашках оплата почасовая, пусть хоть обподкидываются

Подробность технического задания, как ни странно, не приближает его к однозначности.

Оно должно состоять из утверждений, каждое из которых можно однозначно оценить с позиции истинно/ложно. А воды про состав и расположение реквизитов можно на три пачки A4 нас*ть - ясности не прибавится.

Клиент должен дать понятное требование, которое должно быть зафиксировано. Реализуешь и идешь по пунктам. Реализовано? Да! Следующий пункт. Если есть пожелания по доработки - это отдельная работа.

(0) как правило клиенты выставляет техническое требование , исполнитель пишет ТЗ.

В свое практике ТЗ вообще не использую. Иду Итерационным способом прототип, преверсия , версия.

Кому нужны технические задания? Нужно писать функциональные требования

(3) >на шабашках оплата почасовая
что даже по исправлению ошибок сделанных самим прогером?

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

Бывает, конечно, что задача слишком расплывата.
Тут либо настаивать на почасовке, либо на более детальной проработке.
Это ж твои деньги. Клиенту ессно удобнее вот так, как у тебя получилось.
Сплошная выгода. За твой счет.
(6) И какая схема оплаты в твоей практике? Для внешних клиентов?

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

Заказчик пишет ТЗ, Пишет ТП, пишет код, Тестит Код, Запускает в продакшн, передает исполнителю деньги,

"вплоть до расположения реквизитов на форме и цветов ячеек отчета" - если делать нефиг, то да. В стоимость работ должен быть заложен риск (примерно 30%) как раз на вот такие случаи.

(0) Уровень подробности определяется здравым смыслом и важностью требований.
В идеале, ТЗ должно быть.

В реальности (в условиях крупных задач, периодически изменяющихся требований и прочих "прелестях") не всегда получается разработать ТЗ на весь проект целиком с нужным уровнем подробности. И вот тут спасает волшебное слово Agile.

Есть такой анекдот: Идут по парку 2 рабочих, один ямку выкапывает, а второй закапывает. Прохожий спрашивает:
- Зачем первый выкапывает, а второй закапывает?
А они отвечают:
- Закапывает не второй, а третий, второй должен был в ямку дерево сажать, но заболел и не вышел на работу.

Так и у Паши: Клиент озвучивает пожелания, кодер кодит, а консультанта-аналитика, который должен "сажать дерево" и придавать смысл всему происходящему нету

(14) > "И вот тут спасает волшебное слово Agile"
Это для программистов волшебное слово. А для внешних клиентов - матерное. Ибо они в массе хотят сразу бюджет подбить.

(15)как раз такие есть аналитик. Но он появился гораздо позже.  И сейчас успел только нарисовать макеты. А функционал постоянно приходится изменять. При этом в проекте 50% это интерфейс с хитрым алгоритмом работы. То есть в зависимости от выбранных значений открываются те или иные доп поля и закладки. поэтой причине если что меняется, то приходится много переделывать.

(14)(16)в чем суть поясните вкратце? Я по Скрамбу имел только опыт работы но там всегда почасовка - набираешь задачек на неделю, оцениваешь их в часах и в конце недели сдаешь и получаешь следующие порции.

(17) Суть в том, что внешние клиенты любят водопад и бюджет, а не аджайл и почасовку.

(18)ознакомился а Agile.  Получается что  там каждый раз допускается пересмотр ТЗ для внедрения нового функционала и проект может координально меняться.  Но в этом случае как оценивать работу? только по факту по затраченному времени. правильно?

(0) если клиент неизвестный, нет доверия и опыта работы, а требования крайне зыбкие, - есть хороший вариант: пишешь то как понял эти требования и как будешь реализовывать, отдаешь заказчику он подписывает и все. делается только то что за подписью, остальное за отдельные деньги. если он возвращает не подписывая с уточнениями - снова переписываешь и засылаешь на подпись. если вернет раза 4 - проще отказаться, это значит что аппетит приходит во время еды и он никогда не будет доволен. предложить почасовку.

(1) +1. Маньяк правильно формирует цену на свои работы. Сразу надо брать за все, с учетом будущих хотелок: не согласны, ну и ладно, мы остались свободными от головной боли и бесполезной потери времени.

(21)это неверный подход. никогда не знаешь заранее какие хотелки будут у клиента если проект на целый год. Нововведения на рынке диктуют новые потребности. А каждая новая хотелка - это месяц работы. Например, интеграция с очередной новой CRM Системой или  подключение к новому сервису API, которые появляются время от времени.

(22) прикинь, а у него работает такой подход!

(23) Дураки не переводятся

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

(23)не сравнивайте 1с и  онлайн сервисы, которые разрабатываются с нуля.

(0) ТЗ должно быть достаточно полным и однозначным для его выполнения. Если ты его читаешь и у тебя возникают сомнения в том как надо делать, значит ТЗ не полное и его нужно дополнить и/или детализировать.
Подробности о расположении реквизитов и цветов ячеек зависят от конкретного задания, если это влияет на эргономику и клиенту это важно, значит эти подробности должны быть в ТЗ.
Дополнительные хотелки недопустимы. ТЗ согласовывается с заказчиком и подписывается обеими сторонами. Все дополнительные работы должны идти по отдельному заданию. Бывает так, что заказчик что-то забыл предусмотреть. Если он забыл что-то существенное, без чего теряется смысл задания, тогда задание нужно пересматривать и делать либо доп.соглашение, либо переписывать задание полностью. Соответственно стоимость тоже должна меняться. Если что-то не существенное, типа "нарисуйте нам еще котиков в отчете", то это как отдельная доработка.

(25)ну так разве для такой роли не подходит ежемесячная оплата (оклад) ? когда ты сдаешь себя в аренду оговаривая ежемесячную сумму которую тебе будут платить при 8 часовой загруженности 5 раз в неделю? Или в этом случае клиент будет опасаться что ты не все 8 часов вовлечен в проект?

(26) ты задал вопрос на сайте 1сников, друг) не заметил? Твое дело воспринимать советы, а не "оскаливать молочные зубы")

(27)вот и я так считаю. а клиент иногда хочет в рамках оговоренного бюджета  всунуть туда другие хотелки которые по отдельности бы стоили приличных денег.

(28) Не подходит, тут усталость не является мерилом работы, а 8 часов в день неизвестно чего ничего не стоят

(28) даже если вовлечен на 100% или больше - клиенту важен результат. Или повод не платить за работу, которая даже происходила. Но клиент не станет в этом признаваться.

(28) Подходит, если ты 100% времени пилишь фичи одного клиента. Аджайл - про контроль использования этого времени.

(29)я не разделаю 1с-ников от обычных разработчиков. Когда речь идет о допиливании типовой - это одно. Но когда разрабатывается проект с нуля здесь правила другие. Всего не предусмотреть.  1с-ник может быть хорошо подкован в бухгалтерии, в складском учете, в торговле но когда ему дают нестандартную хрень разработать с нуля то там не будешь знать чего нужно какие нужны отчеты какие нужны связи с другими сервисами.  Потому что проект этот индивидуален. И не важно 1с-ник его делает или веб-разработчик.

(32)но у программиста эффективных часов работы в день не 8 а меньше. Эффективность теряется. Либо надо делать перерывы.

(34) Там будет важно, готов Заказчик ли платить или ему нужен будет любой повод чтобы не платить.

(34) Если ты нихрена не знаешь, то как же ты смог озвучить фиксированную цену? От балды? ССЗБ

(35) А ты никогда не слышал историй о том, как разработчики в одно лицо "закрывали" ЛУРВ взамен 160 часов на 240 или 320 часов?

(37)на это как раз нужно техническое задание чтобы озвучить фиксированную цену. Все до мелочей. Тогда можно разбить каждую задачу на подзадачу и оценить время необходимое на решение того или иного функционала. И сделать смету от которой уже отталкиваться.
(38)не понимаю о чем ты. Знаю только что один разработчик вынужден был работать на одном заводе целый год потому что некорректно составил договор и на него наехали и реально угрожали ему физической расправой. Вот он и сидел пилил конфигурацию для порохового завода забесплатно оставшийся год и не мог никуда свалить.   Если вы про это.

кот_с_лампой.жпг

Тьху, да это же Пашо, ну ёмаё, как я мог так лохануться...

(39)"на это как раз нужно техническое задание чтобы озвучить фиксированную цену. Все до мелочей."

такая работа тоже стоит денег, как вариант - нанять третью сторону для написания ТЗ

(42)полностью согласен с вами.   Лично я не смог написать такое техническое задание потому что не видел полную картину что нужно клиенту а у клиента было только несколько подобных сервисов у их конкурентов. Сами они тоже не смогли составить тех задание, только перечислили то что им нужно будет без детализации. потом они взяли аналитика и переложили на него всю задачу но до полноценного технического задания еще очень далеко.

(39) // не понимаю о чем ты.

Поэтому тебе и приходится вот теперь и обсуждать подобную ерунду.

А ерунда в том, что тебя нагибают задарма, как того самого разработчика с завода.

(44) тут главное помнить главное правило при изнасиловании:  ... расслабься!

надо было не тз просить а на эджайл переходить и почасовку

(46)ну так и происходит сейчас. Предложил несколько вариантов клиенту. Один из них почасовка. Один из них точное ТЗ и доработки по отдельному тарифу после сдачи основной работы либо фиксированный оклад за 8 часовой день на время проекта но по рыночной цене программиста.

(47) есть еще вариант - оплата за каждую итерацию

те ты перед итерацией говоришь что будет готово - вы это подписываете и ты делаешь.
если что то еще то следующая

те ты пишешь тз, то как ты понял что нужно

(48)"итерацию"

ещё "спринт" скажи)

(0) обычно в таких случаях дописываю к ТЗ следующую фразу - "Реализация явно не оговоренных моментов остается на усмотрение разработчика".
Но я фикси, так-что, х.з. как там на вольных хлебах.

(48)согласен.
(52)а если не на фикси то неоговоренных моментов рождается очень много когда заказчик начинает работать с программой. Именно тогда ему становится понятно что еще не хватает этого того и другого.  Как, к примеру  написали mp3 Плеер а потом руководство сказало - а давайте еще пусть он cd и dvd тоже поддерживает да еще и редактирование видео желательно и сжатие различными алгоритмами..

(14) Ух ты, спасибо! Почитал и это именно то, до чего я дошел самостоятельно и использую уже давно на крупных проектах. Теперь знаю, как это называется :)

(0) Старо как мир.

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

>> списки правок делать уже после за отдельную оплату.
Правильный ли это подход или клиент может в ходе разработки проекта подкидывать дополнительных хотелок так чтобы программист это всё делал в рамках той же цены?

Я вообще не очень понимаю как у вас построена работа.
Откуда возникают правки и хотелки до сдачи результата заказчику?

Ведь стандартный алгоритм примерно следующий:
1. Требования
2. ТЗ на основании требований
3. План-график реализации ТЗ.
На этом этапе мы точно определяем бюджет, исходя из ТЗ и сроков, описанных в план-графике.
И эти документы подписывают обе стороны, включая заказчика.
Любые изменения (кроме быть может минимальных поправок и бантиков, не влияющих принципиально на то, что написано в ТЗ) должны вноситься только по согласованию с уточнением сроков и стоимости выполнения.

>> И правильно ли в таком случае перейти на почасовую оплату с фиксированной чтобы избежать снижения себестоимости своей работы?

Нет.
Есть два типа работ.
1. Проектная. Оплата только фиксированная. За результат - конечный или отдельных этапов.
2. Сопровождение, консультация и поддержка. Оплата только почасовая.

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

Но это именно исключения. Обоснованные и логичные. Весь проект на почасовке - это утопия. Заказчик выйдет очень быстро за рамки планируемого бюджета. Сроки будут сорваны или вообде растянуться до бесконечности. Высок риск не достичь конечного результат никогда. Или результат будет неудовлетворительным.

(53) >> ...а потом руководство сказало - а давайте еще пусть он...

Это вообще не проблема.
Это чистой воды доработки, не предусмотренные ТЗ, за отдельную плату.
Всё что не описано явным образом в требованиях и в ТЗ может быт не реализовано вообще или реализовано на усмотрение разработчка в том виде, как он (разработчик) себе это видит.

Можно смело выставлять счет.

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

Любые значительные доработки должны оплачиваться отдельно. После согласования изменений  ТЗ и план-графика.

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

Ну собственно 1 и 2 произошло даже при условии, что Заказчик не оплатил работы Исполнителя.
А если Исполнитель не просто работал бесплатно, но и навредил, то с него еще и компенсацию за причиненный ущерб стрясти могут.

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

Кстати, наличие штрафных санкций в адрес Исполнителя я в текстах договоров видел, причем, именно в договорах на разработку программного обеспечения. Но в отличие от страшилки в (43) никто никого убивать не стал, а подписали акт об отказе от взаимных претензий.