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

Вас повысили до архитектора-аналитика? Поздравляю!

(0) странный вопрос. Раз ты с ними работаешь, значит они точно есть.
В общем случае бывает по-разному. Если ты программист, то тебе конечно проще сделать самому чем писать ТЗ.

(2) Пока не работаю. Обсуждаем форматы сотрудничества. Мне сейчас нужно понять, стало ли это стало нормой в 1С. Если нет, то нафик нужно.

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

(0) к примеру в последней УТ у меня перестали корректно печатать чеки  (сумма в бумажном чеке не совпадает с суммой в 1С).
Соответственно какое ТЗ для программиста ты ожидаешь? Или это не проблема программиста исправить ошибку в коде?

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

(3) Не надо работать с Гггеней и ЛивингСтаром... А вообще, есть даже ГОСТ на ТЗ

С другой стороны зачастую архитетура 1С кривая до нельзя, когда реквизит условный "Контрагент" может иметь пользовательское представление как "Список лохов", и тогда что толку от того что клиент скажет, что мне нужно вывести список лохов, ты его не поймешь. А когда он пальцем тыкнет хочу чтобы вот это была тут, то дело пойдет гораздо быстрее

(3) должен ли программист бесплатно изучать вашу самописку для изучения связей и между объектами и различиями в представлении? Или вы ему будете доплачивать?
К примеру звонит мне сотрудник и говорит "у меня цифры неверные в зеленом отчете". После этого так и хочется сказать "ты не умничай, ты пальцем покажи"

что-то не то у ТС спрашивают

А что за "примитивная печатная форма" - из какой типовой конфигурации она должна работать?

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

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

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

(11) Полностью поддерживаю. Всегда так считал.

на рарус техдень об этом хорошо рассказал Ширин Кирилл, ищи на ютюбе, должны были выложить.

(13) Не всегда так. Например у Вас свой расчет отпуска. Как программист без ТЗ его реализует?

(12) ну да, ну да. И каждый программист ТЗ, должен в уме держать все версии.
Спроси у Мани скjлько раз он свой мегапрайс переписывал для типовой УТ11

Я уже молчу про функциональные опции (ведения договоров, ведения партнеров и т.п.)

(12) А давай все-таки речь ограничим печатками... Какую именно форму, для какого документа из ERP ?

(12) https://habr.com/ru/post/530728

(19) а под этой статьёй много-много всего расписано уже в комментах под ней, а не в самой статье

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

(0) обезъяньей работы быть не должно

Какое поле из какого обычно для сумм нужно.
Ибо неочевидно практически никогда.
Про контрагента или организацию конечно излишне

В той же счёт-фактуре цена без ндс, а в документе с ндс. Как считать?

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

(0) >что поле Контрагент нужно взять из одноименного поля документа

А там не требуется еще описывать что именно подразумевается под словом "взять"? А то один возьмет, и просто возьмет: Область.Параметр.Контрагент.Взять(Док.Контрагент). И скажет что архитектор виноват.

Или даже просто сделает, Область.Параметр.Контрагент = Док.Контрагент; А архитектор подразумевал Область.Параметр.Контрагент = ОбщегоНазначения.ПолучитьРеквизитОбъекта(Док.Контрагент, "Наименование")...

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

в статье на хабр часто встречается:
<<НЛО прилетело и опубликовало эту надпись здесь>>
поясните пожалуйста колхознику, что сие означает?

Это Волшебники хабра, пишут сообщения, чаще всего простым смертным не видны.

(0) Так у вас проблема со знанием конфигурации, если программист не знает конфу, тогда точно нужно, а если знает, то нужно, только то, что нужно сделать без конкретики.

(29) А если вариантов знания в конфе множество? Когда там в ERP реквизит на форму из Партнеры, а при выводе в печатную форму используются данные из Контрагенты, причем, с получением данных запросом сразу по всему документу в виде объекта.

Работал близко к этому некоторое время.
Производительность и кодера, и аналитика сильно возрастает, и общее взаимонимание задач между бизнесом и ИТ увеличивается.
Плюсов больше, чем минусов. Но свои трудности тоже в этом есть.
Бывший коллега тут в ветке отметился.

(0) ага, если есть аналитики и программисты раздельно - это нормально. Для относительно небольших проектов и доработок можно "сэкономить" на аналитике и архитекторе и их роль выполняет либо сам программист либо начальник отдела\лид. А в целом такое разделение повсеместно в программировании, и 1с на крупных проектах (или конвеерных у франчей) - не исключение.

(30) Так спросит. Или по контексту задачи понятно.

(0) Просто, если торговцы просят сделать то, что в этой конфе не сделать. И слово НЕТ не понимают. То тут начинается, как в 5 красных линий. ))

(33) ну я сам себе задачи ставлю - нет у меня ни аналитиков каких-то, ни даже постановщиков задач, которые хотя бы формулировали их даже кратко.

Если это речь о конфе ERP, то без знаний самой конфы нет там никакого понятного контекста.

А если еще при этом к документу прикрутили печатные формы через общую встроенную обработку и сломали тем самым БСП (это в типовом варианте, если что), то проще похерить эту задачку, чем тратить на нее адекватное количество часов на решение.

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

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

Подробное тз не может написать аналитик, а только архитектор

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