Краткая рабочая памятка по работе системного инженера

Сообщество
1

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

1 # Рабочие модели, которые системный инженер составляет и использует обязательно в проекте:

  1. Концепция (использования) целевой в эксплуатации
      1. (там же) Системные уровни в эксплуатации - надсистема и системы в окружении
  2. Табличка с интересами и предпочтениями(внешние роли у целевой)
  3. Граф создателей
    2.1. Табличка “кто был на последнем совещании”(интересы ролей в команде проекта).
  4. Табличка методологии (с альфами с их состояниями целевой) с описаниями методов, чек-листов.

Эти модели больше относятся уже к реализации изменений в специализациях:
6. Табличка “Распожаризации” — для фильтрации неполезных, второстепенных или не влияющих на целевую работ, а также для пересмотра методов.
7. Табличка “Какие изменения вы произвели в рабочем проекте за неделю” — для отслеживания изменений в раочем проекте или их отсутствия.

2 # Верхнеуровневое описание цикла шагов:

  1. Найти целевую систему в эксплуатации.
  2. Описать один реальный экземпляр и одну ситуацию эксплуатации.
  3. Выписать внешние роли и их интересы.
  4. Выбрать и подтвердить 3–5 важных характеристик для улучшения (индикаторизация).
  5. Проверить текущие задачи/инициативы через фильтр пользы.
  6. Убрать или отложить то, что не влияет на целевую.
  7. Выпустить маленькие изменения. Моделирования недостаточно. Переходим в специализацию:
    1. Выбираем от потребностей нужные изменения (small-batch changes) - что меняем.
    2. Выбираем метод и предметную роль производящие эти изменения - как меняем.
    3. Планируем работы и ресурсы(разные): кто будет делать, когда, чем - чем меняем.
      1. Надзираем выполнение работ.
    4. Выполнить и повторить цикл маленького изменения.
  8. Получить обратную связь.
  9. Уточнить модель и повторить цикл.

(возможны прыжки по шагам)

