Статья на неИТшном ресурсе, но от ИТшника, явно работавшего на нашем уровне - внедренцем сложных учётных систем.
Общий посыл статьи: ИТ правильно поступает, когда за норму берёт отказ пользователям (заказчикам) в модификации,
модификация на длительном отрезке времени невыгодна и убивает систему.
Это можно смотреть в контексте того, что приоритет за архитектурной вдумчивой и долгой проработкой изменений. А лучше отказать.
https://aftershock.news/?q=node/989974&full

На обсуждение и мозговой штурм по "модной" теме "Архитектура как код" , н уи как бы тут с СППР связать её.
https://infostart.ru/1c/articles/2031119/

Говорят в этой презентации 1С на партнёрке высказаны интересные тезисы
(называется примерно так"Управление проектами и 1С Консалтинг на корпоративном рынке", расположение примерно здесь https://regevent.1c.ru/sem0923/ 2023год):
1. СППР - "православный" продукт для управления проектами, т.е. рекомендуемый
2. 1С-Документооборот тоже "православный" инструмент для управления проектами (Я ранее говорил, что ДО в паре с другой конфигурацией, особенно с ЕРП - мощная вещь для управления бизнес-процессами. Хотя в видео, скорее всего, речь всего лишь о функционале "Управление проектами" в ДО)
3. Там доклад Лоншакова про использование СППР на проекте
4. Рекомендуют не вести все проекты в единой СППР, а на каждый проект своя СППР
5. СППР используется как мастер-система по НСИ (внутренняя доработка 1С)
6. План счетов и хозоперации тоже загнали в СППР
7. Разработка по agile (внутри водопада) в СППР с двухнедельными релизами
8. СППР используется не с конфигуратором, а с git и EDT
9. На содержание СППР нужно 4-5 человек (1-2 разработчика, архитектор-фанат-СППР, техарх, администратор). Ик!
10. Затраты на работу в СППР больше на 30%. Но это неточно...
В общем, у кого есть доступ - посмотрите, и скажите нам здесь, верно ли передана информация или это лишь неподтверждённые слухи и кривой пересказ?

Сделал сводку из чата - материал от участницы нашего чата на тему
"А про различия в подходах к проектировании и разработке (реальные, а не теоретические) можете рассказать?"
( контексте различия продуктовой разработки и проектной в СППР)
-----------------------------------------------------------------------------------------------------------
Ну ладно. Сначала лирика, чтобы в контекст погрузится.
Первое отличие и крупное - нет заказчика, есть рынок (гибридные случаи, когда продукт делается под заказчика а потом адаптируется под рынок - про такое нет близкого опыта). Вместо директора проекта - владелец продукта, вместо РП - продакт-менеджер. Тут чудес нету - если на проектах деньги должны получить с заказчика и не уйти в минус, то по продуктам деньги должны поступать с рынка и не ниже определенной границы (там план с точкой безубыточности и пр). Фантазия продакт-оунера базируется на таких вещах, как маркетинг, обратная связь, ну и такая больная тема, как метрики. Насколько капризнее пользователи, чем заказчик? Ну, например, самая частая причина провала продукта и закрытия его разработки после двух-трех спринтов - он не нужен никому. В воображении продакта всё супер, касдев показал интерес, но, например, гипотеза не подтвердилась, или это была настолько очевидная тема, что уже конкуренты подсуетились и вышли чуть раньше/лучше. Конечно, с проектом и заказчиком тоже смена команды может быть, но это больше когда уже профакапили, а не то, что после двух месяцев мирной работы им другой франч декольте показал.
Так что на счет стабильности и переделки...
Во-первых, дорожная карта, выпуски релизов... это хорошо. Но если mvp не начнет приносить хоть какой-то минимально-граничный доход (ещё не прибыль!), то дорожная карта начнет перекраиваться - под результаты A/B-тестов, под результаты опроса, под более быстрые фичи, под урезание костов и пр. Тут даже личный опыт - участие в выпуске образовательного продукта. Спланировали программу на полгода, авторы работают. Но обратная связь от первой платной когорты плюс расширенное исследование рынка подоспело - и последние темы пошли под нож, теперь быстро и оперативно надо новые спринты, переориентировать авторов и пр... а люди уже учатся.
Во-вторых, чтобы продукт окупался быстрее, маркетинговая подготовка начинается до его разработки. Поэтому есть дедлайны, которому должна быть выпущен mvp или определенная стабильная версия, особенно если под неё уже либо предзаказ, либо бета-когорта из потенциальных покупателей собрана. Далее так же - сопровождение или маркетологи требуют к определенным датам новые релизы, эскалация и претензии в случае нарушения сроков, что они не выполнили план, потому что разработка не успела/сделала навоз и пр... Разницы между дедлайном у заказчика и дедлайном по продукту я особо не заметила, разве что гнобит команду не несколько стейкхолдеров крупной фирмы, а толпа недовольных (в т.ч. в чатах и каналах) плюс обратная связь от продажников.
Поэтому, ИМХО, очень много у продукта как у проекта: есть и проекты-конфетки, и продукты-пирожки, и провалы с адочком может быть и там, и там.
Второе отличие, крупное - продукт не имеет конечного срока и может развиваться без конца (теоретически), но на практике - жизненный цикл бывает очень коротким. Эл.магазин у одного оператора фискальных данных прожил очень мало, а сил туда вложили прилично. После неуспеха команду расформировали, и все что-то разбежались.

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