Тут должна быть заметка по теме главы
Итак…
В компании менеджер формулирует запрос как умеет про то что ему нужен мониторинг работы сервиса подписок.
но на самом деле он хочет чтобы команда поддержки могла быстро узнать когда сервис лег, после этого выяснить причину падения и быстро восстановить работоспособность сервиса пока пользователи не заметили и компания не начала терять деньги и уважение и лояльность клиентов.
такая реакция на опережение или с минимальным запаздыванием не рождает дополнительные пожары которые надо дополнительно тушить.
что важно, что тот менеджер который принес задачу про мониторинг сервиса подписок не уточнил какую на самом деле проблему необходимо решать и какую роль тут играет мониторинг.
команда так же не прикладывает усилий к тому чтобы разобраться в ситуации и ответить на вопрос “зачем?” надо пилить такой функционал.
возникает негласный консенсус что все все поняли с полуслова и тут нечего обсуждать. (это очень жизненная ситуация). Менеджер не составляет описание (descrition in fpf) задачи. передает ее голосом (и, возможно, на бегу по телефону с плохой связью, перебегая с одного совещания на другое).
то что менеджер сообщил команде - это чистая эпистема/хотелка/намерение (intensional object in fpf)
инженеры запрос менеджера понимают так как понимают: “надо запилить царский дашборд на свежем фреймворке чтобы было красиво 4K 120FPS”. и метрики собирать для статистики.
как и кем это будет использоваться в реальной работе никто из инженеров не уточняет и даже не пытается (возможно, в этой компании задавать вопросы не принято или не прилично).
инженеры выкатывают свое решение в том виде как они его поняли.
теперь красивый дашборд красиво со спецэффектами показывает в 4K 120FPS как сервис падает. статистика собирается. уведомлений команда не получает. пожары разрастаются. в работе сервиса с точки зрения внешних пользователей/потребителей не изменилось.
никто в компании не знает кто из агентов в какой последовательности что должен делать за какое время при падении сервиса. все получили “капусту вместо яичницы” (с) за счет заведения.
на самом деле нужно было начать с заземления, чтобы все причастные получили “яичницу вместо капусты”.
должно было состояться конструктивное обсуждение какую именно проблему необходимо решить:
отсутствие информации о падении сервиса?
медленное восстановление сервиса после падения?
Неразбериха при выполнении агентами работ по методу восстановления работоспособности сервиса?
после прояснения содержания реальной проблемы можно начать договариваться какие агенты в каких ролях по каким сигналам какие работы по каким методам выполнят и как координируют свои действия и усилия. как проверять качество выполненных работ и как можно их ускорить если есть в этом необходимость и не исчерпаны возможности для ускорения. после проработки этих вопросов становится более очевидна функция системы мониторинга. кто ее будет как использовать и какие качества у нее должны быть реализованы и как их измерять.
Заземляться полезно в любой ситуации когда агенты начинают обсуждать рабочие моменты и решения задач.
Примерная схема заземления выглядит так:
- описываем физические объекты которые должны меняться в физическом мире после того как задача будет успешно решена. описываем с точки зрения какой роли будет рассматриваться ситуация. если так не получается сразу описать, можно попробовать двигаться от противного: описать что вас смущает в ситуации, что дребезжит, что не сходится или что не понятно, что ускользает в понимании ситуации с позиции выбранной точки зрения.
- определить в описании агентов, которые будут действовать иначе = выполнять работы по новому методу. новые работы/действия надо назвать и описать. описать результаты выполнения работ/действий - какие объекты для выбранной роли будут переведены в другие состояния, какие артефакты будут созданы. проверить, не забыли ли чего из п.1?
- описать каким способом будут измеряться изменения в окружающем мире. куда смотреть, что проверять чтобы убедиться что изменения произошли.
- описать при каких условиях результат можно получить, а при каких условиях результат недостижим.
- как быстро понять и по каким сигналам, что делается что-то не то?
после заземления искать места приложения усилий станет проще, но это все равно останется не такой простой задачей. для решения такой задачи есть разные методологии. одна их них - теория ограничений.
в примере с ленточными конвейерами для шахт, если менеджер хочет ускорить выпуск в 1.5 раза, ему необходимо найти оргзвено/рабочую станцию, работу которого необходимо ускорить чтобы получить такой рост скорости выпуска в масштабе всей организации.
теория ограничений говорит что такая станция одна. другие станции не окажут влияния на скорость выпуска в таком объеме.
заземление в этой ситуации необходимо для поиска нужного звена в реальной структуре производственного предприятия. на совещаниях могут обсуждаться разные текущие проблемы производства.
необходимо выполнить моделирование с использованием графа создателей/производственной цепочки. далее вычислить у какой рабочей станции время цикла/потоковое время самое длинное и ускоряем работу этой станции в 1.5 раза. далее производим замеры - на сколько увеличился выпуск. если целевого значения не достигнуто, то цикл моделирования и поиска рабочей станции с самым длинным потоковым временем (новое ограничение в организации) повторяем.
если в компании есть модель предприятия, собирается статистика по потоковому времени рабочих станций, и такой сбор ведется по единой методике (результаты измерений можно сравнивать без дополнительных конвертаций), то нужный результат можно можно получить быстро.
к этому еще необходимо выдать менеджеру полномочия для проведения изменений.
менеджеру необходимо будет отслеживать не только поведение скорости выпуска продукции (как его вмешательство и изменения влияют на этот показатель), но и контролировать как развиваются события внутри рабочей станции которая изменяется. как ведет себя команда из этой станции - сотрудничает, выполняет поручения или саботирует?
чем раньше он обнаружит, что что-то идет не так - выпуск не ускоряется, потоковое время не сокращается, команда не сотрудничает, затягивает выполнение поручений и тд., тем лучше.
если менеджер не заземлится, то скорее всего предпримет управленческие усилия не в самом нужном месте. увеличит скорость выпуска не в том подразделении, что не приведет к ускорению выпуска всего предприятия в целом. ресурсы будут потрачены, цели не достигнуты. работой будет завалено соседнее подразделение или работа подразделений откатится на работу в прежнем режиме. толку на выходе не получится.
как же происходит заземление?
формируется эпистема = хотелка без деталей. на простом бытовом языке. можно использовать метафоры. тк метафоры хорошо сжимают информацию при передаче. метафоры потребуют распаковки смыслов.
мы с детства осваиваем язык метафор.
формализация профессиональных языков происходит постепенно.
далее хотелка преобразуется в описание того что нужно сделать. от эпистемы происходит переход к описанию. оно должно быть отсылкой к конкретным объектам в мире, описанным с определенной точки зрения, в определенном ограниченном контексте, с возможностью проверки что это описание соответствует тем объектам которые оно описывает.
после того как описание получено, можно обсуждать с командой что необходимо сделать чтобы достичь результата описанного в описании.
бесполезно автоматизировать плохо настроенные процессы. сначала надо определить какие процессы надо автоматизировать, что является процессом в интересующем нас контексте, и готовы ли эти процессы к тому, чтобы подвергнуться автоматизации? не усугубит ли автоматизация накопленные проблемы в компании и не стоит ли сначала проработать процессы, а потом переходить к автоматизации.
в FPF заземление описывается кластером паттернов C.2.1, A.6.P
Такие дела.
спасибо за внимание.
время мышления письмом: (35+30+15) м.