3 # Notes по циклу и принципам в шагах:

  • Viewpoint/Угол зрения (ваши Запросы к моделям): ускоряет, полезно явно формулировать – какой у вас запрос к модели, что вы хотите от нее получить, заметить, проследить и увидеть, сделать. Частая ошибка(у меня), стараться все в одной модели-табличке учесть и впихнуть. Это оказалось сильно непродуктивно как в составлении так и в использовании. Гига-модель-табличка начинает замедлять работу по фронтам проекта, а огромной такой пользы не несет. Придется разрезать для разных своих, чужиех запросов к модели саму модель, составлять вариации, а для этого нужно будет явно выписывать запросы, вьюпоинты/углы зрения под которыми будете смотреть на модель (что в ней искать будете).
  • Экземпляр: заполняем рабочие модели строго описаниями экземпляров - начиная с ситуации эксплуатации (включая и терминологию команды, предметной области, поэтому адаптируем, чтоб мог обсуждать с командой и проверять модель) - пример.
  • Целевая в эксплуатации: всегда начинаем с поиска целевой - все рассуждения по проектам, инициатива, делам далее будут вестись у системного инженера относительно ее – это фильтр и для распожаризации, как для личных, так и для всей цепочки, как по всем системам создания, так и по методам в целом.
    • Зачем? Учесть интересы внешних ролей: чтоб найти предметы интересов/важные характеристики внешних ролей, сами роли для успеха, агентов которые их проявляют, для которых вся цепочка создания и существует по этой линии. А экземплярно рассматриваем, чтоб во-первых заземлить до реальной жизни и изменений в мире, во-вторых сузить обсуждение, тем самым сэкономить и получить нужное рассуждение быстро.
    • Опора на интересы внешних ролей. Дальнейшие рассуждения будут опираться на “фильтр” вопрос «насколько цепочка создания и планируемые работы, инициативы удовлетворяют интересы внешних ролей целевой, то есть несут или принесут пользу целевой?». Всё непомогающее, неполезное, не меняющее в нужную сторону по важным характеристикам целевой пересматривается, по возможности увольняется/удаляется: как планы, так и то, что уже реализовано – ресурсы не тратим на то, что не влияет на успешность. Поэтому важно начинать именно с целевой.
      • Индикаторизировать. Выбрать 3-5 важных характеристик, которые решили оптимизировать, улучшать (согласовать, договорить всех). Под индикаторами имеем ввиду те характеристики, которые выбрали для оптимизации, остальные 95% датчики, показатели, просто мониторим их пост-фактум, пишем тесты под них максимум.
  • Как работать и использовать рабочие таблички/модели в роли системного инженера. Пару рекомендаций себе по методу работы:
    • Помним про small-batch size и бесконечное развитие, которое происходит на разных уровнях одновременно: попытки делать “великий, полный и истинный проход” по поиску целевой оказываются непродуктивными, могут занять много времени и мало сдвинуть дело в нужную сторону, так же и попытки делать гига-модель для всех viewpoint-ов в проекте отвечающие на все предметы интересов тоже дают мало пользы. Поэтому:
      • Начинать всегда с целевой “черного”, сразу с черновым идти проверять на предмет точности по пониманию важных характеристик по внешним ролям. Рассматривать всегда экземпляр 1 целевой за раз и конкретно ситуации одну ситуацию эксплуатации, вплоть до указания временного отрезка.
      • Эксплуатации целевой: пример эксплуатации желательно взятть из реальной жизни, ситуации, назвать все реальные имена, дать точные таймлайны (4д).
      • Выписать свои вьюпоинты в проекте (включая и вьюпоинт системного инженера, у которого предполагаю основной интерес этой успешность проекта, то есть степень удовлетворенности интересов внешних ролей, максимизации пользы по важным характеристикам внешних ролей целевой/вым, надсистемы/ам. Учитывать, что интерес системного инженера может не совпадать с интересами других ролей, поэтому иногда может удовлетворение интересов одной из ролей в системе создания может оказаться не приоритетным, а значит и не стоящим внимания, каких-либо изменений. Если игнорировать нельзя, стоит постараться направить агента в сторону целевой.)
      • Брать и делать: идти дальше описаний в специализацию и изменения: инжерию предметную. Иначе есть вероятность впасть в апатию и параличь от одних только моделей без синтеза(произведения изменений в проекте), где моделирование начинает казаться бесконечной подготовкой и больше подбирательству к делу чем деланию.
      • то, что берется и делается - проекты, инициативы, идеи/гипотезы, методы, текущие работы свои или команды и всё остальное существующее по проектам фильтровать относительно полезности к рассматриваевой целевой.
        • тут важный принцип: «не сделать все на 5+, а сделать хоть на 3-, но не продолбать что-то важное, чтоб не провалить проект, то есть основной фокус на том, чтоб не упустить важного в проекте, а не сделать его “идеально”». Этот принцип так же повышает скорость выпуска, получение обратной связи и результатов по изменениям (release/change often).
      • small-batch size release & evolution: не пытаемся сразу охватить все аспекты моделей, только самое важное.
        • Развиваем по наиболее подходящим местам развития, которую дадут выхлоп относительно целевой.
        • Выпускаем “кусочки” моделей быстрыми версиями на обратную связь команды для изменений, но всегда с оглядкой на целевую (следим чтоб не изменилась еще у внешних ролей - помним про “система в глазах смотрящего” и непрерывность изменений - целевые меняются со временем так же), без попытки охватить все и сразу, работаем непрерывно по интересующим областям в первую очередь - относительно важных характеристик целевой.
        • Не ожидаем что идеально с первого раза всегда получится произвести все изменения, да и времени не дадут столько + непродуктивно будет, поэтому кусочками придется уточнятся. Синтезом - сделал задачу, получил доверие, пошел еще в пользу что-то сделал, сделал задачу, изменил что-то, получил доверие, пошел еще что-то сделал и тд.
          • там уточняемся по важным характеристикам, вьюпоинтам. Чтоб не попасть в ступор и придерживаться small-batch delivery, разбирать 1 вьюпоинт интерес за раз в модели.
  • Специализация, синтез: одного моделирования системного инженера недостаточно для изменений, нужно будет пойти и производить изменения уже предметными методами, или повышается шанс того, что уволят, потому что не заметят толка от того, что “системный такой у нас”, не будут понимать, за что платят.
    • …
    • Инженерия мастерства: обучение, пропитка и пр.
      • Распожаризация. Не занимаемся лишним обучением, фильтруем на предмет пользы к целевой регулярно.
      • Пропитка, обучение команды проекта. Если польза выражается в совершении нужной пропитки, то опираемся на текущие вьюпоинты команды. В работах по оргимзенениями - учитываем вьюпоинты и интересы в проектах, на основе этого и строим рабочие модели, описания отвечающие на интересы ролей но и помогающие направлять(не упускать) внимание на интересы внешних ролей. При надобности описания разрезаем на разные способы описания модели для разных ролей и интересов, но обязательно адаптируем под ситуацию. Это заметка касается пропитки(обучения) и орг.изменений.

        • Чему обучаем. Определяем новые вьюпоинты (как методолог и культуртрегер), то есть содержание нужного мастерства и роли, чтоб восстановить разговор( Telegram: View @selfdiscipline ) о нужном, чтоб сдвинуть дело с мертвой точки.
          *

        • Как готовим обучение. Подбираем более близкие и заразительные метафоры и разговариваем про формат обучения как методисты.

          • Новодим “мосты” для преодолевания понятийных расстояний: находим ближайшие вьюпоинты команды, интересы их.
          • Описываем текущие вьюпоинты команды и те, которым хотим научить. Выписываем основные вьюпоинты по одному: какие есть, каких нехватает для выполнения нужного мастерства. При разработке материалов, описаний, коммуникаций учитываем эти вьюпоинты и интересы, те вьюпоинты, которым хотим научить, пропитать, связываем.закладываем в модели, таблички, операционные системы с уже знакомыми вьюпоинтами и новые – дополняем угол зрения на основе текущего понимания.

        • Как обучаем: обучаем новым вьюпоинтам как преподаватели-лидеры, мотивируя, объясняя пользы для агентов через объяснение, и как предметники тренируя содержательное, распознование нужного в разговоре в контекстах через заполнение, обсуждение табличек, выполнение совместных работ и пр. (Открытые вопросы: а как лучшим образом “восстанавливать разговор” о нужном ( Telegram: View @selfdiscipline )? через таблички и встройки содержаний в операционные моделеры? что насчет докладов, обучений? преподавания)

          • Если надо отдельно обсуждаем какие вьюпоинты сейчас наиболее полезны будут, чтоб проект сдвинуть в нужную сторону(учитывая и движения в целевой) - “Первый класс проблем – это проблемы с выбором точки зрения/viewpoint: требуется явно управлять выбором точки зрения, из которой вы (и ваши собеседники) будете смотреть на ситуацию….Точку зрения на предприятие и на конкретную ситуацию в вашем проекте (те в конкретном контексте) надо выбирать явно. На английском эта практика называется viewpoint governance.” https://t.me/selfdiscipline/154
    • Инженерия специализированная(предметка) с нормативами системной инженерии
      • Распожаризация. Не занимаемся лишней инженерией, фильтруем на предмет пользы к целевой регулярно.
      • по архитектурным решениям хорошо б концепцию использования иметь, интересы и АДР иметь
      • обращаем внимание на метод инженерии, перебираем метод до lean регулярно
      • там если про целевую подтвердили, то думать об ускорению выпуска.
      • … быть готовым к любой специализации по потребности для сдвига проекта
    • Инженерия предприятий (менеджмент) с нормативами системного менеджмента
      • Распожаризация. Не занимаемся лишней инженерией оргвозможностей, фильтруем на предмет пользы к целевой регулярно.
      • там если про целевую подтвердили, то думать об ускорению выпуска.
      • … быть готовым к любой специализации по потребности для сдвига проекта
  • Не ожидаем “пункта назначения”, то есть конца работ. Тут только бесконечное развитие. Осознанно можно опираться на ограничивающие факторы/лимиты по отношению к целевой: при успешном снятии одних факторов можно двигаться к поиску и решению следующих, но только после того как хорошо убедились, что в целевую это несет пользу, включая этические вопросы.

private notes in coda