В соседних темах вот пишут - я с такими бестолковыми задачами работать у них не буду. Сами, мол, не понимают, что хотят - а я кодь давай! Давайте мне нормальное ТЗ!


Фишка в том, что вам приходят задачи от бизнес-пользователя. И это обычные нормальные такие задачи, юзер стори и всё такое. И такая "мутная" формулировка - нормальная вполне для первого этапа.

Никакого ТЗ чаще всего от бизнес-пользователя вы не получите.

На втором этапе далее такие задачи далее нужно анализировать и делать четкую формализацию. Это может делать и специально обученный человек со стороны бизнеса, это может делать и 1С-ник, и кто-то третий. И это отдельные трудозатраты! И, да, согласуйте эту формализацию по итогам с автором проблемы )

И вот после этого этапа 1С-ник имеет шанс увидеть вожделенное ТЗ :)

Резюмирую, имхо, я бы уточнял (если вы ищете работу, к примеру) - кто формализует задачу для программиста? Готов ли работодатель оплачивать это время? Понимает ли он вообще, зачем это нужно.

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

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

Всегда надо писать документацию.
И всегда надо писать тз.
Эти документы должны быть на каждую задачу.
Даже из одного параграфа.
Детализация может страдать.
А факт наличия должен быть.

(0) Мне предпочтительнее, когда я сам предлагаю решение и согласовываю его с ЛПР.

Пишу разрабам где-то пол-страницы что как должно быть по архитектуре, какие формы и на что обратить внимание. Это на задачу примерно от 3 до 10 человекодней.

К сожалению пока что так..

(36) "Надо, Федя, надо!" ©