Предложенный вариант описывает расчет себестоимости слишком упрощенно. Я же не случайно каждый раз уточняю, что речь идет о многопередельном производстве.
Смотрите: Есть номенклатурна, для которой требуется рассчитать себестоимость. Существует процедура costCalculation, куда мы передаем эту номенклатуру в качестве параметра.
Она (номенклатура) может быть либо покупной, либо изделием. С покупной всё достаточно прозрачно: берем цену закупки и на этом останавливаемся. Если же у нас изделие, мы лезем в его состав считаем себестоимость входящих компонентов. И себестоимость компонент считаем той же costCalculation. Что в такой логике, можно декомпозировать?
Однако это еще не полная себестоимость. На каждом этапе, а они у нас имеют вид дерева, для каждого изделия необходимо учесть множество дополнительных факторов:
попутный выпуск, когда в рамках одного передела получаются изделия для разных проектов;
брак и возвратные отходы, причем на разных итерациях одного и того же производства они могут различаться;
расходные материалы, которые не входят напрямую в состав изделия, но тратятся в процессе его изготовления;
и прочие подобные нюансы — список может быть весьма широким.
И на первый взгляд кажется, что все это можно выделить и считать отдельно… но на практике это не работает. Формально, конечно, можно вынести разные части кода в отдельные процедуры. Однако значимый, осмысленный результат можно будет получить только в контексте всего сквозного расчета.
В случае многопередельного производства показатели по одной операции могут зависеть от предыдущих, что тоже надо учитывать.
Контекст (заказ, партия, период, цех и даже конкретный станок) напрямую влияет на себестоимость одной и той же номенклатуры. Даже идентичная продукция может иметь отличающуюся себестоимость. А в случае, когда производство не серийное, все расчеты становятся еще веселее. Потому, что даже приблизительно оценить дополнительные факторы невозможно.
То же самое касается и ФОТ: он распределяется по фактически выполненным операциям в привязке к конкретному производству. Ну а общепроизводственные затраты, в данном случае, можно не распределять, считаем что у нас директ-костинг.
И вот как вы подобную задачу хотите декомпозировать и отдать на откуп ИИ? А, самое главное, как вы будете проверять корректность полученных декомпозиций?
Я даю доступ к файлам проекта в режиме агент. Прошу исправить что-то в одном файле. Небольшое локальное исправление. Агент начинает пыхтеть, читать файлы, говорит что все сделано... и я вижу что изменения внесены даже в те файлы которые не надо было править.
Полез смотреть код, он мне его так отрефакторил что во-первых, он не работает, во-вторых, даже если бы работал дела бы не то, что нужно.
На этот моменте, режим агента мне как-то разонравился. Вернулся в чат. Там я хотя бы заранее понимаю, что поменялось в коде.
Ну так расскажите, как вы будете декомпозировать и проверять промежуточные значение получаемые при расчете себестоимости многопередельного производства? Что с чем сравнивать? Что выделять?
Вот более простой и наглядный пример: расскажите как вы декомпозируете вычисления чисел Фибоначчи и как будете проверять промежуточный результат.
Да, у Фибоначчи формула попроще, но принцип тот же самый.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Человек не может отрастить сначала левую ногу, потом правую, потом руку… только все одновременно.
За ИИ взялись реальные люди, а не евангелисты. Они пишут реальные истории с реальными проблемами. И читать это полезнее и интереснее, чем маркетинговую хрень.
Разумно. Я обычно скармливают в режиме чата отдельные функции или небольшой кусок кода, что бы контролировать изменения.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю. Даже на небольшом проекте, в режиме агента, изменения получались фатальные.
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах. Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Ну во-первых, я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Во-вторых, бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет. И в большинстве своем бизнес предпочтет стабильные проверенные решения, а не маркетинговый муссор.
В-третьих, нельзя уволить человека одним днем. Это и по закону возможно в крайне ограниченных случаях, и по процессу занимает банально больше времени. Рассчитать человека, проверить задолженность перед организацией, сдать или перевести на себя корпоративную симку, вернуть корпоративный ноутбук, передать дела, произвести все выплаты, оформить документы…
Ахренеть логика. Берем вполне себе устоявшийся общеупотребительный термин «задача» и подменяем его жаргонизмом из agile.
А почему не из математики? Или из DnD? Подобная подмена понятий настолько же правомерна. Терминология Agile не является ни общепризнанной, ни единственно возможной. Это просто сленг, который вне agile - ничего не значит.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
Стратегическая цель бизнеса заработать больше денег. Занять большую долю рынка. Вытеснить конкурентов.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Но вы же могли просто написать: проблема в реализации ERP решения одним запросом в sql, а не строить абракадабру. Но тогда бы оказалось, что в самой проблеме и кроется решение.
Нет, про SQL был пример в другой ветке и про другую задачу.
Но ведь я не писал что правила должны быть прописаны в одном месте.
Ну мы возвращаемся к тому, что вы пытаетесь декомпозировать то, что в принципе не декомпозируется в силу сильной взаимосвязанности.
Только сдавал штук 5 экзаменов по этой теме, но сам не ногой, все уже порешено до нас.
Вот почему-то я был в этом уверен. Я сейчас читаю примечательную книжку "Программирование и конфликты" от Роберта Гласс. Очень перекликается с нашей беседой.
C точки зрения разработчика ПО эта фраза не имеет смысла, но все пробелы я вам не заполню.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
Не надо изобретать терминологию. Она уже давно устоялась. И ни в одном определении Задачи нет привязки к трудоемкости.
Для меня задача, это та задача которую ставит бизнес. Подозреваю, что для кого-то "реализовать журналируемую файловую систему с нуля" тоже может быть задачей.
Далеко не все задачи подлежат декомпозиции. Нельзя декомпозировать слишком сложные или хаотичные задачи, где условия постоянно меняются, а связи между частями неочевидны и запутаны. Декомпозиция требует стабильности, а в таких задачах её нет. А это, буквально, большинство учетных задач.
Понятно, реальную себестоимость на производстве вы никогда не считали и теоретизируете на пустом место. За сим, продолжать дискуссию не вижу смысла.
Предложенный вариант описывает расчет себестоимости слишком упрощенно. Я же не случайно каждый раз уточняю, что речь идет о многопередельном производстве.
Смотрите: Есть номенклатурна, для которой требуется рассчитать себестоимость. Существует процедура costCalculation, куда мы передаем эту номенклатуру в качестве параметра.
Она (номенклатура) может быть либо покупной, либо изделием. С покупной всё достаточно прозрачно: берем цену закупки и на этом останавливаемся. Если же у нас изделие, мы лезем в его состав считаем себестоимость входящих компонентов. И себестоимость компонент считаем той же costCalculation. Что в такой логике, можно декомпозировать?
Однако это еще не полная себестоимость. На каждом этапе, а они у нас имеют вид дерева, для каждого изделия необходимо учесть множество дополнительных факторов:
попутный выпуск, когда в рамках одного передела получаются изделия для разных проектов;
брак и возвратные отходы, причем на разных итерациях одного и того же производства они могут различаться;
расходные материалы, которые не входят напрямую в состав изделия, но тратятся в процессе его изготовления;
и прочие подобные нюансы — список может быть весьма широким.
И на первый взгляд кажется, что все это можно выделить и считать отдельно… но на практике это не работает. Формально, конечно, можно вынести разные части кода в отдельные процедуры. Однако значимый, осмысленный результат можно будет получить только в контексте всего сквозного расчета.
В случае многопередельного производства показатели по одной операции могут зависеть от предыдущих, что тоже надо учитывать.
Контекст (заказ, партия, период, цех и даже конкретный станок) напрямую влияет на себестоимость одной и той же номенклатуры. Даже идентичная продукция может иметь отличающуюся себестоимость. А в случае, когда производство не серийное, все расчеты становятся еще веселее. Потому, что даже приблизительно оценить дополнительные факторы невозможно.
То же самое касается и ФОТ: он распределяется по фактически выполненным операциям в привязке к конкретному производству. Ну а общепроизводственные затраты, в данном случае, можно не распределять, считаем что у нас директ-костинг.
И вот как вы подобную задачу хотите декомпозировать и отдать на откуп ИИ? А, самое главное, как вы будете проверять корректность полученных декомпозиций?
У меня какая история была:
Я даю доступ к файлам проекта в режиме агент. Прошу исправить что-то в одном файле. Небольшое локальное исправление. Агент начинает пыхтеть, читать файлы, говорит что все сделано... и я вижу что изменения внесены даже в те файлы которые не надо было править.
Полез смотреть код, он мне его так отрефакторил что во-первых, он не работает, во-вторых, даже если бы работал дела бы не то, что нужно.
На этот моменте, режим агента мне как-то разонравился. Вернулся в чат. Там я хотя бы заранее понимаю, что поменялось в коде.
О! Вот это уже интересно.
Судя по вашему комментарию, все обсуждение выше вы не читали. Тогда с какой целью взялись комментировать?
Ну так расскажите, как вы будете декомпозировать и проверять промежуточные значение получаемые при расчете себестоимости многопередельного производства? Что с чем сравнивать? Что выделять?
Вот более простой и наглядный пример: расскажите как вы декомпозируете вычисления чисел Фибоначчи и как будете проверять промежуточный результат.
Да, у Фибоначчи формула попроще, но принцип тот же самый.
А как он в сеньеры выбился?
Что до дизайнеров, мне кажется, хорошие работы дизайнера стали только больше цениться, на волне ИИ слопа которым наполнился интернет.
Расскажите мне, как декомпозировать расчет себестоимости с учетом того, что любой промежуточный результат расчета себестоимости не имеет никакого смысла и не проверяем в принципе.
Человек не может отрастить сначала левую ногу, потом правую, потом руку… только все одновременно.
Тут та же ситуация.
Это не решает проблему нежелательного изменения кода. Это помогает аннулировать нежелательные изменения.
Разделение осознанное и оправданное.
Основные процессы хорошо отлажены и внедрены. Трогать их - себе дороже.
А как интерпретировать полученные результаты, это совсем другая история.
За ИИ взялись реальные люди, а не евангелисты. Они пишут реальные истории с реальными проблемами. И читать это полезнее и интереснее, чем маркетинговую хрень.
Разумно. Я обычно скармливают в режиме чата отдельные функции или небольшой кусок кода, что бы контролировать изменения.
А вот как обезопасить себя от нежелательного изменения кода в режима агента - не представляю. Даже на небольшом проекте, в режиме агента, изменения получались фатальные.
Смешной вы человек, право слово. Вы ничего не знаете обо мне, моих навыках, моих задачах. Вы ничего не знаете как работает бизнес. Вы ничего не знаете о приеме/увольнении. А пытаетесь выдавать какие-то суждения.
Ну во-первых, я именно тот человек к которому общаются когда хотят продать технологию или ПО в мою организацию. И если меня не убедят, что технология стоящая, бизнес даже разговаривать не станет с продажниками.
Во-вторых, бизнесу плевать на абстрактную эффективность. Ему нужна конкретика: как это снизит затраты, увеличит доходы или какие риски снимет. И в большинстве своем бизнес предпочтет стабильные проверенные решения, а не маркетинговый муссор.
В-третьих, нельзя уволить человека одним днем. Это и по закону возможно в крайне ограниченных случаях, и по процессу занимает банально больше времени. Рассчитать человека, проверить задолженность перед организацией, сдать или перевести на себя корпоративную симку, вернуть корпоративный ноутбук, передать дела, произвести все выплаты, оформить документы…
Ахренеть логика. Берем вполне себе устоявшийся общеупотребительный термин «задача» и подменяем его жаргонизмом из agile.
А почему не из математики? Или из DnD? Подобная подмена понятий настолько же правомерна. Терминология Agile не является ни общепризнанной, ни единственно возможной. Это просто сленг, который вне agile - ничего не значит.
Впрочем, в остальном ваши суждения столь же спорны и поверхностны.
Стратегическая цель бизнеса заработать больше денег. Занять большую долю рынка. Вытеснить конкурентов.
Один из способов решения этих задач (user story в терминах agile, раз уж иначе вы не понимаете) это контроль доходов и расходов.
А вот необходимый инструмент для контроля расходов и та самая task из agile, это как раз расчет себестоимости производства.
И хоть ты лопни, но разбить расчет себестоимости на более мелкие, но самоценные, блоки невозможно.
Ох уж эти теоретики. Все, заканчиваю спорить о вкусе устриц с теми кто их не ел.
У меня нет необходимости обсуждать решение моих задач. Я их решаю сам и довольно успешно. И не в теории, а на практике.
Все что было нужно мне - пример решения сложной задачи с помощью ИИ. Свои задачи я привел для примера сложности, а не обсуждения как их решать.
Нейроскептиком я не являюсь. Я просто очень хорошо представляю как работает эта технология и какие у нее ограничения.
Если человек успешно решал сложные задачи с помощью ИИ, он бы вполне мог бы это описать. Даже не углубляясь в детали. Общие нюансы, проблемы, ограничения, сильные стороны.
Собственно я схожий вопрос задаю на собеседовании программистам. Расскажите о своем сложном проекте и о том как вы его решали. И программисты рассказывают. А евангелисты ИИ не могут.
Бизнес логику от логики агрегации не отличаем?
Нет, про SQL был пример в другой ветке и про другую задачу.
Ну мы возвращаемся к тому, что вы пытаетесь декомпозировать то, что в принципе не декомпозируется в силу сильной взаимосвязанности.
Вот почему-то я был в этом уверен. Я сейчас читаю примечательную книжку "Программирование и конфликты" от Роберта Гласс. Очень перекликается с нашей беседой.
В силу отсутствия у вас практического опыта, это будет бессмысленный разговор. Но если вы хорошо учились, то термины неделимость состояния, отсутствие чётких интерфейсов и нелокальный эффект изменений - подскажут вам, почему не все задачи можно декомпозировать.
Не надо изобретать терминологию. Она уже давно устоялась. И ни в одном определении Задачи нет привязки к трудоемкости.
Для меня задача, это та задача которую ставит бизнес. Подозреваю, что для кого-то "реализовать журналируемую файловую систему с нуля" тоже может быть задачей.
Далеко не все задачи подлежат декомпозиции. Нельзя декомпозировать слишком сложные или хаотичные задачи, где условия постоянно меняются, а связи между частями неочевидны и запутаны. Декомпозиция требует стабильности, а в таких задачах её нет. А это, буквально, большинство учетных задач.
А почему вы думаете, что я этого не делал? Делал. И результат меня не удовлетворил.
Я за свою карьеру написал и прочитал множество технических проектов, заданий и просто фантазий пользователей.
Так вот, то что предлагает ИИ - это вода. Без конкретики. Без пользы.