Написать пост с моделированием системных уровней вашего основного рабочего мастерства, (за основу поста взято описание из разделов с примером социальных танцев).
“Инженер”
Опишу методы/культуры/стили и роли, используемые инженером, в области электросвязи (по старому) или telecom по новому.
Работа «связиста»/«организация связи»/::метод интересна тем, что существует как поддержка какой-то другой производственной или эксплуатационной деятельности (исключением будет работа в операторе связи, где бизнес процесс в организации каналов связи для другого бизнеса). При отсутствии связи вернёмся к пневмопочте и посыльным, заодно и голубей начнём использовать (Кстати пока почтовый голубь с флешкой в пару терабайт передаёт информацию быстрее чем провайдер). Метод этой работы исполняется инженерами::роль, в которой связист::«подроль инженера». В нашем случае инженер (с задействованной подролью связист) — это исполняющая метод организации связи подроль «члена сообщества поддерживающей инфраструктуры»::«человек дела»::человек, пример других подролей ролей людей-членов сообщества поддерживающей инфраструктуры — специалист информационной безопасности, администратор сети, инженер энергетик, инженер теплотехник, инженер по водоснабжению и водоотведению, инженер систем вентиляции и кондиционирования, инженер линейнокабельных сооружений. Повторимся: в этих сообществах не только инженеры, но и организаторы работ, метролог, специалист по охране труда, диспетчер. Коллективно выполняемый ими стиль/культура поведения сообщества этого стиля — субкультура, для сообщества всех инженеров — иногда говорят про эту культуру «субкультура», иногда и просто «культура», всё зависит от проекта, для которого ведётся моделирование/«присвоение типов для важных объектов предметной области». Себя инженеры::роль предпочитают называть «специалисты», но это характеризует их подготовку, мы увидим дальше, что «инженер» тут находится на довольно глубоком системном уровне, выше «инженера» ещё много самых разных ролей.
Системное мышление о сообществе поддерживающей инфраструктуры или даже отдельном инженере::роль сложней, чем системное мышление о каком-нибудь электронном гаджете. В it среде есть байка про то как к директору организации пришли два человека и затребовали повышение зарплаты, на вопрос кто вы такие сотрудники ответили: айтишник и безопасник. И рассказали чем занимаются. Директор был очень удивлён, как много эти два сотрудника делали и до этого не было повода узнать сотрудников лично (вызвать на ковёр). Так и проявляется хорошая работа саппорта её не заметно, потому что сам бизнес процесс протекает без помех. Однако отсутствие связи, как и электричества или воды и свежего воздуха конфортной температуры сразу остановит производство или резко сократит его эффективность.
Об инженерной культуре.
Система создания из групп инженеров может заниматься строительством или эксплуатацией. При приёмке в эксплуатацию созданной системы возникает здоровый конфликт интересов между “создателями” и будущими “эксплуататорами”. Практика показывает, что строить и эксплуатировать должны разные агенты. Это важное функциональное разделение инженеров в процессе применение методов.
Если взять организацию в целом, то зависимо от её вида деятельности: создание новый систем или эксплуатация существующих её оргзвенья будут состоять пропорционально из “создателей” и “эксплуататоров”. Если организация занимается эксплуатацией то в ней “строителей” мало и они выполняют роль текущего ремонта (на капитальный ремонт придётся привыкать подрядчика). При эксплуатации требуется много оперативного персонала хорошо знающего особенности в своей зоне ответственности и имеющие универсальные навыки. Строители наоборот берут числом, но с учётом узкой специализации. Оргзвено метрологов и специалистов по охране труда будет везде и заниматься одинаковыми задачами. Строительство финансово более выгодно, эксплуатация стабильней для исполнителей.
Если говорить про разделение на конструктивные части, то полтора землекопа это не наш метод. А функционально инженер при переходе из отдела развития в группу эксплуатации будет обращать внимание на совершенно разные вещи. Локальная шизофрения выраженная в конфликте интересов ролей у одного агента - это продукт оптимизации. Внутренние лебедь, рак и щука вынуждены предъявлять свои аргументы, в лучшем случае судьёй будет совесть. А про делему как лучше сделать по проекту или “как лучше” можно целое “хождение по мукам написать”.
Про уровни. Представим, что Коммерсант::роль, решает открыть дополнительный офис. Для подключения к головному офису необходимо обратиться к оператору связи и … Что же именно нужно заказать? Целевая система будет линия связи соответствующая требованиям к интерфейсу и полосе пропускания связывающая две точки (на схемах обычно облачко) Вот тут и попробуем выстроить модель. Была история на предприятии где раньше работал. Коммерсант имея личное знакомство с генеральным директором обратился к нему с просьбой организовать канал связи. На вопрос какую максимальную скорости можете предложить, гендир ответил, что любую. И тем самым попал в глупую ситуацию. Когда стало ясно, что выполнить такой запрос невозможно. Техническое задание от бизнеса в идеале формирует внутренняя it-служба::эксплуатация. Далее с внятным ТЗ можно обратиться к провайдеру. Провайдер в свою очередь будет выяснять у своей эксплуатации о наличии технической возможности подключения на существующей сети. Скорее-всего будет требоваться строительство линии доступа (провайдер строит сам) или организация “последней мили” за счёт другого провайдера (в городе где организуется новый офис нет присутствия провайдера). Тут у эксплуатации выявляется ещё одна роль. Постоянно поддерживать актуальную информацию о существующей сети для предоставления на верхний уровень для ускорения бизнес процессов. Если метод организации выбран (провайдер строит или через подрядчика), то далее через проектно изыскательные работы создаётся описание целевой системы::проект. Проекта - замечательная вещь его можно бесконечно пересылать по цепочке субподрядчиков) А вот инженерно техническое решение нельзя, только для внутреннего пользования в рамках предприятия. И проект (строит кто угодно) и ИТР (строит сам провайдер) должны пройти много итерации согласования как со со службой эксплуатации коммерсанта, так и со службой эксплуатации провайдера. В итоге получили рабочий проект и далее можно с ним обращаться к инженерам строителям. В процессе строительства осуществляется тех. надзор со стороны провайдера за подрядчиком который осуществляет строительство. Далее приёмка и подписание актов сначала провайдер - строитель, потом приёмка провайдер - клиент. В результате в проекте могут появиться изменения которые необходимо зафиксировать и эти данные станут отправной точкой для ведения новой эксплуатационной документации. И кругом одни инженеры)