Обсуждения — важная часть системного мышления

Дисклеймер


Этот пост написан потому что в конце первой главы сисмыша есть задание которое нужно отметить галкой о выполнении "Написан и опубликован первый пост по теме первого раздела «Системного мышления» Что пришло в голову по поводу материала раздела? Что было контринтуитивным? Что удалось сразу применить на работе? Не на работе?". Совесть не позволяет отметить галкой и не выполнить, поэтому пишу этот пост и попутно отвечаю на поставленные в задании вопросы.


Кто я и чем занимаюсь


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


Мой проект - ITSM портал


В ответ на требования внешних аудиторов - иметь оформленную и подтвержденную руководителем заявку на доступ в какую-либо информационную систему, более года назад в компании появился ITSM-портал на основе Jira, где сотрудники могут отправить запрос на доступ к той или иной системе, он попадет на одобрение к руководителю, и далее доступ будет выдан администратором. Портал развивался и сейчас раздел с доступами один из 8 подразделов портала.
# Один из подразделов - Change request
Мы называем Change request - любой запрос на изменение какой-либо из существующих систем, исключая запросы на создание доступов и новых учетных записей в этой системе. Такими запросами могут быть изменения настроек системы, связь ее с другими системами и т.д. Вариантов много, поэтому форма запроса в данном случае - большое текстовое поле, где заказчик максимально подробно может описать свои хотелки.
В процессе чтения главы вычитал мысль, что системное мышление - это постоянные обсуждения и договоренности со всеми заинтересованными сторонами проекта. Change request - это чаще всего какой-то проект. Мини или макро проект. И мы можем улучшить начальную постановку задачи добавив к ней обсуждения, т.к. часто заказчик не всегда знает, что он хочет или как это лучше сделать.

Идея в том, чтобы в change request помимо текстового описания добавить возможность забронировать встречу с системным администратором для обсуждения задачи. На обсуждении уже сформулировать задачу точнее.

Может быть предложить обходные пути или рассказывать про существующие способы решения задачи. Сисадмин всегда знает больше о всех системах и их взаимосвязях.

Результаты встречи зафиксировать в заявке. Заявку в бэклог и потом в работу.

Еще одна мысль которая пришла, в начале написания поста - вышла из формулировки задания: "Написан и опубликован первый пост по теме первого раздела". Такая формулировка не дает пройти мимо и поставить галку/согласиться не выполнив написаное.
Мы пока не используем чек-листы в таком виде при выполнении рабочих задач, но я возьму это на заметку при составлении чек-листов для пользователей.

Оригинал в моем блоге https://yetanother.ru/discuss_and_system_thinking

«Написан и опубликован первый пост по теме первого раздела». Такая формулировка не дает пройти мимо и поставить галку/согласиться не выполнив написаное.
Мы пока не используем чек-листы в таком виде при выполнении рабочих задач, но я возьму это на заметку при составлении чек-листов для пользователей.

– Мне тоже это понравилось) Такой интересный манипулятивный прием. Если бы было в инфинитиве, галку поставить было бы проще: ну ок, принял к сведению, что надо написать и опубликовать первый пост… А так – не отвертишься) Пост или опубликован, или нет. Отличный прием.

1 лайк

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