В качестве вклада в сообщество https://infostart.ru/1c/tools/1998847/

Оффтопик
Схема как точнее спрашивать chatGPT и схожие с ним AI инструменты.
Т.е. как конструировать свой вопрос, чтобы ответ AI был боле релевантным.
На английском увы А нет, теперь не увы. Теперь и на русском.

Интересная статья от ВЦ Раздолья и его многолетнего (это важно) руководителя Грибкова Евгения (лично, это тоже важно) по рискам проектов внедрения ПО ERP-класса.
Человек, если не ошибаюсь лет 20 делающий такие проекты и небось не десяток, а сотню, сделал неплохой свод основных рисков.
Мотайте информацию на ус - как взгляд со стороны, делайте свой анализ и выводы - "сверяйте часы" с известной личностью и известным специалистом в этой области.
Своё мнение я высказал на сайте в комментариях.
Кратко - похоже что крупный внедренец до сих не имеет технологии решения этих рисков, которые нормальны, т.е. обычное дело на проектах.
Это мои ощущения от текста.
Не удивлюсь, если БИТ и WA и иные франчи-интеграторы тоже в такой же позиции за все годы.
Обратите внимание на риски № 4 и № 5. которые касаются проектирования и длительности проектирования.
https://infostart.ru/pm/2002890/

Цитаты из статьи:
"А сейчас эпоха науки. Хорошая архитектура и чистый код уже на втором плане, потому что люди этому уже более‑менее научились."

"Разница в том, что 40 лет назад наука угрожала рабочим местам библиотекарей и телефонных операторов, а сегодня она режет аналитиков, переводчиков, дизайнеров и ассистентов. Программисты следующие в очереди"

"Когда вы молодой, вы многообещающий и все вас хотят. Все двери открыты для вас, и эта эйфория закрывает от вашего взгляда обратную сторону мира:
Если двери существуют, то для того, чтобы быть закрытыми для кого‑то. И этот кто‑то — любой, приближающийся к 40 годам, кто не соответствует социальным ожиданиям."

"Станьте безумно публичным" (начните с малого - сделайте трансляцию по своему опыту в СППР в чате СППР :) - жду ваших предложений)

Прочитайте статью - не пожалеете, интересна крайне
https://habr.com/ru/articles/782740/

В результате голосования экспертной комиссии по номинации «Вклад в области "ИТ-анализ"»
премию получил участник нашего чата Дмитрий Кучма
Поздравляем Дмитрия с победой в номинации!
Информация о победителях в других номинациях здесь

Цитата "СППР ... плод .... диких фантазий"
Это острый и интересный коммент из чата на близкую тематику, видимо, от сотрудника 1С погруженного в тему ERP и всего с ней связанного - см. ссылку ниже.
СППР на наш взгляд полезный и нужный продукт, но вялорастущий в направлениях интересных сообществу (упор в сторону разрабов, а не аналитиков и архитекторов).
Автоматизация и правильная архитектура - вот чего в первую очередь недостаёт СППР.
UPD по просьбе удалил ссылки на репост. Но желающие могут поискать материал в указанном чате и ознакомиться со всей дискуссией.

Интересная статья про место архитектора с точки зрения объективных глобальных процессов.
Для тех кто пытается понять что архитектору делать, куда ему развиваться и идти ли в архитекторы.
Тезисы на подумать из статьи:
1) Согласно закону Мура ИТ замедляется в настоящее время. Взрывной рост прекращается, идёт переход к горизонтальному развитию.
Именно это время оптимально для архитектора, здесь он нужнее всего и боле выгоден.

2) Идея о роли архитектора - его задача реализовать схему Шеннона (алгебру Буля) к архитектурным описаниям.
Это значит преобразовать архитектурные описания в уравнения.
А раз есть уравнения, то можно провести автоматический рефакторинг/упрощение.
Вот это и есть автоматизация архитектуры.

3) Agile и т.п.

Гибкие методологии разработки, на мой взгляд, главный гвоздь в крышку гроба архитекторов.

Командам, которым для разработки программы достаточно фреймворка можно отказаться от архитектора.

(имеется в виду фреймворк в который заложено много паттернов проектирования)
Водопад - эффективная схема времён дорогих компьютеров и дешёвых программистов.
Эджайл - это схема заменяющая архитекторов на техлидов и тимлидов.

4) Программисты - "психические тормозы". Бизнес - психические "разгонщики".
Бизнес+программисты = продуктивная шиза в эджайле. Шиза разруливается посредником в коллективе, тем же архитектором.

5)

Естественным развитием гибких методик разработки стал архитектурный подход Domain Driven Design (DDD)

...

и ввёл понятие "Единого язык

Собственно СППР1 и была основана на попытках свести к единому языку общений всей команды.

https://habr.com/ru/companies/oleg-bunin/articles/735032/

Записки в формате черновика от участника нашего чата.

Сказ о том, как одна команда монстра сопровождала
+ –
Данная статья родилась в муках сопровождения одного интересного субъекта.
Монстр, кто он...
Какие монстр породил проблемы
Решено, дракона надо приручить...
 
