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

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

Напишу письмо, где в мягкой форме (а вдруг я ошибся?) укажу на возможное несоответствие. И буду делать.

Уточнять и разъяснять нужно всегда. Ведь может оказаться, что это ты не заметил, что там 2 + 3.

Если есть система учета задач и ТЗ там зарегистрировано, то надо делать как в ТЗ.
Спрашивают с того кто задачу ставил. Тот кто делал передает готовую задачу постановщику.

А что у 1Сникоа кто-то ТЗ пишет?

(0) А ТЗ согласовано? А наша служба участвовала в согласовании? А почему меня не спросили?

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

(4) пишут

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

(8) То есть ошиблись все и методисты и аналитики и исполнители, которые тоже ТЗ согласовывали и, следовательно, пролюбили ошибку. Если ошибка ставит под угрозу проект и риск неудачи велик, может стоит вернуться на этап формирования и согласования ТЗ? Если ошибка мелочная, то уточняется и согласовывается ищменение (отклонение) от ТЗ. Ошибка в ТЗ одна из самых дорогостоящих.

Должен быть регламент. Даже если он негласный, то все равно он должен быть -

"как поступать, если обнаружена ошибка в решении?"

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

1С целые релизы платформы фигачат с ошибками и чего теперь с этим делать?

(10) >какой смысл его дальше делать после выявленной ошибки?!
Смысл в зарплате ))

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

(10) По сабжу ошибка не в решении, а в ТЗ. И выбор или согласовывать новый вариант ТЗ без ошибки, или по 1Совски — хуякс-хуяки и в продакшен

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

(13) ну это глобально, вопрос не про ТЗ даже, а кому откатили

(7) Ни разу не видел. Не свезло видать.

(12) А откуда будет зарплата, когда Заказчик не получит желаемого из-за того, что кто-то утаил ошибку и все изгадил?! И выяснится это уже в самом конце.

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

(17) Не дай бог тебе увидеть. Когда на согласование приходит ЧТЗ на плёвую доработку в несколько сотен листов. И сроки согласования всего в месяц, ностальгируешь по "горячим внедрениям" без ТЗ только с неясной целью

Если задача приходит как консу, то беру с уточнением, если как методологу, то спорю до последнего

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

И тут такое вылезет наружу и все друг-другу скажут : почему наши супер-пупер-дупер специалисты эксперты по технологическим вопросам промухали ошибку в ТЗ, ась?!!!

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

Интересно. А какая разница? В чём особенность франча?
ИМХО, никакой разницы нет.
Если методист/консультант - автор ТЗ дурак, то говорить об этом руководителю проекта не нужно? Странный подход.

Смотря что так считать, если собственную почасовую работу как 2+2=5 то сделаю, почему бы и нет.
А вот если наоборот 2+2=3 - буду уточнять, пока не станет 2+2=5 ;)

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

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

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

(0) Сделаю предупреждение о возможных последствиях.
Приступлю к неспешному выполнению.

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

Голосовалка, как это часто бывает на мисте, дебильная.
Не имеет никакого отношения к реальной жизни.

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

Иными словами в жизни два последних пункта могут применяться одновременно. В зависимости от конкретных обстоятельств. Иногда не зависящих ни от заказчика ни от разработчика. Например, когда срочно надо закрыть вопрос хоть как-то, а разбираться будем потом (часто в жизни "потом" не наступает никогда).

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

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

ТЗ -> кодер.
нехрен кодеру в логике разбираться. откуда кодер знает какая логика у тех кто внедряет. Кодер максимум - указывает на явные нестыковки технического плана типа 2+2 = 5. mF если в ТЗ написано, что напечатать надо документ с 10 рублями, а долг по документу положить 10+2 - не кодер адело почему так.
.
все логические ошибки отлавливаются уровнем выше - на техническом проекте, ТП = что надо сделать (логика, функциональность итд)), а КАК делать (ТЗ) - это внутренний документ разработчиков.
.
или вы сначала разберитесь
ТП-ТЗ-кодер
или
ТЗ-ТП-кодер
.
по моему разумению - ТЗ = задание, вот тебе лопата и копай. То что нужно копать не экскаватором, а не лопатой, и не прямо а под углом - это уровнем выше Решается. в ТП.

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

если пошел программистом - делай как в ТЗ, иначе иди аналитиком

(23) "В чём особенность франча?"
в (24) еще ответ, в первой строке

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

