Будучи в роли разработчика, как вы поступите если к вам поступит ТЗ в котором нужно реализовать 2+2=5.
Т.е. есть ошибка в логике или какая то другая, которую вы видите. ТЗ, например, пришло от аналитика или от другого сотра.

Работа на внутреннего заказчика, не франч.

Было однажды такое. Уточнил у аналитика, писавшего ТЗ, тот говорит: делаем так, как в ТЗ. Я, путём долгих танцев с бубном реализовал. Потом обсуждали другую задачу с руководителем проекта, ну я и про ту задачу спросил: тут дествительно так? РП глянул, сделал округленные глаза и сказал: "Конечно нет, переделываем как надо". При этом РП не только сам это ТЗ согласовывал аналитику, так ещё и с заказчиком его в таком виде согласовал.

(78) Ну и что в итоге получилось?

(79) Работало и так, и так, критично го там ничего не было. Пришлось обходить типовое поведение системы.

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

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

(81) // непонятно, зачем
Эксперты по рисованию прямых углов с котятами?

(81) В 95% случаев ТЗ - это "хочу большую кнопку и чтобы считала правильно". Я для финотдела делал отчет с "особой математикой". Их нормальный средневзвешенный расчет среднего не устраивал, изобрели свой супер-пупер велосипед.

В практике встречается мнение, что ТЗ - это точка зрения и их может быть много.

(81)  "Задания не обсуждают, а выполняют. Или отказываются выполнять"
Эдакий черно-белый мир, с блэк-джеком и бизнес-аналитиками 1С

(80) "с РП - не потратил бы 2-3.."
- ты представляешь сколько лишнего времени РП тратить чтобы хоть что-то понять из ситуации и объяснения Заказчика.

(85) ты просто нирваны еще не достиг, мой падаван...
давно известно "каждый 1сник-автоматизатор - в душе гестаповец"
.
мой мелкий опыт показывает что только таким вариантом достигается хоть сколь-нить значимый положительный результат.

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

(88) ты прав, но я бы еще и цену заломил эдак раза в 3.

А в чем собственно проблема
Пишешь письмо заказчику ТЗ. что ТЗ просмотрено и есть нюансы, типо тут заведомо не правильная логика или какая-то ошибка. В мягкой форме конечно.
Автор ТЗ или кто там. тебе отвечает либо спасибо сейчас изменим, либо нет нужно именно так.
на основании его ответа, ты либо делаешь как тебе ответили. либо если ты принципиальный и считаешь что так делать не правильно и не будешь делать, то не делаешь. И все.
Какие тут еще могут быть варианты ?

Нет ну есть вариант. без вопросов, сразу сделать так как написано в ТЗ. а если это реально ошибка их ну все же бывает. Они потом будут просить переделать, оно тебе надо ?)

(90) на практике может быть что нормального ТЗ ты не получишь никогда
и даже если уволишься и устроишься на другое место, то там будет тоже самое

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

Если тебя бухгалтер попросил в реализации. сделать 2+2=4.5. И ты говоришь ну это же не верно, сумма не правильная. а она тебе говорит а мне пофигу мы так работаем делай. то почему не сделать то, если ее налоговая потом прижмет, то ты то тут не причем. ты в письме сказал что это ошибка, она тебе ответила что делай с ошибкой.

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

Тут главное не остаться крайнем. а что бы этого не было. нужно в письменном виде предупредить об логической ошибки.. что бы тебе потом не сказали.. ну ты что дурак. ну логично же что в ТЗ ошибка 2+2 = 4. ну опечатался человек написал 5.

(92) у тебя рассуждения которые приведены в моем вопросе)
а свою позицию ты так и не написал

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

в смысле типовые от 1с?
ну так а чем мы все по-твоему занимаемся...

(91) поэтому либо себя уважаем и получаем как "менеджер по нормализации учета" или не уважаеми получаем как падаван=-ассенизатор ;-)

(99) правильно я понимаю, что ты не будешь обсуждать косяки ТЗ а просто откажешься от него, потому что ты себя уважаешь?

