Архитектурная работа моего отдела. #СМС23

После прочтения / просмотра кусочка курса по архитектуре предприятия, сразу же захотелось навести порядок в своем не очень маленьком отделе.

Главные проблемы, которые я пытался решить:

  • Создать понимание у себя, чем мы занимаемся (наша система / ы), какие жизненные циклы эти системы проходят, какие практики используются и какие роли выполняют эти практики
  • Понять, на какой стадии развития находится та или иная практика / орг возможность
  • Создать понимание у моей команды по вопросам выше
  • Создать возможность для распределенного лидерства, так как новые задачи, желание выстраивать новые практики, возникает у бизнеса каждый день, и необходимо как то на эти вызовы отвечать

Что удалось сделать:

  • Удалось описать одну из моих систем, описать ее жизненный цикл, верхнеуровневые практики по разным системным уровням, привести в соответствие этим практикам чеклисты и рабочие продукты. Все было сделано в табличной форме в coda.io
  • Эта архитектура была представлена команде и был получен предварительный ОК, для того, чтобы мы попробовали работать используя эту модель
  • Было выявлено, что члены моей команды не знали, какие практики и чеклисты используется другими членами моей команды, хотя роли, которые они играют одни и веже (однако, эти роли играются в немного разных доменных областях)
  • Для меня стало понятно, какие же системы мы создаем и стало легче отвечать бизнесу, на вопросы, которые не касаются этих систем (просто мы этим не занимаемся потому что мы создаем системы X, Y, Z) или “давайте создавать новую систему”

Что необходимо доделать:

  • Операционализировать исползование архитектурной модели
  • Добавить состояние практик/оргвозможностей и практики провода этих практик по их состояниям
  • Разбить крупные роли на более мелкие, для того, чтобы была возможность делегирования практик другим орг звеньям. На текущий момент, с модульностью проблемы, один модуль выполняет очень много функций. (Хотя может быть это и здорово, с точки зрения ТРИЗ). Что ведет с большой зависимости от конкретных орг звеньев, и их перегруженности
  • Додумать и описать все системы, которые создает мой отдел

В целом, я считаю, что для первого раза (я конечно делал орг чарты и распределял функции по орг звеньям и до этого, но это не было системно) архитектура получилась более менее практичной и вменяемой. Я попробую доработать ее в след 2-4 недели и сделать ее actionable.

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

Коллега, а если не секрет - сколько “ролей” у вас в отделе?
Не сотрудников, а именно ролей?