Что там ещё было... Перенос остатков - это приходится учитывать, если продукт решили зарефакторить или устроить ребрендинг. Особенно актуально для сервисов, задействующих бигдату. Например, система рекомендаций. Они держаться на анализе накопленных данных, смена формата хранения или источников - боль, приходится придумывать переходные моменты, временные решения, пользоваться чужими сервисами (это про интеграцию ещё, кстати). Подтвержденные ошибки... Самое смешное, что было недавно - сервис электронной библиотеки, в конце года решил наградить топ самых читающих, а отдел рекомендаций обнаружил, что весь год из-за некачественного сделанного антибот-службы самые читающие пользователи их системой игнорировались. И метрики по ним поэтому в... глубоко, в общем. А метрики - главное для систем, которые не продаются обособленно, а в составе других продуктов или сервисов. Потому про подтвержденные ошибки тоже не совсем радужно. Про четкость ошибок... Тут даже мой личный опыт - от отдела сопровождения приходит жалоба студента, я её разбираю и либо делаю заявку (на корректировку продукта), либо пишу обоснование и отправляю специалисту по сопровождению. Не понимаю, чем это отличается от хелп-деска и линий поддержки.
--------------------------------------------------------------------------------
Теперь про СППР, дабы не выгнали за флуд
Если смотреть демо-базу, изменения во второй редакции, курс Филиппова, наблюдение за продактами и личный опыт ведения в СППР разной степени модификации как проекты (90%), так и подобие внутренних продуктов (10%), то пока выявила такие отличия:

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

- целевые задачи, этапы. При проектной разработке цели заказчика и проектной команды различаются. Для заказчика - получить продукт, закрывающий потребности, для исполнителя - получить прибыль от своей работы (а продукт - это типа побочка, результат работы, отдаваемый в чужие руки заказчику). Цели команды продуктовой разработки в большинстве своем совпадают, словно заказчик и исполнитель в одном командном лице. СППР сделана для продукта, и потому целевые задачи и этапы должны быть связаны с этапами развития продукта. Частый пример интегратора - попытка в целевые задачи поместить свои цели, а в этапы - этапы проекта исполнителя. Приходится объяснять, что тогда у них все требования/идеи будут привязаны к одной целевой задаче "обследование заказчика" (условно), а в целевую задачу "разработка функционала" требования уже не придут и пр. И, повторюсь, как раз этому способствует, что в демо-базе пример по этапам или целям СППР как продуктовой разработки, и потому наивные и не окунувшиеся глубоко часто пытаются сделать так же (на курсе есть предупреждение).

- проект/конфигурация. Самое больное! Для продукта объединение понятно - проект по изготовлению продукта, т.е. конкретной конфигурации. Все идеи относятся к этой конфигурации и пр. Что делать с проектом, когда конфигурация (и не одна) выбирается после сбора требований и отрисовки бизнес-процессов, когда требования (например, по НСИ) могут относится ко всем конфигурациям проекта... выкручиваемся или ломаем СППР

- бизнес-процессы. Для продукта нет необходимости отрисовывать бизнес-процесс вне продукта и держать связку АS IS и TO BE (даже если "было плохо, стало лучше", то зачем плохое помнить?) И потому для бизнес-процессов в СППР очень-очень мало... а они часто нужны, и не просто как схема для услады глаз, а в декларативном описании - чтобы привязать функциональные и нефункциональные требования, функциональные разрывы (тоже чуждое для продукта понятие), функции...

Свежие данные по портрету 1сника, сколько он зарабатывает и чего он хочет. https://infostart.ru/1c/articles/2035974/

На заметку
Почему я рекомендую в СППР и рисовании схем IDEF0 и работе с НСИ и дизайном лимит в виде числа 7.
(1С в Руководстве по СППР рекомендует 6 - это не принципиально но под число 7 есть научное обоснование)
Далее цитата с просторов интернета из комментария в Хабре)

Авторы многих известных книг, например, таких как Совершенный код, Чистый код и проч. ссылаются на исследования, согласно которым человеческие возможности весьма ограничены. Часто приводятся сведения о "магической" цифре 7, как предельному числу объектов, которые человек еще может держать в голове. Следствием этого являются рекомендации и даже регламенты, например, предельному количеству аргументов функции (!) или количеству непосредственных подчиненных одного начальника. Макконнелл в Совершенном коде выводит "Главный технический императив разработки - управление сложностью" исходя из того же принципа - ограниченности человеческого ресурса.
Хороший код от кода "с душком" тем и отличается, что минимизирует уровень сложности, необходимый для его понимания и сопровождения. Ту же цель преследуют подходы, например, предметно ориентированное проектирование (DDD), принципы, парадигмы, например, функциональная (ФП).

Из литературы могу также порекомендовать книгу Ум программиста Фелин Хермано. В ней также говорится о долговременной и кратковременной памяти, трудностях, с которыми сталкивается разработчик в своей деятельности.

