
Пост по итогам первого раздела "Практического системного мышления".
Есть ощущение, что ШСМ научила меня заземляться в коммуникациях. Речь, особенно письменная, стала содержать больше отсылок на физические объекты - системы, артефакты. Так то я всегда был склонен уходить в абстракции, по двум точкам выстраивать картину мира, и действовать, воображая, что все окружающие уже в том мире и понимают, о чем идет речь. Нет, не понимают.
Но сейчас чаще удерживаю фокус, помню роли, в которых находятся отправитель и получатель информации. Тем заметнее ошибки, которые совершаю.
Описываю пример из рабочей переписки, где я наделал ошибок. Близко к тексту, только убираю имена и заменяю имена систем.
- Функциональный менеджер спрашивает мое мнение об отправке инженеров на обучающие курсы по системам мониторинга и поддержки экипажа семейства HAL. У нас бывают проекты по установке таких систем для внешних клиентов. (Кстати, какая у него роль в этот момент ... операционный менеджер? И у меня тоже такая же? Видимо, так).
2. Пишу письмо в ответ:
Я «за» - при условии, что в течение трех месяцев после курсов инженера создадут пакет проектных документов, описывающих HAL 9000.
Хотя бы FDS, BoM, включая лицензии, и блок-диаграмму.
Также нам доступен софт HALO. Надо его просто заказать и накатить (на продакшн сеть, ага).
Я понимаю, что один курс не даст всех знаний, но ожидаю, что хотя бы составят дорожную карту и начнут по ней двигаться.
2. Менеджер показывает ответ одного из инженеров, которым он отправил мои формулировки:
Хотелось бы уточнить,
FDS – что это за диаграм схемы ?
BoM- это применимо к HALO?
включая лицензии – где их брать ?
будет ли у нас доступ к продакшн ? наверное да
Давайте начнем хотя-бы от чего-то отталкиваться ?
Чем нам грозит срыв трехмесячных планов?
Стоп-кадр. Разбираю свои ошибки. Давайте начнем хотя бы от чего-то отталкиваться, в самом деле.
- Не связал в тексте обучающие курсы и целевую систему. Был уверен, что прямой адресат, менеджер, меня поймет - с ним то были обсуждения проблемы ранее, контекст уже существует. Он и понял, но на следующем шаге такого контекста уже не было и смысл потерялся.
- Не пояснил термины.
- Проблема уровнем выше - нет базы знаний с образцами документов.
- Не сослался на номер проекта, описание системы, его визионера, архитектора.
- Проблема уровнем выше - не продуман онбординг инженеров в запущенные проекты.
- Не описал, как и какие полномочия будут у инженеров.
- Не описал цель. Чтобы что?
Хорошо, что речь идет о развитии собственной платформы, и приоритет у кейса не самый высокий. Но ведь точно такие же ошибки можем делать, и делаем, на внешних, важных проектах.
No pain - no gain. После такого письменного разбора стало немного понятнее, куда расти. Причем и в краткосрочной перспективе, и в долгую, меняя организацию.
Пробую теперь переформулировать свое письмо:
Я «за». Условие: после курсов создать пакет документации, описывающих HAL 9000.
Текущая ситуация с системой:- HAL 9000 в настоящий момент обеспечивает безопасность и комфорта экипажа нашего корабля Discovery One, обнаруживая и исправляя проблемы, которые могут возникнуть на корабле. В целом нареканий к системе нет. Резервирование системы сущствует только для критических компонентов, например, блоков питания оборудования и жестких дисков серверов.
- владелец системы - Дэйв Боумен. Ставлю его в копию переписки.
- вся документация находится в папке проекта (ссылка)
- проблема в том, что система разворачивалась и работает без проектной документации и описания.
План такой:
- до курсов смотрите документацию в проектной папке, обсуждаете с Дэйвом текущую ситуацию и проблемы. Зачем: чтобы поймать моменты и сфокусировать внимание, когда аналогичные проблемы и пути их решения будут упоминаться на курсах.
- как возвращаетесь, садимся с вами и Дэйвом и обсуждаем план работ. Минимальный набор: FDS (ссылка на образец документа), BoM, включая лицензии (еще ссылка), и блок-диаграмма (и еще ссылка). Также доступен для установки софт HALO как дополнение к HAL 9000. Его функция: дает возможность распознавать лица членов экипажа и общаться с ними голосом. Надо будет составить план его развертывания и тестирования, чтобы не сломать продакшн.
- затем каждый месяц синхронизируемся, метод по ситуации, но лучше асинхронно, в почте.
- хорошо бы закончить за три месяца, чтобы пометить задачу сделанной и заняться другими. Но так как задача с невысоким приоритетом, нормально, если срок увелится на месяц-два.