Запись трансляции

В СППР, хотя и используется IDEF0-подход, но взаимодействие участников команды лучше реализуется через функциональный подход.
В цепочке Консультант-Аналитик-Архитектор-Разработчик-Тестировщик-РП каждому своё место и свой вход и выход.
И свой договор.
Предлагаю обсудить какой договор должен быть заключен, скажем с Архитектором, на фрилансе (ГПД).
Ключевые тезисы, реализуемые в договоре:
1) не более чем на 1-2 страницы
2) функциональное описание прав и обязанностей
3) универсальность для сделок в РФ и вне РФ
4) максимально полный, но краткий охват что должны архитектору, а что должен он
5) без ежемесячных актов
6) простота прекращения договора по инициативе заказчика, но защита отработанных денег исполнителя
Текст договора во вложении.
UPD Текст договора скорректирован, приведён к строгому соответствию понятия договора оказания услуг - слово "работ" исключено полностью.

По интернету с год уже бродит тезис, что ИИ (chatGPT) "убьёт" профессию программиста.
Какие из этого последствия для остальных и для СППР?
Кратко: возрастёт роль архитектора (аналитика) и СППР (точнее ему подобные и лучшие его инструменты) станет основным рабочим местом для создания кода.
Вот мысль из одного из комментариев в сети:

@kape404
3 недели назад
Мне кажется, что все резко начнут апаться до архитекторов со знанием промтинжиниринга, будешь просто писать больше сервисов, а не строк кода, сначла грубыми мазками накидаешь код с помощью чата гпт, потом будешь напильником докручивать сервис под нужды бизнеса, все таки качественный код помогает экономить на железе, которое и так говорят, что в дифиците

UPD вот ещё мнение очень хорошего ИТ-директора, выросшего из программистов (не только 1С знает) о мотивах по которым ИИ заменит программиста неизбежно

"Просто программист стоит больше чем может генерить бизнес, 100% будет замена"

В качестве вклада в сообщество 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 и скармливает его СППР.
Если выскажете интерес к функционалу, разработчик чат читает и может вам ответить публично или в частном порядке.