Вообще, тут некоторые высказываются, как будто в каждой ИТ компании есть разработка. Это ж далеко не всегда так и я очень глубоко согласен, что 90+% всех технических задач это таки сопровождение (чёрных недокументированных ящиков без доступа к коду)

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

Всем привет!

Вчера на zoom-е группы были озвучены следующией темы:
1. Alexander Samarin : ISO/IEC/IEEE 42010:2011 viewpoints, views,  model-kinds and models for Enterprise Architecture (Smart Cities as an example)
2. Aleksey Senkov : Как организовать обмен данными и знаниями (обученными интеллектуальными моделями / системами)  между заинтересованными сторонами? Какие особенности и варианты решения?
3. Gennady Kruglov : - трансформация роли архитектора в технологического партнёра бизнеса (сейлов, топов, лпр)
4. Gennady Kruglov : - взаимосвязь арх паттернов (микросервисная архитектура, событийно ориентированная архитектура, озеро данных, лямбда архитектура) при построении транзакционно-аналических решений
5. Gennady Kruglov : - референсная архитектура (композитный арх стиль?) построения транзакционно-аналитических решений в рамках продуктово-платформенного подхода
6. Alexander Luchkov : Пет-проекты для студентов и магистрантов. Втаскивание студентов в реальную деятельность.
7. Alexander Luchkov : Исследования в области "хороших" практик проектирования вывод. Методики организации проектирования.
8. Alexander Luchkov : Документирование эскизных и технических проектов при поддержке средств моделирования.
9. Дарья Кафтан : Культура документирования проектных решений и наполнение базы знаний. Методики определения степени детализации документации, которая принесет максимальный профит для эффективного внесения изменений. Как убедить команду, что это действительно нужно, и привить культуру документирования в команде и компании.

Спасибо всем за участие. Надеюсь, ничего не забыл. Задавайте уточняющие вопросы инициаторам. Через пару дней устроим голосование по приоритетности тем

Не понимаю как сопровождать BlackBox. Просто вне рамок, я сбегу от такого.

Звучит так, что на всех уровнях иерархии набралось достаточное количество компетентных людей. Что и позволило провести преобразования. Если это стечение обстоятельств, то рад за такое везение. Если это кем-то организовано с 0,со старта "один в поле воин", то этот кто-то крут.

По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D

Звучит так, что на всех уровнях иерархии набралось достаточное количество компетентных людей. Что и позволило провести преобразования. Если это стечение обстоятельств, то рад за такое везение. Если это кем-то организовано с 0,со старта "один в поле воин", то этот кто-то крут.

По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D

А на листы есть отвественные, что их обновляют, в общем управляют изменениями?

Не понимаю как сопровождать BlackBox. Просто вне рамок, я сбегу от такого.

Мы на самом деле говорим о TTM (проход) и TCO. Вместо затрат приходит на ум утилизация.

Отсутствие дизайна, документирования, наличие тех. долга и пр., приводит в конечном итоге к снижению TTM и росту TCO.

Фокусируясь на утилизации упускается из виду TTM и TCO. То есть вроде бы все заняты (затраханы до предела), а фичи выводятся всё медленнее и стоят всё дороже.

А самое главное - менеджеры этого не видят и сами не понимают, что делать. Отчасти потому что многие из них "эффективные менеджеры общего назначения" и не понимают в производстве ПО.

По чек-листам. Что-то сложнее перезагрузки пк или сброса кэша - перенаправлять на команду развития продукта. :D

"набралось" - звучит, как будто "мы не нажимали, оно само". Но надо нажимать, иначе само никуда не наберется.

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

Вертикальная организация команд и микросервисы помогают:
1. развитие и поддержку можно сосредоточить в одном орг.юните. Если дальнейние изменения начинат тормозить, гораздо проще ткнуть пальцем в конкретный проект “потому что вот тут было насрато”.
2. “плохие” проекты можно огородить от остальной системы и дать им тихо сгореть в своем маленьком аду

Под коррекцией внесение изменений в бизнес-данные скриптами или что-то другое?

А как же влияние орг юнитов друг на друга и взаимодействие микросервисов? Насрато может быть в дизайне верхнего уровня, и изменения вносятся тоже начиная с него, до микросервисов еще опуститься надо.