Монстр
Монстром будем называть конфигурацию ЕРП с двумя встроенными отраслевыми продуктами, Модуль CRM и Модуль PM. Также к монстру прилагаются доработки, выполненные различными командами в разное время, разбросанные по самой типовой конфигурации и по 70 расширениям.
Насколько удалось выяснить, такой роли, как архитектор, в процессе создания Монстра не было, поэтому использовались разные подходы доработок, например: 
- одно расширение, один разработчик;
- одно расширение, одна подсистема;
- Новые метаданные создавались частично в расширениях, частично в основной конфигурации..
Какие монстр породил проблемы..
Итак, сей продукт мне приходилось поддерживать около трех лет. В процессе поддержки вылезли следующие проблемы:
1. Формы.
Одна и та же форма могла быть захвачена в нескольких расширениях. Например форма справочника Ресурсные спецификации редактировалась в 6 расширениях. Для примера, чтобы внести правки, понадобилось выяснить, а где у нас сделана "вот эта кнопка", что она делает, кто имеет к ней доступ и т.п., ответить с ходу не представлялось возможным. Плюс ко всему, кнопка могла быть выведена на форму программно, а могла быть добавлена мышкой. Код добавления кнопки мог быть в самой форме в расширении, а мог присутствовать в переопределяемом общем модуле...
Форма в расширении, при изменении формы поставщика в основной конфигурации, автоматически не обновляется. Нужно обновлять ее вручную. И таких форм может оказаться не одна, и не две, после обновления основной конфигурации.
 
Некоторые формы в расширении после путешествия через несколько платформ (в процессе сопровождения расширения прошли от 8.3.16.хххх до 8.3.21.ххх) начали "странно себя вести". В одном случае клиентский сеанс просто падал при попытке открытия определенного справочника. В другом случае в общий модуль, куда передавался контекст формы, приходил неверный тип данных в одном из реквизитов контекста. В обоих случаях помогло только полное удаление формы в расширении и повторное ее создание.
2. Данные в расширениях
В расширениях присутствовали объекты с данными. Часто требовалось в одном расширении обращаться к справочникам/документам/регистрам другого расширения. Думаю, не нужно расписывать, какие это может вызывать неудобства.
Забегу вперед, скажу, что решено было перенести в процессе сопровождения данные из расширений в основную конфигурацию, при этом:
При переносе нескольких справочников из расширения в основную конфигурацию возникла однажды платформенная ошибка "Найдены дублирующиеся записи в менеджере баз данных...". Применить обновление основной конфигурации с новым справочником не получалось. С помощью выгрузки конфигурации и расширения в файлы были проверены идентификаторы объектов метаданных, одинаковых идентификаторов не нашлось. Проверены имена объектов, тот же результат. Опыты на копии показали, что помогает полное удаление расширения и добавление его заново. А у нас в расширении есть данные.... Повезло, что данных в расширении было мало, удалось выкрутиться.

При попытке переноса объекта с данными в другом случае, все прошло гладко, но в процессе проверки на копии вылезла "магия": "Обращение к несуществующей константе". Ошибка выскакивала при открытии любого справочника. В расширении осталась константа. Обращения к этой константе были только в этом же расширении. Здесь обошлось, потому-что "магия" не помешала быстро перенести остальные объекты с данными из этого расширения и удалить его. После удаления расширения ушла и ошибка.

Следующий перенос справочника. Расширение отключено после переноса. Платформенная ошибка: Ошибка SDBL:

Поле Fldххх таблицы Documentххх не может принимать значение NULL

Для сторонников подхода "Архитектура как код" есть своя среда и,развиваемся Сбером, платформа. Вышел сводный, так сказать, пояснительный материал.
Кто ищет альтернативу подходу СППР можно ознакомиться. Напоминаю, что есть альтернативы
1) Как в СППР. Вот, кстати, как его кратко назвать? Парсинг конечного ПО в специализированную среду хранения кода и метаданных?
2) Архитектура через шаблон - активно развивается некоторыми крупными компаниями.

В связи с востребованностью повторю ответ Евгения Чекушкина на вопрос тех кто СППР с git пытается подружить https://t.me/SPPR_1C/9113

В копилку материалов (что-то не вижу было ли ранее опубликовано в нашем канале, поиск по названию не нашёл)
Использование 1С:СППР при разработке 1С:ERP
https://www.youtube.com/watch?v=uHPQ_sy0-uQ&t=1s

Понятие "Механизмы" в СППР.
Предлагается рассматривать его как аналог "API" в других средах разработки, в котором разработчик объявляет как будет обработан объект (документ).
В контексте 1С "обработан" - это значит разнесён по регистрам.
В контексте подхода к разработке это "библиотечный" подход - при котором в конфигурацию закладываются механизмы, позволяющие обрабатывать даже ещё не существующие объекты (документы).
Т.е. разработчик механизма заранее учитывает, что разработчика других доработок конфигурации могут создать свои объекты, но механизм первого разработчика опознает и примет к проведению любой новый объект на основе "API"-описания.
Говорят на таком подходе построена 1С ЗУП.
Для большей детализации рекомендуется смотреть презентацию 1С "Механизм проведения в концепции модульности "Механизм проведения в концепции модульности"

Инсайд
Один из участников нашего чата сообщает, что у него в наличии почти готовый функционал загрузки профилей пользователей в СППР.
Работает на основе Microsoft TFS - запускает базу, потом запускает обработку, перехватывает xml и скармливает его СППР.
Если выскажете интерес к функционалу, разработчик чат читает и может вам ответить публично или в частном порядке.

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