Вот здесь способ оценки задач не в часах.
А прямо скажем в попугаях.
Хотя ряд полезных мыслей есть, например, небольшой классификатор задач по сложности.
Ну и как бы вы это положили бы на СППР?
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 дорожками - неплохо бы такую схему прикрутить в СППР для отрисовки Процессов и Шагов.

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

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

Напоминание:
- для новых пользователей в чате работает запрет на сообщения в течение 24 часов
- работает фильтрация по отдельным словам на спамеров
- работает народный @banofbot - ответом на сообщение

Хорошо структурированная статья по принципам проектирования кода ПО (не самого ПО, а именно кода).
С примерами на 1С.
А кто продумывал как SOLID применить к проектированию на уровне функциональности пользователя - т.е. на уровне СППР?