Мой опыт архитектурной работы

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

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

Но тем не менее и к системам создания должны быть применимы рассуждения про архитектуру, как важным решениям по разбивке системы на модули и выстраивания их связей.

В системной инженерии сегодня разделяют роли разработчика и архитектора. Разработчик придумывает, как реализовать необходимый надсистеме и внешним проектным ролям функционал. Архитектор придумывает, как систему поделить на модули так, чтобы она была поддерживаема, развиваема, ее легко было чинить и т.п.. У Архитектора своя область интересов, эти интересы называются архитектурными.

Спроецируем это на создание команды проекта.

Организационный разработчик определяет, какие практики команде необходимо применить/применять, чтобы создать целевую систему. Это функциональное проектирование. Далее организационный разработчик предлагает, какие варианты практик будут использоваться, какие инструменты будут применяться, какие оргзвенья будут эти практики реализовывать.

Если архитектор определяет, как система будет нарезана на модули и как эти модули будут взаимодействовать между собой, то оргазинационный архитектор определяет, как организация проекта будет поделена на оргзвенья и как оргзвенья будут взаимодействовать между собой.

Как организационный архитектор, сегодня я придерживаюсь подхода кросс-фукнциональных команд во вверенном мне оргзвене (лаборатория робототехники одной крупной компании). У нас единомоментно 3-5 проектов разного масштаба с целевыми системами разного уровня зрелости. В каждом из них требуется уникальный набор практик и мастерств, под каждый команда набирается из сотрудников лаборатории индивидуально. В какой-то момент был архитектурный вопрос о том, как реализовывать роли продакт-менеджера и операционного менеджера - в разных людях или в одном. Это обсуждено в соседнем моем посте.

Для наших проектов важна скорость работы. Масштабируемость на наших этапах не так критична. Поэтому кросс-функциональный подход по построению проектных команд нам вроде как подходит.

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

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

Думаю, что к этой теме вернусь в ближайшие несколько недель по мере прохождения Системного менеджмента и стратегирования 2023.

На этом все.

Спасибо мне за внимани-е :)