(95) Формально предупреждения мало. Нужно согласовать и внести изменение в ТЗ. А пока этого нет или под честное слова заказчика делать не по ТЗ, что череповато. Или тормозить процесс, если нет параллельных процессов, что также череповато по срокам реализации.

(100) Косяки в ТЗ обсуждаются на этапе согласования этого самого ТЗ. Особенно важно это для исполнителя, ему же "отжиматься" потом, если что не так в ТЗ. Вдруг заказчик туда неисполнимое заложил. Или кто-то принимает в работу ТЗ не читая?
А по сему нужно определиться на каком этапе жизни самого ТЗ вылезло 2=2+5. Если на этапе согласования и утверждения ТЗ, то ничего страшного. Не принимаем в работу и согласовываем требования или отказываемся от работы. А если ТЗ уже утверждено и согласовано, опять же "два путя". Если, в принципе, реализуемо, можно делать как в ТЗ. А можно составить и направить бумагу заказчику с запросом подтверждения и/или разъяснения конкретного требования ТЗ, но и тут "два путя". Работу можно остановить, а можно не останавливать ми т. д.

Вот на все эти дела и нужен рук. проекта и единое ответственное лицо обладающеее властью по отношению к участникам проекта, как со стороны подрядчика, так и со стороны заказчика.

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

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

(103) Мы так и работаем. Планирование и согласование часто длится дольше и стоит дороже, чем само исполнение проекта. Но для этого нужны не просто стальные, я бы сказал легированные тестикулы.

(105) такое можно только в газпрёмах, где покупатель никуда не денется, и сожрет любое говно по любой цене.....
однажды на одном "заводе-флагмане советской индустрии", в постсоветские и совсем рыночные времена планировали и согласовывали совещание по вопросу целесоообразности выпуска одной незатейливой продукции - моек "двухкамерных". писк моды 2000 года. у завода было все для выпуска - и нержа, и прессы, и инструментальный цех для пресс-форм, и оборудование для электрополировки, и цех РТИ... ну вот, к моменту, когда совещание должно уже было состояться - в город привезли эти мойки из польши. поляки прочухали тему, освоили выпуск, челноки прочухали и освоили доставку, а местные стройбазары наладили сбыт... а на заводе только решили начать совещание...

(106) И кому интересны эти коробейники... Вон у нас в городе движки для москвичей делали на одном из заводов. Так это как раз нечто навроде ваших моек.

(107) Москвич в смысле говноповозка, выпускавшаяся на АЗЛК и В Ижевске

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

Уточню, действительно ли я правильно понял что должно быть так как написано (у меня подобное было с налоговым учетом в УПП) если получаю подтверждение то делаю. Это не моя зона компетенции решать как оно должно быть с точки зрения закона. Опять же я могу не знать общей картины задумки руководства.

(109) Строго говоря, между формулировкой темы "неверные решения" и вариантами совалки "есть ошибка" и "пока 2+2 не будет 4" есть нестыковка. То есть кто-то со стороны не участвовавший в составлении, согласовании и утверждении ТЗ решил что решение неверно. А наглость уточнять требования до исправления "неверного" решения  вообще поражает. Заказчик при нарушении сроков вполне может применить штрафные санкции (если есть в договоре неотъемлемой частью которого и должно быть ТЗ).

(110) Речь идет о формулировке "заведомо неверные решения", то есть исполнитель точно знает, что решение неверное, и у него есть компетенция это понять.

(107) ну вот получилось так, что завод стал "мало кому интересен". а могли бы хотя бы ширпотреб выпускать...
(108) москвич - вполне неплохая машинка. а УЗАМ - вполне нормальный двигатель. если учесть все семейство, которое полностью ниасилили

(112) понять, что решение неверное с определеной точки зрения- не означает знать все причины, по которым оно принято.

я не буду, по другому не умею и переучиваться не буду, потому что работа должна приносить результат и работать на реальном предприятии, а не остаться на бумаге. Но тех кто делает по ТЗ или "как в типовой" даже если это натягивание совы на глобус, я не осуждаю. Хотя такая позиция может стоить очень дорого, вплоть до ухода на другой проект.

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

