Вы уж определитесь о чем рассуждаете. То "выбираете заказчиков", то "сама компания ведет разработку", то это "отдельная бизнес модель".
Я вам про Фому, а вы мне про Ерему...
В ТМ тоже есть сроки. В ТМ тоже есть критерии приемки работ. Просто сроки короче, задачи локальней а бюджет закладывается. Даже бюджет там тоже есть. Просто считается и расходуется иначе.
И в плане управления проектом (развития программного продукта) разницы между ТМ и Фиксом не будет ровно никакой. ТМ и Фикс - это просто условия оплаты, а не методология.
Для внедрения программного продукта, а мы изначально обсуждали именно его, ТМ плохой выбор. Да, в случае когда компания не имеет зрелых бизнес процессов и в принципе не очень понимает что ей надо это будет практически единственный вариант. Но по сути это и есть незрелый заказчик.
Есть еще вариант когда компании просто не хватает собственных исполнителей для реализации всего объема работ в срок. В этом случае, внедрением занимается сам заказчик, а исполнитель просто дополнительные руки. То есть, по сути, тот же самый проект с фиксированными сроками, бюджетом, объемом работ, но с привлечением дополнительных сил. Но это уже не TM, а outstaffing в рамках проекта. Похожее, но все же разное.
А вот для поддержки и дальнейшего развития, ТМ вполне себе подходит. Задачи появляются постепенно и закрываются по необходимости. Но тут и объем работ иной, и стоимость, и срочность не сопоставима с внедрением. И цена ошибки ниже. О чем я собственно уже писал.
То что описано у вас не внедрение. Это что угодно: поддержка, сопровождение или доработка — но не внедрение.
Внедрение — это реализация конкретных процессов на конкретной платформе в заданных временных рамках. Его цель — перевести эти процессы на новую платформу. Внедрение почти всегда разбито на этапы, и первый релиз никогда не бывает финальным. Но у него всегда есть перечень целей и задач, которые должны быть решены, и сроки, в которые они должны быть решены.
Когда внедрение завершено, предприятие получает систему, в которой может полноценно вести свои процессы. Не обязательно все сразу и не обязательно идеально — но поставленные цели и задачи внедрением решены.
Дальше начинается сопровождение продукта: силами заказчика или сторонней организации. На уже работающей системе в рамках сопровождения можно менять процессы, оптимизировать их, добавлять новый функционал. Но это именно сопровождение, и у него другая логика управления: не фиксированный объём работ до результата, а регламент, SLA, приоритеты и поток задач.
И даже в сопровождении заказчик и исполнитель согласовывают стоимость и сроки работ. Просто согласовывают их иначе, чем при внедрении.
Это не опытный заказчик, а заказчик хорошенько обработанный меркетолагами. Ни один адекватный заказчик не будет вливать деньги не имея представления о том когда это кончится и что он получит в результате.
Внедрение программного продукта это вполне себе фиксированный процесс с началом и концом.
Потом, уже работающий продукт, можно дорабатывать. Внедрить новые модули, менять уже внедренные и т.д.
Но даже в этом случае, это будут отдельные проекты с началом и концом.
Ну и да, не стоит путать внедрение с сопровождением и поддержкой. Это очень разные процессы с разными задачами и методами.
Это вы описываете идеального исполнителя. А такие встречаются редко.
Если заказчик сам не разбирается в системе - подход правильный. Он не знает продукт и объясняет на своих процессах, что ему нужно. Исполнитель вникает в процессы заказчика и предлагает грамотное решение.
Однако, мне встречалось другое: исполнитель приносит решение, которое не ложится на процессы заказчика. Всё по методологии вендора, красиво расписано, хорошо задокументировано (и даже идеально реализовано), но на практике это не просто неудобно, а разрушает рабочие процессы.
Либо у исполнителя не было специалиста, который способен это увидеть, либо не было желания вникать в процессы заказчика.
Всё зависит от того, есть ли у сторон нужные компетенции и насколько сильны специалисты.
Если заказчик сам не понимает, что он хочет - вы никогда не сдадите такую систему.
Заказчик должен понимать, что он хочет. Требования могут меняться и дорабатываться при разработке системы.: что-то не предусмотрели, что-то поменялось, для чего-то нашли лучшее решение... Но "то что заказчик хочет" не меняется. Меняться может "то как он это хочет получить".
В противном случае, получится система которая будет соответствовать формальным требования ТЗ, но будет совершенно не рабочая и бесполезная для заказчика.
О! Точно! Последний раз я держал в руках диск с МРТ. Правда, за чем он мне нужен, я так и не понял. Результаты были доступны врачу во внутренней системе поликлиники.
LLM не обладает пониманием инженера — она обладает статистической уверенностью, которая может быть катастрофически ошибочной. Человеческое «ничего не понял, надо уточнить» — это не баг, а важнейший механизм верификации, основанный на реальном понимании предметной области. LLM же с абсолютно одинаковой уверенностью сгенерирует и гениальный краевой кейс, и тест, проверяющий деление на ноль через сакральный смысл числа 42, если это коррелирует с её обучающей выборкой.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели. И то, что написание тестов вы отдадите другому ИИ ровным счетом ничего не меняет.
Утверждение, что агент «возвращает только нужное, безо всяких промежуточных этапов», выдает непонимание природы LLM-агентов в продакшене. Вы называете «мусором» ту самую цепочку рассуждений, которая, является единственным способом для LLM решать сложные задачи с приемлемой точностью. Агент не «шуршит», фильтруя мусор, — он галлюцинирует на каждом промежуточном шаге. Проблема «основного контекста» никуда не исчезает: она просто переносится в контекст агента, где, благодаря многоагентности, ошибки накапливаются, а возможность человека проконтролировать логику стремиться к нулю.
Ну и главное: сравнение с человеком, который «не помнит каждую строчку кодовой базы», некорректно. Человек не помнит код, но он хранит ментальную модель системы. Он знает, почему модуль А не должен вызывать модуль Б напрямую, потому что полгода назад это приводило к гонке состояний. LLM не помнит синтаксис и не строит ментальную модель. Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Проблема не в том, кем написан тест, а в том, что вы делегируете машине верификацию истинности, на которую у машины нет ни права, ни способностей.
А кто-то еще пользуется дисками, кроме консольщиков? Я уже и забыл, когда последний раз в руках держал CD или DVD. Где-то в закромах валяется внешний привод, но ни на одном компе, ноутбуте их давно уже нет.
А вы знаете, это прекрасный вопрос. Для меня он полностью закрывает необходимость дальнейшей дискусси.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый. По этому LLM оперирует энтропией, а не "понятностью".
Юнит тесты для проверки ИИ, которые пишет сам ИИ? Это способ самоуспокоения и к проверке кода имеет весьма касательное отношение. И даже 100% покрытие тестами написанными ИИ не даст гарантии, что код правильный.
Проблема ИИ, не в том, что ИИ ошибается. Проблема в том, что ИИ прячет ошибку за правдоподобным кодом. И на синтетических тестах (даже написанных вручную) все может работать, а продавшее - ломаться.
Почему я пытаюсь ограничить LLM? Да потому, что контекст LLM, даже со всеми ухищрениями, сильно меньше контекста человека. Если ИИ скормить слишком много информации, он начинает ее сжимать. А это чревато тем, что важные требования могут оказаться потеряны, а ИИ сосредоточится на второстепенных. Примеров этому достаточно много даже здесь.
ИИ не задает вопросы, потому что ему непонятно. Он задает их, потому что в его настройках прописано: «Если энтропия запроса выше X%, возьми три наиболее частых неоднозначности из обучающей выборки и сформулируй их как вопросы».
ИИ может остановиться и указать на ошибку. Но не потому, что понял логику, а потому что:
В обучающей выборке были похожие баги, и он запомнил паттерн ошибки.
У него есть встроенный валидатор.
Он сопоставил ваш код с известной проблемой.
Если вы дадите ему уникальную архитектурную задачу, которой нет в интернете, он не остановится. Он спокойно напишет красивый код, который упадет в рантайме, потому что он не просчитывает последствия на 10 шагов вперед.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем. Это решает лишь проблему поиска и анализа небольшого объема данных на большом объеме кодовой базы. Да инструмент полезный, но очень ограниченный.
Меня всегда умиляет слово "понимает" в привязке к ИИ.
Мой нож понимает как разделать мясо. Мой автомобиль понимает ПДД. А самолет понимает аэродинамику. А мой компьютер вообще все понимает, он очень начитанный, у него куча книг на жестком диске.
Код и бизнес логика это хоть и связанные, но разные задачи. Код это ответственность программиста. Бизнес-логика - архитектора(аналитика) и заказчика. Но это именно зона ответственности.
У меня программисты вполне себе разбираются в бизнес логике которую реализуют. Умеют критически оценивать запросы пользователей и задавать вопросы.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой. Он знает некоторые шаблонные решения, да и то, если они опубликованы в интернете. Но не более.
Если человек видит и задает вопросы, когда что-то не укладывается в его знание процесса. То, ИИ не будет ничего "уточнять". Он просто реализует. И даже если его попросить проанализировать, он не найдет ошибок бизнес-логики. Он сможет найти только отличия от известных ему шаблонов.
Это называется: бумага все стерпит. Вы можете писать о себе все что хотите. Что вы пинками дверь к директору открываете. Что он ГД во всем с вами советуется. Что личного шофера отправляет за вами, когда что-то не работает... Никто это все равно проверять не будет.
А реальност она совсем другая. Если ваше "ядро" не будет удовлетворять бизнес, на все ваши рассказы про математичность ядра, про грязые руки и прочее... никто не посмотрит. И будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен.
Вы уж определитесь о чем рассуждаете. То "выбираете заказчиков", то "сама компания ведет разработку", то это "отдельная бизнес модель".
Я вам про Фому, а вы мне про Ерему...
В ТМ тоже есть сроки. В ТМ тоже есть критерии приемки работ. Просто сроки короче, задачи локальней а бюджет закладывается. Даже бюджет там тоже есть. Просто считается и расходуется иначе.
И в плане управления проектом (развития программного продукта) разницы между ТМ и Фиксом не будет ровно никакой. ТМ и Фикс - это просто условия оплаты, а не методология.
Для внедрения программного продукта, а мы изначально обсуждали именно его, ТМ плохой выбор. Да, в случае когда компания не имеет зрелых бизнес процессов и в принципе не очень понимает что ей надо это будет практически единственный вариант. Но по сути это и есть незрелый заказчик.
Есть еще вариант когда компании просто не хватает собственных исполнителей для реализации всего объема работ в срок. В этом случае, внедрением занимается сам заказчик, а исполнитель просто дополнительные руки. То есть, по сути, тот же самый проект с фиксированными сроками, бюджетом, объемом работ, но с привлечением дополнительных сил. Но это уже не TM, а outstaffing в рамках проекта. Похожее, но все же разное.
А вот для поддержки и дальнейшего развития, ТМ вполне себе подходит. Задачи появляются постепенно и закрываются по необходимости. Но тут и объем работ иной, и стоимость, и срочность не сопоставима с внедрением. И цена ошибки ниже. О чем я собственно уже писал.
То что описано у вас не внедрение. Это что угодно: поддержка, сопровождение или доработка — но не внедрение.
Внедрение — это реализация конкретных процессов на конкретной платформе в заданных временных рамках. Его цель — перевести эти процессы на новую платформу. Внедрение почти всегда разбито на этапы, и первый релиз никогда не бывает финальным. Но у него всегда есть перечень целей и задач, которые должны быть решены, и сроки, в которые они должны быть решены.
Когда внедрение завершено, предприятие получает систему, в которой может полноценно вести свои процессы. Не обязательно все сразу и не обязательно идеально — но поставленные цели и задачи внедрением решены.
Дальше начинается сопровождение продукта: силами заказчика или сторонней организации. На уже работающей системе в рамках сопровождения можно менять процессы, оптимизировать их, добавлять новый функционал. Но это именно сопровождение, и у него другая логика управления: не фиксированный объём работ до результата, а регламент, SLA, приоритеты и поток задач.
И даже в сопровождении заказчик и исполнитель согласовывают стоимость и сроки работ. Просто согласовывают их иначе, чем при внедрении.
Это не опытный заказчик, а заказчик хорошенько обработанный меркетолагами. Ни один адекватный заказчик не будет вливать деньги не имея представления о том когда это кончится и что он получит в результате.
Внедрение программного продукта это вполне себе фиксированный процесс с началом и концом.
Потом, уже работающий продукт, можно дорабатывать. Внедрить новые модули, менять уже внедренные и т.д.
Но даже в этом случае, это будут отдельные проекты с началом и концом.
Ну и да, не стоит путать внедрение с сопровождением и поддержкой. Это очень разные процессы с разными задачами и методами.
Это вы описываете идеального исполнителя. А такие встречаются редко.
Если заказчик сам не разбирается в системе - подход правильный. Он не знает продукт и объясняет на своих процессах, что ему нужно. Исполнитель вникает в процессы заказчика и предлагает грамотное решение.
Однако, мне встречалось другое: исполнитель приносит решение, которое не ложится на процессы заказчика. Всё по методологии вендора, красиво расписано, хорошо задокументировано (и даже идеально реализовано), но на практике это не просто неудобно, а разрушает рабочие процессы.
Либо у исполнителя не было специалиста, который способен это увидеть, либо не было желания вникать в процессы заказчика.
Всё зависит от того, есть ли у сторон нужные компетенции и насколько сильны специалисты.
Если заказчик сам не понимает, что он хочет - вы никогда не сдадите такую систему.
Заказчик должен понимать, что он хочет. Требования могут меняться и дорабатываться при разработке системы.: что-то не предусмотрели, что-то поменялось, для чего-то нашли лучшее решение... Но "то что заказчик хочет" не меняется. Меняться может "то как он это хочет получить".
В противном случае, получится система которая будет соответствовать формальным требования ТЗ, но будет совершенно не рабочая и бесполезная для заказчика.
Читать код сложнее. Это очевидно.
Хех... какая наивность. Я то еще помню те времена, когда некоторые заводские диски оказались с вирусом.
Ну и DVD+/-R где-то все таки записывали. Так что получить на диск вирус - вполне возможно.
О! Точно! Последний раз я держал в руках диск с МРТ. Правда, за чем он мне нужен, я так и не понял. Результаты были доступны врачу во внутренней системе поликлиники.
LLM не обладает пониманием инженера — она обладает статистической уверенностью, которая может быть катастрофически ошибочной. Человеческое «ничего не понял, надо уточнить» — это не баг, а важнейший механизм верификации, основанный на реальном понимании предметной области. LLM же с абсолютно одинаковой уверенностью сгенерирует и гениальный краевой кейс, и тест, проверяющий деление на ноль через сакральный смысл числа 42, если это коррелирует с её обучающей выборкой.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели. И то, что написание тестов вы отдадите другому ИИ ровным счетом ничего не меняет.
Утверждение, что агент «возвращает только нужное, безо всяких промежуточных этапов», выдает непонимание природы LLM-агентов в продакшене. Вы называете «мусором» ту самую цепочку рассуждений, которая, является единственным способом для LLM решать сложные задачи с приемлемой точностью. Агент не «шуршит», фильтруя мусор, — он галлюцинирует на каждом промежуточном шаге. Проблема «основного контекста» никуда не исчезает: она просто переносится в контекст агента, где, благодаря многоагентности, ошибки накапливаются, а возможность человека проконтролировать логику стремиться к нулю.
Ну и главное: сравнение с человеком, который «не помнит каждую строчку кодовой базы», некорректно. Человек не помнит код, но он хранит ментальную модель системы. Он знает, почему модуль А не должен вызывать модуль Б напрямую, потому что полгода назад это приводило к гонке состояний. LLM не помнит синтаксис и не строит ментальную модель. Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Проблема не в том, кем написан тест, а в том, что вы делегируете машине верификацию истинности, на которую у машины нет ни права, ни способностей.
А кто-то еще пользуется дисками, кроме консольщиков? Я уже и забыл, когда последний раз в руках держал CD или DVD. Где-то в закромах валяется внешний привод, но ни на одном компе, ноутбуте их давно уже нет.
А вы знаете, это прекрасный вопрос. Для меня он полностью закрывает необходимость дальнейшей дискусси.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый. По этому LLM оперирует энтропией, а не "понятностью".
Юнит тесты для проверки ИИ, которые пишет сам ИИ? Это способ самоуспокоения и к проверке кода имеет весьма касательное отношение. И даже 100% покрытие тестами написанными ИИ не даст гарантии, что код правильный.
Проблема ИИ, не в том, что ИИ ошибается. Проблема в том, что ИИ прячет ошибку за правдоподобным кодом. И на синтетических тестах (даже написанных вручную) все может работать, а продавшее - ломаться.
Почему я пытаюсь ограничить LLM? Да потому, что контекст LLM, даже со всеми ухищрениями, сильно меньше контекста человека. Если ИИ скормить слишком много информации, он начинает ее сжимать. А это чревато тем, что важные требования могут оказаться потеряны, а ИИ сосредоточится на второстепенных. Примеров этому достаточно много даже здесь.
Какой вы самокритичный... ну раз не понимаете, то и ладно.
ИИ не задает вопросы, потому что ему непонятно. Он задает их, потому что в его настройках прописано: «Если энтропия запроса выше X%, возьми три наиболее частых неоднозначности из обучающей выборки и сформулируй их как вопросы».
ИИ может остановиться и указать на ошибку. Но не потому, что понял логику, а потому что:
В обучающей выборке были похожие баги, и он запомнил паттерн ошибки.
У него есть встроенный валидатор.
Он сопоставил ваш код с известной проблемой.
Если вы дадите ему уникальную архитектурную задачу, которой нет в интернете, он не остановится. Он спокойно напишет красивый код, который упадет в рантайме, потому что он не просчитывает последствия на 10 шагов вперед.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем. Это решает лишь проблему поиска и анализа небольшого объема данных на большом объеме кодовой базы. Да инструмент полезный, но очень ограниченный.
Меня всегда умиляет слово "понимает" в привязке к ИИ.
Мой нож понимает как разделать мясо. Мой автомобиль понимает ПДД. А самолет понимает аэродинамику. А мой компьютер вообще все понимает, он очень начитанный, у него куча книг на жестком диске.
RAG не снимает ограничения ИИ. Он обходит некоторые, но не всегда успешно.
Код и бизнес логика это хоть и связанные, но разные задачи. Код это ответственность программиста. Бизнес-логика - архитектора(аналитика) и заказчика. Но это именно зона ответственности.
У меня программисты вполне себе разбираются в бизнес логике которую реализуют. Умеют критически оценивать запросы пользователей и задавать вопросы.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой. Он знает некоторые шаблонные решения, да и то, если они опубликованы в интернете. Но не более.
Если человек видит и задает вопросы, когда что-то не укладывается в его знание процесса. То, ИИ не будет ничего "уточнять". Он просто реализует. И даже если его попросить проанализировать, он не найдет ошибок бизнес-логики. Он сможет найти только отличия от известных ему шаблонов.
Это называется: бумага все стерпит. Вы можете писать о себе все что хотите. Что вы пинками дверь к директору открываете. Что он ГД во всем с вами советуется. Что личного шофера отправляет за вами, когда что-то не работает... Никто это все равно проверять не будет.
А реальност она совсем другая. Если ваше "ядро" не будет удовлетворять бизнес, на все ваши рассказы про математичность ядра, про грязые руки и прочее... никто не посмотрит. И будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен.
Но вы продолжайте в себя верить.
Ох уж эти сказки, ох уж эти сказочники...
А причем тут программисты? Речь шла об умении ИИ проверять бизнес логику.
Но, вообще-то, для человека разбирающегося в предметной области, это повод задать вопрос бизнесу, нет ли тут ошибки. ИИ на это внимания не обратит.