Внутренние инструменты как форма власти
То, чем команда пользуется каждый день, честнее рассказывает о компании, чем ее продукт.
Продукт компании — ее парадный фасад. Отполированный, продуманный, он рассказывает ту историю, которую компания хочет рассказать о себе. Внутренние инструменты живут по другую сторону: админки, дашборды, системы доступа, тулинг для сборки и выкатки. Их не показывают на конференциях, про них не пишут в блоге. И по ним обычно видно больше.
Инструмент показывает структуру
Хотите понять, как устроена компания? Оргсхема скажет мало. Посмотрите на внутренние инструменты. Кто может нажать какую кнопку. Что делается в один клик, а что требует трех согласований и тикета. Что пишется в лог, а что проходит бесследно. Инструмент — это застывшее решение о том, кому здесь доверяют и какое поведение считают нормальным. Он честен по скучной причине: его делали не для того, чтобы производить впечатление, поэтому в нем никто не сглаживал углы.
Власть, встроенная в интерфейс
Во внутреннем инструменте власть перестает быть абстракцией. Это поле, которое одни редактируют, а другие только видят. Фича-флаг, открытый команде роста и закрытый поддержке. Лог, который фиксирует, кто поменял лимит, и молчит о том, кто его посмотрел.
Пару лет назад я вел нашу платформу фича-флагов на базе Unleash. По задумке флаг — вещь временная: включили эксперимент, собрали метрики, выключили. На деле у нас был флаг, простоявший включенным почти год. Его завели под раскатку одной функции на узкий сегмент, функцию потом выкатили на всех, а флаг убрать забыли. Он висел в проде как аппендикс, вроде бы ничего не делал. Пока однажды джун, разбираясь с чужим кодом, не дернул его обратно, и часть пользователей на несколько часов потеряла экран, которым уже год пользовалась. Разбор был коротким. Виноват был не джун. Виновата была система, где боевой тумблер выглядел ровно как безопасный, стоял с ним в одном списке и не требовал ни подтверждения, ни строчки о том, зачем ты вообще его трогаешь.
Каждое из тех решений — не помечать боевые флаги, не просить подтверждения, не хранить, кто и зачем создал флаг — принималось походя, между делом, как техническая мелочь. В сумме они и были нашей настоящей политикой доступа.
Регламент лежал в Confluence, а реальные правила доступа жили в списке флагов, который никто не считал документом.
«Но это же просто плохой тулинг»
Здесь легко возразить, и я сам себе это возражаю. Все описанное звучит как обычная инженерная неряшливость. Не пометили флаг, не поставили подтверждения — так это недоделка. При чем тут власть и конституция организации. Почини бэклог, добавь ролевую модель, и красивое морализаторство отвалится само.
Отчасти так. Много уродства во внутренних инструментах объясняется банально: не было времени, не дошли руки. Но выбор, до чего руки доходят, а до чего нет, сам по себе показателен. Мы полгода вылизывали клиентское приложение, где каждый пиксель проходил ревью, и одновременно терпели админку, в которой оператор поддержки менял статус чужой заявки без единой записи в истории. За этим стоит иерархия: чьи ошибки компания считает дорогими, а чьи — терпимыми. Плохой тулинг тоже кое-что утверждает, просто вслух этого никто не произносит.
Здесь я перестаю быть уверен
Я строил такие инструменты и видел, как тихо дизайн админки задает нормы. Сделай опасное действие требующим подтверждения — его начинают делать осторожнее. Спрячь кнопку экспорта в подменю — ею перестают пользоваться, даже когда она нужна по делу. Интерфейс воспитывает, и делает это молча.
И вот тут моя уверенность заканчивается. Та самая власть, которой я призываю распоряжаться ответственно, еще и приятна. Когда ты решаешь, что экспорт данных теперь идет через апрув, ты вроде бы заботишься о безопасности. А заодно тихо устраиваешь так, что без тебя (точнее, без твоей роли) теперь чуть меньше можно. В моменте я не всегда отличал одно от другого. Пару раз я добавлял «подтверждение опасного действия» туда, где мне на самом деле было просто спокойнее, если люди лишний раз спросят меня. Это удобно называть заботой. Заботой оно было не всегда.
Что с этим делать инженеру
Относиться к внутренним инструментам всерьез, в том числе политически. Спрашивать, работает ли это. И следом — какое поведение оно поощряет и кому дает власть. Проектировать доступы и логи как высказывания о доверии. Иногда это значит дать людям больше, чем тебе комфортно, и записать про них меньше, чем ты технически можешь.
Внутренний инструмент — то место, где инженер оказывается ближе всего к настоящей власти в компании. Обычно он этого не замечает, потому что власть тут выглядит как форма ввода и галочка «залогировать». Я до сих пор не уверен, что распоряжался ей хорошо. Но перестал делать вид, что ее нет.