Пиши, выделяй

Сон разума менеджера проекта рождает чудовищ

Пост по заданию из курса "Системный менеджмент" с описанием деления практик менеджмента и их ролей в терминах моей организации.

Когда обдумывал задание, появилась мысль оформить все в виде таблицы. Да вот только оказалось, что она плохо поддерживает многоуровневые списки (или я не нашел способа). Чтобы имитировать разные уровни, пришлось играться с начертаниями шрифта. Больше так оформлять не буду.

Табличное представление ниже. Пришлось основательно поломать голову, вспоминая лексикон обсуждения практик менеджмента в моей организации. Есть ощущение, что часть практик упоминается в компании в явном виде примерно никогда. Что, конечно, совсем не означает, что их нет, речь об уровне зрелости/maturity процессов. Не называем -> не выделяем вниманием -> не развиваем осознанно.

Мой уровень оцениваю по десятибалльной шкале, 0 — «абсолютно не владеет практикой, ничего не умеет», 10 — «владеет практикой лучше всех в мире, умеет делать в этой практике всё с неизменно превосходным результатом».

Практика менеджмента (метаУ) Роль (метаУ) Практика менеджмента (метаС) Роль (метаС) Комментарий Мой уровень
Инженерия целевой системы Инженер целевой системы Инженерия Инженер Терминология в контексте: "инженер, проект, система" 6
Визионерство целевой системы Визионер Контроль исполнения проекта Куратор Относительно недавно выделенная, описанная роль 8
Архитектурная деятельность для целевой системы Архитектор Системная инженерия Системный инженер Иногда - скопиованный у заказчиков "ГИП" 7
Разработка Разработчик Разработка Разработчик Часто - инженер 5
Проектирование Проектировщик Проектирование Проектировщик Часто - инженер, инженер-проектировщик 6
Изготовление/производство Инженер-технолог Изготовление Изготовитель Аутсорс 0
Эксплуатация Оператор целевой системы Эксплуатация Оператор Чаще всего роль у внешнего заказчика 6
Инженерия платформы разработки Инженер платформы разработки Системное администрирование, Документ-контроль Системный администратор, Менеджер документ-контроля Т.к. часто результат нашей работы - проектная доментация, то документ контролер - это наш DevOps 6
Менеджмент Менеджер Руководство Руководитель Только по контексту 7
Стратегирование Бизнесмен Стратегическое управление Руководитель Только по контексту 6
Орг-архитектурная деятельность Орг-архитектор Проектирование оргструктуры Проектировщик оргструктуры Раритетный термин, не каждый год можно услышать 7
Организовывание Организитор Организовывание Организатор Редкий термин 8
Организационное развитие Менеджер по оргразвитию Функциональный менеджмент Функциональный менеджер Классическая матричная структура 8
Оргпроектирование Оргпроектировщик Развитие оргзвена Менеджер по развитию Редкий для организации термин 8
Лидерство Лидер Лидерство Лидер Часто употребляется, но с размытым контекстом 8
Операционный менеджмент Операционный менеджер Менеджмент проекта Менеджер проекта Классическая матричная структура 8
Администрирование Администратор Управление персоналом (как пример) Менеджер по персоналу Адм. практики выполняют многие роли 6
Продвижение продукта или услуги Продвиженец Аккаунт-менеджмент Аккаунт-менеджер Работаем на B2B рынке 6
Привлечение инвестиций Фандрайзер Привлечение инвестиций Основатель компании Компания - не акционерное общество 1
Практики менеджмента и их ролей в терминах моей организации

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

Кратко: приоритетными шагами видятся явное обозначение роли орг-архитектора, с задачей развертывания практик DevOps/инженерии платформы. Причем действие в таком паттерне применяется дважды - для инженерии целевой системы и для инженерии системы создания.

Подробнее:

  • Инженерия целевой системы.
    • Выделить роль архитектора, разрабатывающего концепцию системы. Создать чек-листы для контроля важных архитектурных характеристик. Примером для старта можно взять модель стандарта ISO 25010. Учитывать и документировать (ADR формат) про развилки/tradeoffs.
    • В инженерии систем создания переход на DevOps практики для организации будет означать модернизацию системы документ контроля, переход на систему управления конфигурацией/CM. Добавлять отсутствующие сейчас метрики, бенчмаркинг. В таком случае появится возможности для аудита и постоянного улучшения системы. Первый шаг в улучшении: измерить качество, скорость и количество работ в в процессах - релизы, BoMы, запросы и изменения.
  • Инженерии организации как системы создания.
    • Выделить роль организационного архитектора. Декларировать стратегической моделью организации работ - поток. Запустить пропитку, убеждение сотрудников. Еще одна ментальная модель - компания как продукт, которым должно быть удобно пользоваться. Продумать фитнес функции, контролирующие архитектуру, настроить медленные переменные для сбора данных. Заход на управленческий учет в дальней перспективе.
    • Инженерия целевой системы. Обязательно - совмещение с ролью операционного менеджера. Описание ролей. Выстраивание команд, производственных и платформенной/CM. Итеративная калькуляция SLA для контрактов/интерфейсов взаимодействия с платформенной/CM командой. Сбор информации для поиска процессов к автоматизации.

Mike Rother в книге "Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results" (2009) писал, что сообщество Lean при копировании японской системы менеджмента пропустило самую важную практику - кату совершенствования. Эта ката требует создания структуры для ежедневных и привычных практик улучшения. Первый черновик каты совершенствования моей организации написался в этом посте.

Есть самые разные способы делать деревья в таблицах. Чаще всего просто объединяют колонки или строки (помним, что любую таблицу ведь можно транспонировать!). В особо сложных случаях можно не полагаться на “визуальное представление”, а добавлять нумерацию “дерева” в какие-то колонки или строки, оставляя пустыми верхнеуровневые (для каждого уровня сделать свою колонку или строку) – 1., 2., 2.1., 2.2, 2.3., 2.3.1, 2.3.2, 3., 3.1, 3.2, 4., 5.

Думаю, что при заполнении таблицы у вас было много интересных мыслей о вашей организации )))
При этом если речь идёт о ситуационной мета-модели, то надо не “редкий в организации термин” писать из учебника менеджмента, а как у вас это называют. И если “никак не называют” – то поздравляю, вы нашли дырку в оргпроекте )))

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