Post #2143

Про техническую ясность In an organization, technical clarity is when non-technical decision makers have a good-enough practical understanding of what changes they can make to their software systems. Чем выше менеджер в корпоративной иерархии, тем меньше он разбирается в возможностях и ограничениях инженерных систем, поверх которых работает его продукт. При этом ему приходится ежедневно принимать решения, которые зависят от наличия у него в голове приближенной к правде ментальной модели того, как эта система работает. Как результат – из-за этой оторванности от реальности очень многие принимаемые решения плохие. Одна из ролей стафф-инженеров – обеспечивать эту самую техническую ясность для тех, кто принимает решения, отвечая на их вопросы, давая весь нужный контекст, и объясняя ограничения. У этой роли две сложности. Во-первых, часто сложно дать однозначный ответ на вопрос про огромную кодовую базу. Пока вы не возьметесь решать задачу, вы не можете быть на 100% уверены, что правильно оцениваете ее выполнимость. Во-вторых, менеджеры, далекие от кода, не могут быстро вместить себе в голову тот же уровень технических деталей, что и разработчик. Чтобы обеспечить им ясность, нужно хорошо уметь упрощать сложные концепции. Чтобы успешно обеспечивать техническую ясность, нужно обладать следующими качествами: 👉Хороший инженерный вкус. Он позволит вам понять, какие риски и контекст надо проговаривать, а какие можно опустить. 👉Глубокое техническое понимание системы, про которую идет речь. А оно берется только из постоянной работы с ней. 👉Достаточная уверенность в себе, чтобы рассказывать менеджерам упрощенную картину реальности. Пропуская детали, вы берете на себя риск дать неправильное суждение.