вот вылезла у меня тут багуля 13 летней давности..
тоже типа 2+2=4
но вот внезапно выяснилось что есть случаи когда оно дает неверный результат.
просто изменились процессы, данные приняли значения которые никогда не принимали прежде и поехало)

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

ТС - ты правда странный, из пунктов голосовалки выходит, что тебя волнуют 3 вопроса:
1. Нужно ли сообщать, если нашел "ошибку" (или у тебя другой взгляд на задачу) или тупо делать по ТЗ
2. Настаивать и убеждать заказчика в своем видении
3. Делать ли задачу, если ты "с чем то не согласен" после всех обсуждений

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

Вроде это очевидно, не?

(0) если ошибка действительно в математике или логике то вменяемый постановщик её обязательно исправит и даже вопросов не возникнет
так что я думаю ситуация немного другая

выкладывай сюда конкретно что там за "2+2=5"
я уверен что ты просто смотришь со своей узкой точки зрения и многих вещей или не знаешь или не учитываешь

(105) это замечательно, что вы так работаете, но вопрос у меня не как перестроить процесс, а вполне конкретный другой.

(109) ещё один из идеального мира розовых пони

(121)Так задай конкретный вопрос, а не по принципу "у одного моего друга..."
(122)Ещё один автоматизатор ларьков столкнулся с необходимостью вычитывать ТЗ до начала работ.

(123) спасибо за внимание к теме

(120) пример я приводил в (47)
не понятно откуда у тебя эта уверенность, с учетом того что вопрос теоритический

(121) >>  вопрос у меня не как перестроить процесс, а вполне конкретный другой.

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

>> пример я приводил в (47).

А что не так с регистром, который не будет закрываться в ноль?
Объясняем заказчику в чём проблема (желательно письменно). При необходимости обсуждаем. Реализовываем в соответствии с согласованным решением.
Само согласованное решение может быть самым разным. В том числе и "оставить регистр, как есть - не закрываемым".
Если заказчик разговаривать не хочет и требует делать "как написано" - делаем.  В чём проблема? Мы его предупредили, а значит ответственность с себя сняли.

Вообще в (119) лучше всего всё расписано. Особо и добавить нечего.

(125) "пример: нужно сделать регистр остатков, чтобы отслеживать закрытие заказов
прог видит в тз что регистр не будет закрываться в ноль"

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

в любом случае, это не 2+2=5
это решение у которого есть свои достоинства и свои недостатки

(126) не знаю, многие конкретные ответы мне понравились, особенно с примерами
мне здесь интересна внутренняя позиция специалиста, как человек поступит когда столкнется

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

(125) В примере из (47) вообще заказчик может не знать что такое регистр остатков, и почему он должен закрываться. Это по большому счету проблема автоматизатора. А вот если со временем отчет не будет формироваться в согласованные сроки, и гарантия не закончится, то вполне возможно что придётся переделывать за свой счет.

>> я повторю мой ответ на это: имею ввиду ошибку, когда заказчик не получит требуемого результата
А я повторю вопрос, как можно взять в работу невыполнимое ТЗ или ТЗ, которое не приведёт к результату (по сути это не ТЗ тогда а филькина грамота)? И логично сделать вывод, что если ТЗ взяли в работу, то значит оно выполнимо и  приводит к результату.

(131) ну в идеальном мире все вопросы решаются заранее, а не по факту их нахождения

(129) я тоже повторю свой ответ. Нет у тебя никакого 2+2=5 где математическая ошибка очевидна
есть решение которое было принято с учётом многих факторов, но конкретно ты считаешь его ошибочным

(129) >> имею ввиду ошибку, когда заказчик не получит требуемого результата.

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

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

(132) в идеальном мире вопросов просто не возникает. там все идеально...

(133) Плюсану

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

(0) Всегда 5 было откуда 4? Автор, дурак, думает, что 2+2=4!

4!=1*2*3*4 примерно 24 выходит. Ясно что и вариант ТС никуда не годный

