🧭 «Видеть, как софтверная компания»: почему эффективность — не то, что кажется

В мире технологий мы привыкли думать, что больше процессов, метрик и Jira-тикетов — значит лучше. Всё должно быть измеримо, прогнозируемо, отчётливо. Но, как показывает эссе Шона Гудеке «Seeing Like a Software Company», эта «читаемость» (legibility) в действительности часто делает компании медленнее и менее живыми.

🌳 От немецких лесов к Jira-бордам

Гудеке опирается на идеи Джеймса Скотта из книги «Seeing Like a State».
Когда немецкое государство XIX века захотело «управляемые» леса, оно вырубило подлесок и посадило деревья ровными рядами, чтобы инспекторы могли пересчитать их. Лес стал понятным — но больным.
🪵 Подлесок, сорняки и разнообразие видов, ранее казавшиеся хаосом, на деле поддерживали экосистему.

В мире IT-корпораций происходит то же самое. Мы создаём «ровные леса» из OKR, планов, SLA, Jira-тикетов и диаграмм Ганта. Это делает работу видимой для менеджеров, инвесторов и партнёров — но часто убивает её живую часть.

⚙️ Что такое «читаемая» и «нечитаемая» работа

🧩 Читаемая работа — это всё, что можно описать в таблице:

• ✅ задачи с дедлайнами;
• 🗂️ метрики производительности;
• 🧾 отчёты и план-ревью.

🌿 Нечитаемая работа — всё, что живёт между строк:

• 🤝 неформальные договорённости и личные связи;
• 💡 импровизация и быстрые решения без согласований;
• 🗣️ знания, которые никто не записывал, но все помнят.

Без нечитаемой работы ни один крупный проект не выживает. Именно она спасает компанию, когда процесс буксует, а «правильное» решение требует месяца согласований.

🧠 Почему крупные IT-компании выбирают читаемость

📊 Всё просто: читаемость — это не про эффективность, а про контроль и доверие.

Крупные заказчики (особенно B2B и Enterprise) хотят знать, что именно они купили и когда это будет готово. А для этого им нужна отчётность.
Поэтому компании вроде Salesforce, Atlassian или Microsoft жертвуют гибкостью ради предсказуемости.

🧱 Читаемость позволяет:

• 💼 подписывать многомиллионные контракты, потому что «всё под контролем»;
• 📅 планировать фичи на кварталы вперёд;
• 🧩 быть понятными для других крупных корпораций.

А вот маленький стартап, в котором CTO сидит рядом с дизайнером и решает задачу за 10 минут — это противоположность читабельности. Он хаотичен, но эффективен.

🔥 Зоны «разрешённого хаоса»

Когда процесс становится слишком медленным, компании создают временные островки нечитаемости — например:

• 🐅 tiger teams (ударные группы),
• 🚑 strike teams для устранения критических багов,
• 🧪 внутренние «skunkworks» — небольшие лаборатории, работающие в обход бюрократии.

Такие команды действуют без менеджеров и отчётов, но с максимальным доверием.
Они часто спасают продукт, но не могут существовать вечно: система снова «впитывает» их и возвращает в читаемое русло.

🕸️ Теневая сеть инженеров

В любой крупной организации есть неформальные каналы — Slack-чаты, личные сообщения, дружеские созвоны.
🧑‍💻 Один инженер пишет другому: «Можешь внести правку напрямую? Это займёт минуту».
И правка попадает в продакшн через сутки, а не через полтора месяца бюрократии.

Эта сеть недокументирована, но она — несущая конструкция любой технокорпорации.
Без неё процессы бы просто коллапсировали.

🎭 Люди в системе: «социопаты», «наивные» и «аутентичные»

Гудеке цитирует Венкатеша Рао и его знаменитый текст The Gervais Principle, где корпоративный мир делится на три типа:

• 🦊 Социопаты — манипулируют правилами ради выгоды.
• 📘 Наивные (clueless) — свято верят в правила и KPI.
• ☕ Аутентичные («losers») — понимают игру, но не хотят играть.

Все три категории нужны, потому что каждая отражает баланс между читаемостью и нечитаемостью.
Именно на их стыке рождается реальная продуктивность.

🧭 Моё мнение

Как разработчик, я вижу, что читаемость — это форма защиты от хаоса, но и форма самоограничения.
Компании хотят превратить живой творческий процесс в управляемый механизм, но софт — это не сборка машин, а форма диалога между людьми.

✨ Настоящий прогресс рождается там, где инженеры смело нарушают формальные правила, но делают это ответственно.
Лучшие решения — результат гибкости, доверия и «зон временной нечитаемости».

Если бы вся инженерия подчинялась Jira, не было бы ни Linux, ни Kubernetes, ни GitHub Actions — все они родились из личной инициативы и хакерской свободы.

🔗 Источники

• Шон Гудеке — Seeing Like a Software Company
• Джеймс Скотт — Seeing Like a State
• Венкатеш Рао — The Gervais Principle