Здесь на 6.40 о том как используется СППР в проекте АксиомаСофт на Ростехе
Проект с огромными параметрами, количеством пользователей 6000 в пилоте / 25000 в ожидании (см. подробнее данные проекта).
Про СППР там больше рамочно, но вы сможете прикинуть что в ней востребовано на крупных проектах
https://www.youtube.com/watch?v=oYh812yy3kQ

Интерес к СППР заметно ширится.
Даже на старом добром Mista открываются свеженькие обсуждения.
Вот здесь интересная мысль о необходимости в СППР матрицы трассировки требований
"Однако, программных продуктов, в которых была бы реализована матрица трассировки, за приемлемые деньги не возможно найти"
"Вот если бы в СППР сделали матрицу трассировки - это был бы очень востребованный продукт"
Вот здесь подробнее изложено что такое матрица трассировки. (Трассибилити, sic!)

На Инфостарт объявлено голосование за доклады на майско-июньскую конференцию.
В т.ч. за мой доклад на тему:
СППР – технология применения, недостающая функциональность, основные альтернативы – «Архитектура как код» и «Шаблон архитектуры»
Прошу поддержать рублём евро фунтами долларов голосом.
У кого есть свои доклады - скиньте в чате или в личку - сделаtv ещё пост с просьбой о поддержке со списком докладов от участников нашего чата.

Ищем обещанные рассказы про СППР в докладах:
https://event.infostart.ru/analysis_pm2024/agenda/2052365
https://event.infostart.ru/analysis_pm2024/agenda/2050184

Материалы от Станислава Султанова, архитектора немалого числа реально крупных и известных проектов,
по доработке функционала СППР с учётом опыта её эксплуатации на подобных проектах,
в настоящее время сотрудника НТЦ 1С.
Доработка Станислава, выпущенная 3 года назад,
существенно улучшает функциональность СППР (см. демо-видео файлы и файл с кратким описанием).
В настоящее время автор расширяет функционал на взаимодействие с DocHub - перспективным инструментом управления корпоративной архитектурой.
Смотрите демо-видео по ссылке или в файлах, копите вопросы.
Планируется, что Станислав по данной теме проведёт трансляцию после 11 марта и ответит на ваши вопросы.
Следите за анонсами в нашем канале.
https://disk.yandex.ru/d/cfKcpuZlO-kUnA

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

Порадуемся за успехи у коллег.
В редакторе VScode теперь можно просматривать формы 1С в предпросмотре.
Ну и типа, кто в СППР работает с метаданными - может глянуть как с ними работает VScode через расширение.
https://t.me/nixel2007_thoughts/440

Если не будет вопросов по теме, то трансляции не будет.
Кидайте вопросы в привязке к этому посту.
Пока инициативу проявила 2-3 человека. Нужно больше.
Под вопросы будет построено изложение материала,
дабы не вышло бесцельное тыкание в формы и рассказ обо всё и ни о чём.

Цитата

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

Вообще-то в первоисточнике у автора про бизнес.
Но что-то тут близко ко внедрению СППР....
Да и про пользу от внедрения ERP близко...
https://www.facebook.com/alexander.zhurba/posts/pfbid0r8wYGu4KiEkrsAuKxnavPy1tEkfVnzEMVY3Gu49u3cABEA1RiXtfQTrewTSaVnEbl

Бродя по просторам интернета и читая разные сообщества,
иной раз натыкаешься на очень интересных людей,
стиль мышления которых, их формат общения, чёткость в изложении мыслей
обращают на себя внимание и выделяют их на фоне других собеседников.
Вот пример такого человека который является к тому же участником нашего чата и аналитиком на проектах.
Я наткнулся на Гюльнару через её посты с "небезызвестным" Наумовым в чате сообщества 1С-Аналитиков.
Уровень изложения Гюльнары, понимание роли аналитиков и архитекторов в проекте меня удивили так,
что даже познакомился с ней персонально в онлайн общении.
Я не зря это сделал, Гюльнара рассказала интересное, что, например, в организации своего аналитического мышления ей помогли
курсы по..., вы не поверите, скорочтению.
Привычка и подходы к систематизации, выработанная на курсах, помогла в работе на проектах аналитиком.
Гюльнара также из этих технологий курса выработала свою технологию обучения аналитиков и натаскивания их на командную проектную работу.
Если вы ищете способы как прокачать свои аналитические навыки, что почитать, какие курсы того же скорочтения и как могут помочь - пишите Гюльнаре или может задать свои вопросы здесь.
Она также на ближайшем Инфостарте планирует выиграть участие своими докладами:
Мастер-класс: Работы аналитика в проектах автоматизации
Тренинг: Главный инструмент аналитика – его мозг
Можете поддержать доклады голосами при желании.