Я люблю общаться в публичных каналах на работе.

В Купере (ex-СберМаркете) такой принцип общения был заложен задолго до моего прихода. На прошлом месте я потратил год, чтобы вынести общение из личек.

Какая ценность от этого? — Тет-а-тет проще слиться. Может есть что-то более интересное/важное, или ты не считаешь, что надо делать… Неважно... Этого же никто не увидит. А голосом, так вообще огонь: «сам дурак, понял не так»! 🤡

Но когда нам надо ответить в публичной плоскости текстом, то всё меняется! Мы дважды подумаем, прежде чем что-то написать. Мы же все хотим выглядеть отлично в глазах коллег/руководства? А в тред/чат может зайти любой из них 🤔

Ну вы поняли, почему я люблю публичные чатики. Да? 😏 Но это «мелкая бытовуха», есть и кое-что большее…

Последнее время в IT популяризируются Architectural Decision Records (ADR), Process Decision Record (PDR) и пр. Их идея в том, что до внесения архитектурного чэнджа в систему, автор обязан описать его в виде ADR в общем пространстве компании (может, и с ревью). Также и с процессами работы (PDR), хочешь поменять — опиши: что, почему, зачем, какие альтернативны смотрел и пр.

Что это даёт? 🗣️ Люди вынуждены объяснять, почему принимаются те или иные решения — в первую очередь менеджеры 🤔 Причём ещё и в письменной форме — в процессе описания происходит большее осмысление нюансов и улучшение решений 💎 Описание решения хранится в общем пространстве — подписываться под откровенной фигнёй никой не будет 🚀 Это выставляет крайне высокую планку ожиданий в части необходимости и обоснованности принимаемых решений, что повышает их качество 🤝🏻 Получаем прозрачную для всех дискуссию в части работы с возражениями

Если изменение полезное, то его можно легко описать и привнести на всех без длинных обсуждений. А если изменение «сомнительное», то инициатор: 1. либо не рискнёт подписаться публично своим именем под «откровенной фигнёй» и забьёт 2. либо не сможет обосновать, что надо делать именно так и… забьёт

Опять бюрократию развёл, скажете вы 😡 Но этот подход вскрывает несовершенства и неоптимальность ещё до того, как они повлияют — а исправлять архитектуру/процессы/т.п. дороговато.

Допом мы упрощаем ретроспективный анализ ошибок, ведь мотивация принятых решений зафиксирована (мы ведь blameless, да?). Также в масштабе это лучший способ обеспечить качество принимаемых решений с сохранением автономии команд.

И вот честно, как часто в вашей практике кто-то залетал с шашкой наперевес и складно стелил, что «прям капец как надо», «мамой клянусь!», «всё пропало, если не сделать», а потом вы это расхлёбывали? 😕

Да и мы все сами наверняка успели изрядно накосячить на своём пути. Нет людей, которые не ошибаются 💚

А вы используете что-то подобное в своей работе?

#менеджмент #решения #изменения #adr #pdr #процессы #архитектура