Одним из впечатливших меня докладов с #dotNext2024 стал доклад Влада Хононова "Фрактальная геометрия в проектировании систем". Он дал столько пищи для размышлений, что наверное я сделаю еще немало материалов на его основе.
В рамках доклада Влад предложил рассматривать работу множества разных систем через призму обмена энергии. И если в случае с IT признать, что энергией являются "Знания" (или "Данные"), то их построение и развитие вполне себе похоже на то, как развиваются живые организмы, электрические сети, организации.
Важным моментом развития является то, что каждое последующее внесение изменений усложняет всю систему, делает более тяжелой ее поддержку и требует больше затрат для последующих улучшений.
Для лучшего понимания расчета стоимости этих самых изменений, было предложено оценивать расстояние между компонентами и силу взаимосвязи этих компонентов.
Для примера была введена классификация расстояний программного кода в рамках:
1️) Одного метода / функции
2️) Класса (объекта)
3️) Суб-модуля (пространства имен)
4️) Модуля (библиотеки)
5️) Компоненты (набора связанных библиотек / nuget-пакета)
6️) Микро)Сервиса (или программного модуля)
7️) Всей системы (набор взаимосвязанных сервисов или модулей)
На второй картинке приведена матрица оценки сложности изменений, вкратце: Чем теснее взаимосвязь между компонентами и чем они дальше, тем дороже будет изменение.
И если для разработчиков программного обеспечения в целом это прописные истины, то для остальных скорее всего не очень. Мне показалось, что аналогичный подход можно переложить на построение процессов обмена знаниями и компетенциями внутри компании.
Для упрощения я разделил компанию на следующие уровни обмена энергией в виде информации между сотрудниками:
1️) Группы \ Участники рабочих групп по задачам или проекту
2️) Отделы \ Сотрудники одних компетенций в одном отделе, занимающиеся разными задачами
3️) Продукты \ Сотрудники разных отделов, работающих над одним продуктом (или продуктовым доменом)
4️) Компании \ Все сотрудники одной компании
5️) Группы компаний \ Включая сотрудников партнеров и клиентов
При таком разложении у нас получается, что если мы хотим внести изменения в знаниях одной рабочей группы — это довольно легко произвести, а вот внести знания для всех людей на продукте или во всей компании — уже очень трудная задача.
Один из моих любимых примеров, который однажды случился у нас на расстоянии продукта:
🟧 Один тестировщик столкнулся с проблемой ПО и завел баг-репорт
🟥 Выделенный на проблему разработчик полез смотреть баг и по итогу развел руками, сказав, что не может решить (это за рамками его возможностей
🟩 На помощь пришли сотрудники технической поддержки, которые через день решают такие проблемы у заказчиков — включили один параметр в ОС и все заработало.
Этот пример прекрасно отражает именно сложность передачи знаний: В том время, как в, казалось бы, технически менее подкованном отделе, какое-то знание было уже рутинным (стыдно его не знать) — в другом отделе про это знание даже не слышали.
Такие моменты позволяют выявлять проблемы в процессах передачи знаний, а подход с расстояниями позволяет более грамотно оценивать сложность этой передачи и прогнозировать отсутствие знаний у коллег из соседних отделов, продуктов, или у заказчиков. А когда мы знаем проблему и можем ее прогнозировать — это уже гораздо лучше, ведь становится примерно понятен фронт работ.
#dotnext #планирование #развитие #проектирование #знания #мысли #мнение #обмензнаниями #обменданными #владхононов #vladkhononov