Интересная тема в завтрашней конференции Раруса (18 июля).
Да и весь список тем весьма привлекателен.
Но следует заметить, СППР подаётся как инструмент для разработки и для разработчика.
Увы, видимо, и Рарус не может похвастаться умением использовать СППР для проектирования ПО.

Прямо сейчас идёт трансляция Рарус по СППР
UPD вот здесь запись конференции

Стартовал проект от Александра Сазонова СППР+

Кто интересуется вопросами оценки затрат труда программистов на проекте (до проекта)
и ищет методологический базис для оценки, рекомендуется копать от методик
CMMI и SWEBOK (по последней ссылке сразу качается файл pdf со стандартом на санкционном языке)

Главные тезисы:
- программирование это давным-давно коллективная игра
- в большой разработке проблемы чаще из-за управления (архитектуры), а не из-за технических кризисов (умения писать код)
- организация процесса разработки и процесс управления проектом разработки - это две сильно разные вещи

А тем, кто интересуется как подсчитать-спрогнозировать затраты не только на программистов,
но и на других членов команды (архитекторов, аналитиков, консультантов, тестировщиков, менеджеров),
тем стоит порыть идеи здесь.

Вот здесь способ оценки задач не в часах.
А прямо скажем в попугаях.
Хотя ряд полезных мыслей есть, например, небольшой классификатор задач по сложности.
Ну и как бы вы это положили бы на СППР?
https://habr.com/ru/companies/selectel/articles/830848/

Какое интересное описание встретилось в материалах по 1С ЕРП


Описание процессов
Для описаний процессов поддержана выгрузка и последующая загрузка в другую
информационную базу. При выгрузке возможна замена ссылок на объекты информационной базы
на скриншоты этих объектов. При загрузке описаний предусмотрена возможность сравнение и
объединение текстов описаний в выгрузке и в текущей базе.

Далее по тексту говорится что можно выгружать из некоей демо-базы в рабочую базу, что можно выгружать в копию рабочей базы для тестирования и далее контекст со ссылкой на клиент и менеджер тестирования.

Так что получается под "демо-базой" можно понимать и СППР.
Тогда, процессы, описанные в СППР можно выгружать в рабочую базу 1С ERP?
Можно в тестовую рабочей базы и гонять тестирование?
Мы в двух шагах от интеграции СППР с описанием бизнес-процессов и ЕРП?
Звучит фантастично

Ещё тема на обсуждение из материалов к той же ERP 2.5.18:

"Замена остаточного регистра накопления «Заказы клиентов» на оборотный
«Распоряжения на отгрузку»"

Мы видим, что состоялся факт - один вид регистра заменился на другой.
На пользователя это скорее всего не повлияло.
Но в коде явно существенное изменение.

А теперь приз вопрос в студию:
А если бы как архитектор, работающий в СППР, сделали бы такое изменение в объектах метаданных и алгоритмах,
то как бы вы в СППР это описывали?
Т.е. как бы описали в начале с одним регистром, а потом как бы отразили в СППР всю цепочку изменений на другой регистр.

Ох, Рарус и словоплёты.
Сделали кликбейтный заголовок к своему выступлению и излагают совершенно другую вещь.

Что ожидалось услышать: как к СППР или иной какой 1С прикрутили систему описания бизнес-процессов или систему напиcания кода как в Knime,
чтобы аналитики, архитекторы и просто пользователи могли донести до программиста какую-то схему, а он по ней построил код решения.

Вместо этого излагается методологическое решение внутри 1С ERP, которое позволило без модификации кода типовой конфигурации
описать работу авиакомпании.
Неплохое решение, весьма интересное.
Там, кстати, за основу выбрана сущность "Работа самолёта" - номенклатура вокруг которой работает производственный учёт в 1С ERP.
Аплодисменты.
Но это не no-code решение.

А теперь представьте что эта задача попалась бы вам и вашей СППР.
Как бы вы её решали в СППР.
Напоминаю суть: Архитектор Рарус выработал решение на основе определения сущностей и управления настройками 1С ERP, которое не требует кодовой доработки.
Как это описать в СППР?
Ведь решение выстроено вокруг не метаданного, а "объекта данных" - сущности у Раруса, вокруг элемента справочника "Номенклатура" для простоты.
Плюс настройки 1С.

Напоминаю, что в модели ERP от 1С, которая выпускалась для СППР настройки конфигурации присутствовали как элемент справочника "Функции" СППР1.

Сегодня в канале СППР+ ожидается развёрнутая публикация.

Кто искал теорию по оценке трудозатрат на проекте
Вот лёгкий материальчик для чтения.
Там есть про "Оценщик трудозатрат разработки (RICEF Estimator)"
И простенькая таблица базовых действий при разработке с оценкой в трудоднях.
Вперёд, колхозники!

Интересные мысли об аналитиках.
Изложено вполне системно.
Самое важный вывод - лучше тот аналитик, который работает быстрее, пусть выдаёт и не самое лучшее решение, лишь бы оно устраивало заказчика.
Сделать лучше, но качественней - это плохо, если это превышает ожидания заказчика, это ест лишнее время от проекта и от затрат у заказчика.
Ещё из искрящих моментов - наняли 50 аналитиков, уволили из них 35 (за год и менее судя по тексту).
UPD тезисы выше из статьи, а не мнение автора поста.

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

Здесь хороший теоретический свод про работу с требованиями.
Упоминается СППР как дополнение к Confluence и Jira, решающее основную проблему - сложность работы с требованиями как с элементами списка в Confluence

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

По смыслу Техпроекта в СППР он не является напрямую заданием на разработку (Разработчику).
Это агрегатор описаний планируемых модификаций.
Задания разработчику нарезаются из Техпроекта СППР отдельным видом документов СППР.
Была мысль использовать ещё один уровень Техпроектов для агрегации Техпроектов под отдельные виды разработки.

По запросу "СППР" ХХ выдаёт 101 вакансию за "всё время".
Это же число выходит при запросе "за месяц".
Чтобы это значило....

ЗАО "СППР"

Для борьбы со спамерами в чат введено условие, что новичок не может писать ранее какого-то времени после входа (какое время разумеется секрет, предположим 24 часа).
Если вы не новичок и есть проблемы написать в чат - сообщите админу.
Чай новая техника не всегда правильно умеет работать.

В канале СППР+ большая публикация по готовому функционалу.
Суть - про идеологию реализации конфигуратора в платформе (СППР) и работу с метаданными как с данными.
UPD
Через малое время обещана выкладка видео о работе в системе.

Неплохая простенькая памятка по BPMN
Особенно понравились схемы с движением потока (судя по комментам сделано в Comunda)
В статье и комментах есть упоминания используемых продуктов для рисования.
Comunda c дорожками - неплохо бы такую схему прикрутить в СППР для отрисовки Процессов и Шагов.