После выполнения заземления я заметил, что изначально воспринимал ситуацию слишком упрощённо — как проблему «отсутствия приоритизации». В процессе разбора стало понятно, что ситуация сложнее: механизм приоритизации в компании, вероятно, существует, но он недостаточно прозрачен для участников процесса и частично опирается на неформальные договорённости, коммуникацию и управленческие обсуждения.
Заземление помогло мне отделить:
-
наблюдения;
-
интерпретации;
-
и предположения о причинах происходящего.
Например, изначально у меня была тенденция делать слишком сильные выводы:
«приоритизации нет» или «задачи проталкиваются только через давление».
После заземления формулировка стала точнее:
-
есть формальная шкала приоритетов;
-
есть встречи с участием менеджеров продукта и технического директора, где принимаются решения;
-
но связь между формальным приоритетом и фактическим движением задач пока выглядит для меня недостаточно прозрачной.
Также заземление помогло увидеть реальные наблюдаемые эффекты:
-
задачи могут жить по 9 месяцев;
-
возвращаться в активное обсуждение;
-
но при этом не иметь понятного решения о запуске в работу;
-
большое количество задач имеют высокие приоритеты одновременно;
-
низкие приоритеты практически не встречаются в активной работе.
Это позволило сформулировать более аккуратную рабочую гипотезу:
возможно, система постепенно теряет способность различать реальную срочность задач, из-за чего часть координации смещается в сторону коммуникации и локальных договорённостей.
При этом заземление помогло не только уточнить описание проблемы, но и снизить риск ложных выводов. Например, я понял, что пока рано утверждать:
-
что система «сломана»;
-
что приоритизации нет;
-
или что проблема связана с конкретными людьми.
Наоборот, стало видно, что сначала нужно:
-
дольше наблюдать за движением задач;
-
понять реальные механизмы принятия решений;
-
посмотреть, как меняются приоритеты со временем;
-
и только потом делать выводы о качестве самой системы.
Также заземление помогло лучше понять, куда именно стоит смотреть дальше:
-
как устроена очередь задач;
-
как принимаются решения о запуске задач в работу;
-
как связаны формальный приоритет и фактическое движение;
-
где возникают задержки;
-
и кто реально принимает решения в системе.
На данный момент мне кажется, что «радар ошибок» сработал не вхолостую, потому что наблюдаются реальные сигналы:
-
длительное ожидание задач;
-
размывание шкалы приоритетов;
-
высокая зависимость движения задач от коммуникации.
Но одновременно заземление помогло удержаться от преждевременного вывода, будто я уже понял всю систему после первых наблюдений.