Давным-давно один клиент переходил с аксесса на торговлю 10. Я сделал презентацию, мне сказали: нам это не подходит, надо, чтобы было как в аксессе. Я говорю - работы тут много, время, деньги, ценность результата сомнительна, вы уверены? Мне в ответ - что споришь, тебе сказали делать? Делай.
Стал ваять формочки, мимикрируя под аксесс. Вырисовывал долго, денег заплатили. Заказчика постоянно что-то менял а проекте, просил переделывать. Полтора года поработали, сказали - фигня какая-то, и стали работать в родных формах УТ 10.

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

(141) хм. Я иногда и ТЗ вставляю. Особенно когда ТЗ несколько нелогично или "специфично".

(141) вот за что я ценю мисту, что есть зёрна таки

(143) Поделись откровением, которые ты увидел в (141)
Оставлять комментарий в коде? Без сарказма, какое тут зерно ты увидел?

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

ИМХО, (141) - описывает 80% работы нынешних 1сников, большая часть из которых никогда не скажет

"работы тут много, время, деньги, ценность результата сомнительна, вы уверены?"

а остальные скажут, но в итоге все равно сделают.

(146) можно ли их за это винить?

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

(148) Ага, (141) скажи об этом

(148) она не совсем бессмысленная была. Просто был более лучший вариант

Когда просят какой нибудь отчет, который позарез нужен. А по факту он нужен 1 раз.
Такая же относительно бессмысленная работа.
Конечно гораздо приятней видеть как твоей работой пользуются постоянно

По факту (141) можно назвать А/Б тестирование. Потестировали формы как в аксесе и поняли что типовые удобнее

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

(151) Смысл (146) в том, что компетенция подавляющего большинства заказчиков часто на очень слабом уровне в предметной области, а исполнители не мотивированы обсуждать (а тем более настаивать) лучшие варианты.
Они делают как проще, часов побольше, чтобы работа была "видна". Можно настроить типовой механизм и обучить пользователей, а можно написать обработочку. Только в первом варианте придется еще этот механизм сначала самому разобрать, да и часов может выйти намного меньше.

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

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

(156) слишком сложный механизм и не очень понятный как он цифры рссчитывает

(155) Смешно, на ИТС разжевано для дебилов

(157) Тебе просто лень

(157) Да и тут нет каких претензий, я тут плохого ничего не вижу

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

(161) я в домике

(157) Просто когда тут (148) пишет, "Выполнять бессмысленную работу не хочется никому, даже если её оплачивают", становится реально смешно:
Ведь при работающем отличном типовом механизме, кто-то сидит и тратит свое время на свой велосипед в виде очередного арма, еще цветами разными там чета выделяет, кнопочки красивыми делает.

(162) да!
Если результат будет неверным, то виноват будет аналитик/автор ТЗ
А если ты будешь спорить и сделаешь по-своему, то при неверном результате виноватым будешь ты.

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

(158) да ничего там не разжевано. там "краткое введение в стандартные ситуации".

(163) + Да, и если че, я тоже, естественно, так делал, а ща не делаю, только потому сменилась сфера деятельности =)))

(165) Соболезную

На самом деле вся эта сложившаяся ситуация печальна только для заказчиков, у 1сников все збс, но это их плата недостаточную компетентность, поэтому все справедливо, я щетаю

(168) На самом деле вся эта сложившаяся ситуация печальна только для 1сников, у заказчиков все збс, они знают что хотят и получают это за вменяемые деньги

(169) Ну аргументируй свой высер петросян, чем печальная ситуация для 1сников

(169) Они получают то, чем потом не пользуются, збс

(170) ну зачем теперь что-то объяснять, сразу не было видно что ты е*анько

(144) зерно такое, что человек ответил на вопрос в топике, а не размышлял как перестроить процессы

(173) + потому что даже при хорошем тз, что то вспылывет при разработке, и дальше уже решение принимает разраб - говорить что у него есть сомнения или не говорить
если сделает криво но по тз, то его вины большой, возможно, не будет, если это вопрос был методический, а не технический

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

(159) если бы люди пробовали и им не зашло. Я бы не отказался писать альтернативу

(172) ебанько твой отец, потому что контрацептивами не пользовался