(11) всегда сначала задаю вопрос, после получения ответа делаю или нет по результатам ответа. это может тебе кажется что 2+2=5. а на самом деле совсем не 5. а может тут оператор "+" по другому устроен

(24) "Дурным идеям сопротивляться стоит, вплоть до увольнения, если есть куда податься."
да если есть куда податься, то наверное так и стоит работу работать, а не просиживать до 18:00

+(24) Я все это уже проходил и не раз.
Я отказывался и объяснял почему так делать нельзя, а напарник делал как в ТЗ.
В результате почти ВСЕ отчеты потом показывали кривые данные, а что бы их исправить, пришлось их изувечить в соответствии с последствиями ТЗ.
Стали раз в 5 медленнее, но что хотели то и получили...

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

(26) "сказала что совсем не это имела виду"
а сослаться не было возможности на требования?

*

(37) ну только отличие может быть в том что на фикси прог гарантированно получит свой оклад, а во франче кусочек от пирога

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

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

(18) Если все реализовано строго по ТЗ то хрен выйдет зажать зарплату

(0) Нет правильного ответа

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

А можно примеры?
А то бывает что прог думает, что он лучше всех, а по факту это далеко не так

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

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

(47) Он должен сделать так чтобы закрывался в ноль, это само собой разумеется. Или ТЗ должно быть до уровня вода мокрая, как пособие для идиота.

(0) Нет.

(47) как бы заказы обычно всегда в регистрах остатков висят. Пока 1:0 не в твою пользу

(50) удачи тебе с такими системами, где всегда остатки "висят"

(50) Это ошибка, 1:2 в мою пользу.

Если фикси не буду (с уведомлением).Если франч буду,потом буду переделывать за отдельную плату

Остатки вполне допустимы, если они имеют прикладной смысл. На 01 счете тоже всегда остатки висят.

(54) Это бух. учет, там и не такое висит)

ребята, с регистром я привел пример где тз не соответствует ожиданияем, и только
а что там у кого еще висит это тема очень интересная, тут вопросов нет)

Кодеры по тз на то и кодеры по тз, чтобы работать по тз без вопросов)

(57) Бывает такие ТЗ прилетают, что поневоле станешь архитектором :)

(54) Концептуально, в бухучете все балансовые счета - один регистр. И остатки по этому регистру недопустимы.

TLDR

Было дело, работал я на заводе. Как-то собрались мы на совещании у директора по ИТ. Выступает начальник ОТЗ - большой человек, зарплатой рулит как-никак. Говорит, что хочет, чтобы мы сделали программу, в которой будет рассчитываться зарплата конструкторов заводских. Нехай, дескать они сами каждый себе проставляют, по сколько часов каждый день над какими проектами работали. ТЗ выкладывает. Хорошее ТЗ, толковое.

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

Не ну мы придумали, чего там сложного-то. Формочка одна, где главнюк раскидывает задачки на подчиненных, да отмечает выполненные. Да формочка другая, где сам конструктор отмечает каждый день чего он там творил по сколько часов. С любовью к делу подошли, сделали чтобы там лишних телодвижений делать не надо было делать. По умолчанию время поровну делится между всеми активными задачами, конструктору остается по факту только ОК нажать, не ну может при желании часы подвигать, но если нет желания, то и не надо.

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

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

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

Уволился я оттуда вскоре после. Вобщем-то последняя капля была для меня. Оно, бабло хорошее платили, но не бабками же одними человек живет. Вот и сказке конец.

(61) сколько времени пилили?

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

(61) это ты Ивана Белокаменцева почитай, там еще не таких историй

(63) а, это там где 146% получилось в итоге?

получАлось

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

(63) "проценты складывали с суммами"
на бою складывали?

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

Скорее надо добить ТЗ до уровня чтоб заказчик понял что он ошибается.
Иначе просто отказаться проще. Или начинать делать предупредив о проблемах.

Верну ТЗ на доработку... толку приступать к работе, когда там ошибка :)
...Если отдадут другому программисту, то это уже проблема другого программиста...

(0) нет ни чего хуже, чем разработчик, отклоняющийся от ТЗ

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

Так.

Свою работу в бесполезную превращать не буду.

(74) это ты еще в гугле не работал, где 95% пишется или сразу в стол или через год на свалку уходит

(75) а кто работал?

(61) сейчас это скорее реальность и обоснование затрат времени на проект по часам жесткая необходимость на предприятиях на ближайшее будущее.
не в киосках с шаурмой конечно. )

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

(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) ебанько твой отец, потому что контрацептивами не пользовался