Валентин Рагозин
Это же типовые плюсы, под соусом которых продают идею с open source. Типа смотрите, мы можем легко проверить исходный код. На самом деле его не проверяют как правило, но возможность типа есть. А вот вендорлок не позволяет этого сделать и это как кот в мешке.
На счёт того, что российские компании не могут свернуть деятельность не совсем так, могут просто разорится или перестать поддерживать продукт.
АренаДата в своем пакете имела поисковый движок на базе ОпенСоурс, с 2024 года они перестали его продавать новым клиентам и обещали какую-то поддержку уже купившим, но как долго не ясно. Мы заложились на этот продукт как на аналог Эластика, но пока бюрократия бежала куда-то в море бумаг - этот продукт из реестра исчез.
сейчас у государство классический waterfall, перед новым бюджетным годом утверждается бюджет на ИТ. Согласовывается и выделяется в следующем году. Чтобы получить обоснование бюджета, нужно представить список того, что будет в реализации. Т.е. вы прикидываете бэклог, накидывается архитектура, требования и потом бюджет защищается. Это всё длительно в рамках год - 1 от старта проекта. Потом по идее должна начаться разработка и внедрение.
Но в реальность с помощью всяких процедур согласование бюджета и ТЗ затягивается до середины года, в котором нужна реализация. Требования начинают меняться, оценки едут, а разработка не ведётся. Когда этот процесс заканчивается, получается огромный GAP между тем что защищали и тем что запросили. И начинается разработка всего того огромного ТЗ, которое было написано. При этом в него ещё и вносятся изменения по ходу реализации. Получается адская смесь - сдать надо по документам то, что запросили в прошлом году, а по факту то, что наменяли в процессе реализации.
ГОСТ 34, который был давно написан в целом сделано неплохо, он потерял актуальность в некоторых разделах, в виду того, что ЭВМ сильно и изменились с тех пор, как его писали. Но взял его за основу и выкинув всё лишнее можно получить очень хороший шаблон ТЗ.
А глобально, я надеюсь Минцифры найдет в своём раздутом бюджете деньги на актуализацию ГОСТа, хотя бы в рамках своей новой программы Цифровой экономики и тогда можно будет очень неплохо жить в этой части.
тут у каждого свой опыт. Не знаю о каких именно книгах идет речь, потому не могу прокомментировать. Речь не идет об идеальном результате как таковом, речь идет о том, что если у человека есть какой-то образ результата, а вы ему его не выдаете только на 99,99 % то, он перечеркнет весь результат. И не дело в самодурстве, я много работал с внешней стороны и всегда одно и тоже - подрядчик всегда должен делать на 100 %, а вот внутренним службам прощают даже 50 % недоделок (при условии наличия внешнего участника), потому что они свои, а вы чужие.
На самом деле 100 % результат достижим, нужно его четко сформулировать. Обычно в проектах, есть размытые Соображения заказчика и менеджер по продажам, который говорит мы всё сделаем. А потом задача начинает уточняться и менеджер оправдывая себя говорит - да вы просто идеалисты, с вами не возможно работать! Не скажет же менеджер - блин, я так хотел бонус за продажи или мне так страшно было спорить с клиентом, что я обещал сделать, не уточнив деталей.
А чтобы лучше понять суть моего сообщения - представьте, что вам выдают машину, которая вся помыта, но правое зеркало грязное. Или например, что вы купили хлеб, а корочка у него не пропеклась.
Да, заказчик и архитектор работают напрямую. Есть два ключевых артефакта - Обзор решения, это верхнеуровневое понимание бизнес задачи. Оно описывает цели и эффекты для бизнеса и верхнюю картину того, что надо сделать в IT и тут работает архитектор. Когда решение принято, то его уже превращают в дизайн и тогда в работу включаются аналитики. Технологии выбираются перед тем, как отдать в разработку, а не наоборот.
Я встречал названия
Обзор решения: Solution overview, high-level design, Conceptual design, Statements of work, Change Request. Даже Use Case сюда можно отнести.
Дизайн решения: Detail level design, техническое задание, Solution Design, ОТАР (общеотраслевое технико-архитектурное решение)
Ну не совсем, требования не панацея. Об этом ещё будет. В первую очередь важна коммуникация и контакт между заказчиком и архитектором.
Да, отличная иллюстрация. А главное винить некого