В мире технологий мы привыкли думать, что больше процессов, метрик и 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