Кроме «что», надо «как»: тактическое руководство
Разбираем сейчас интересный кейс по поводу программных документов.
Обрабатываем грабельку — которую надо бы записать, пригодится, она частая.
Проблема-то следующая: документы «слишком общие». То есть, у нас есть (уже есть) достаточно неплохие и даже неглупые штуки, где-то записанные. И даже уже внедренные в процессы.
Но присутствует беда: написанное напоминает неподготовленному человеку воду из общих слов. Как в анекдоте, «мыши, станьте ежами» аналогично «я не тактик, я стратег».
Вот у тебя написано, как красиво всё работает, когда всё делается как надо. Кто бы сомневался.
Потом у тебя в руках появляется какая-то жопа, которую тебе перекинули коллеги или принесло жизнью, и всё, что ты можешь сказать — ну, это жопа. Гарантирую, я ее узнал.
Очень было бы прикольно, когда всё красиво и правильно. А пока что вот тут — ну ни разу не красиво, и не похоже на правильно. И скорее всего не станет, без мата и пластыря. Сроки горят, все в истерике, швабра держит потолок, ну и так далее.
И скорее всего, всё последующее пойдет не по красивому процессному flow, а как-то враскоряку костылями и подпорками. Как обычно, а не как надо бы. Потом посмотрим на документы и вcплакнем на ревью, опять получим леща и скажем «ну, ни шмогла, такая ситуация, понимать надо».
В чем тут беда: стратегию описали, тактику забыли.
Во-первых, вы удивитесь, но если программные документы надо применять (это называется «функциональный документ») — это значит, в нем явно должно быть написано, что его надо применять. Когда, кем и как.
— если ты, Вася, видишь что реальность сильно отличается от правильного хода вещей — при первой возможности приложи пожалуйста усилия,
и либо приведи работу к надлежащему виду,
либо опиши для данной конкретной ситуации, что и почему у нас идет настолько не так, что применять «правильное и согласованное» мы здесь не можем (или не хотим).
Как минимум для того, чтобы правила игры в данной ее конкретной части и ситуации были далее прозрачны и понятно для кого-то, кроме Васи — например, для менеджмента, который будет в какой-то момент рвать волосы в сложных местах в попытке найти концы и сроки.
Для стратегических доков в их высшей части (повторюсь) неплохо выделить блок проблематики, «а нахера мы это делаем вообще». Обычно ответ — чтобы получить предсказуемость работы соседних коллег, синхронизировать ожидания, тиражировать полезный опыт. Сэкономить время на разруливание и на понимание modus operandi внутри команд и групп.
Сила волка, как говорят, не в клыках — а в стае; каждый вправе ожидать, что действия соседа будут подчиняться общей логике (прописанной), а значит на этом можно выиграть коммуникацию и ситуацию целиком.
Во-вторых, неплохо бы вспомнить и прописать, что если что-то в какой-то части идет не так — оно имеет право так делать. В различных ситуациях (каких?). Если у вас пожар, то логично сначала найти себе в руки огнетушитель, а только потом идти вызванивать команду реагирования.
Что здесь важно: составные части. Положение о том, что если «всё пошло по звезде», то это не значит, что в этот момент мы забыли всё, что согласовывали для нормальной работы. Нарушение одной части плана никак не отменяет другие.
- Если в данном контексте у нас сроки = вчера, планирование = подорвались и побежали, то регламент по передаче ответственности и интеграции (например) все еще остается в силе.
- Если мы не можем нормально провести research и у нас пол-отдела занимается «поиском в материале» ответа на вопрос «как эта херня вообще может работать?», то регламент по синхронизации сроков и правила командной работы никто не отменял.
Видел хорошую рабочую концепцию master overrides. Когда «мастерским произволом» для выбранного проекта и/ли конкретных задач ответственные лица (руководители, интеграторы, c-level, заказчики) явно прописывают: вот здесь, для этого конкретного случая или пачки, мы можем вот такие правила регламентов игнорировать (и следом написано, почему).
Право на мастерский произвол точно так же прописывается в списке процессных прав (см. «право на да, нет, и я так хочу»), а для особо частых случаев даже в самом flow.
Очевидно, что override, в смысле «исключение», должен быть именно исключением из правил; если у вас каждый второй случай = исключение, то нет, это так не работает. Но уже какая-то точка старта (можно задать вопросы «а почему у нас так?»).
В-третьих, если мы знаем чисто статистически, что у нас чаще всего «может пойти не так», неплохо бы написать тактические подсказки. Что конкретному человеку делать правильно, и к кому с этим пойти. Нет нормального технического задания — не иди гайки крутить (хер знает что накрутишь), а выдели исследование или поставь задачу «выяснить». Требуют костыль-вчера — окей, предложи следом нормальное решение, чтобы когда/если жопа перестанет гореть, кто-то взял его в работу уже в нормальном процессе.
Чтобы базовые документы не распухали, окей, вынеси описанное в отдельный блок best practices. Распухшая дока становится проблемой только тогда, когда ее никто не читает; иногда достаточно простого указания «сломал? читать здесь». Как инструкция к микроволновке (которую читают только тогда, когда сломано).
В-четвертых, иногда полезно явно указать людям, даже в документе или в best practices, что в сложной ситуации надо остановиться и подумать. Удивительно, насколько об этом люди забывают — или забивают. Жопа-то горит, что тут думать, прыгать надо(ц). Как вы будете эту ситуацию обрабатывать, и кем. Например, зондеркоманда service response бежит затыкать дырки, а все остальные не болеют за них и подбадривают криками с трибун, а прорабатывают нормальное решение, конкретными ответственными людьми, чтобы такая херня больше не повторилась.
Самые частые вопросы, о которых обычно следует вовремя подумать (если жопа) — как ситуацию локализовать, как поставить за нее ответственных, кого она затрагивает (а кого нет, как их ограничить), и где из жопы выход (спойлер: там, где вход) и как его найти в том или ином случае.
Короче говоря, не забывайте про тактическую часть.
Кроме «что», должно быть понятно, «как». И кем.
Иногда тактическое-ситуативное реагирование отдается «на откуп исполнителей», но знаете, это так себе практика.
Витя-слесарь с 20 годами опыта понятно, что сложную ситуацию разрулит чисто на опыте и знании материала. А вот кто-то другой уже не разрулит, у вас bus-factor в лице слесаря и опять кусок проектного знания сконцентрирован в отдельно взятой голове.
От такого лучше уходить, это полезнее.
Бывает так, что документ вовсе не функциональный (хотя имхо, зря такие плодить). Например, общий vision. Ему функциональная часть «как» — вроде и не нужна. Зато она нужна другим документам, в которых функциональный и тактический блок будет опираться уже на общий vision и его аналоги.
Если общая часть предполагает общее понимание «мы не работаем, как мудаки» — то в других документах написано, что и конкретно следует сделать в той или иной ситуации, чтобы не быть мудаком (для себя или для всех остальных).
UPD: а еще прописанные и работающие тактические правила снижают операционные риски («мы знаем, как у нас всё работает, и сами работаем именно так»). Вместе со снижением рисков идет повышение доверия; внутри системы, команды, взаимодействующих частей.
Это как раз тот случай, где взаимосвязь рисков и доверия — из описанных мной заметок про доверие (раз, два) — применяется не в умозрительной связи, а в самой что ни есть прямой. Прикольный пример. Спасибо за уточнение, кст.