Культура работы: как IWE помогает поднять продуктивность в 2+ раза

У меня сейчас 36 активных рабочих продуктов. Архитектура платформы, бот, публикации, исследования, встречи. И параллельно — несколько окон с ИИ, каждое на своей задаче.

Год назад я бы утонул. Сегодня — нет. Я не стал умнее, а поставил новую культуру работы — набор методов, протоколов, навыков и форматов, которые не столько работают вместо меня, а сколько позволяют мне сконцентрироваться над содержанием и значительно ускориться.

Это не тайм-менеджмент. Не список задач. Не GTD. Это часть IWE (Intellectual Work Environment) — операционной системы интеллектуальной работы. Культура работы — один из четырёх компонентов IWE, наряду с ядром мышления, моделью мастерства и сообществом.

Внутри культуры работы я выделил три типа элементов:

Протоколы — формализованные последовательности, которые делаешь по шагам
Навыки — нарабатываемые способности, которые применяешь по ситуации
Форматы — стандарты оформления результатов

Протокол 1. ОРЗ — Открытие, Работа, Закрытие

Самое важное. Любая работа — от 25-минутной сессии до целой недели — проходит три стадии.

Открытие: не «сел и начал что-то делать как обычно», а осознанный старт. Кто я сейчас? (роль — стратег, кодировщик, автор). Как буду действовать? (метод). Что должно получиться? (рабочий продукт — конкретный артефакт с критериями готовности).

Работа: делаю работу по методу. Но на каждом рубеже — ИИ в роли Экстрактора проверяет: появилось ли знание, которое стоит записать, и дает мне на согласование свой вывод? Паттерн, решение, ошибка — всё фиксируется сразу, пока горячее.

Закрытие: что сделал, что узнал, куда записал. Без закрытия — знание остаётся в чате и теряется. Я это проверял: если не закрыть сессию — через день не помнишь, что именно решил. И IWE тоже не поможет.

Этот паттерн фрактальный: одна и та же тройка работает на масштабе сессии (полчаса), дня и недели. Удобно.

Протокол 2. Каскад планирования

Стратегия (куда иду в этом году) → Приоритеты месяца (3-5 главных результатов, на которые выделяешь до 80% бюджета времени) → План на неделю (конкретные рабочие продукты с бюджетами в часах) → План на день (что именно сегодня, в какие свободные блоки).

Каждый уровень сужает фокус. Стратегия без дневного плана — мечтание в облаках. Дневной план без стратегии — суета. Каскад связывает «зачем» с «что делаю прямо сейчас».

У меня есть жёсткое правило: если рабочий продукт занимает больше 3 часов — я обязан ответить, к какому результату месяца он ведёт. Нет ответа — значит, это off-plan или какая-то мелочь (техдолг, например), и нужно решить: это важнее чего-то в плане, или это отвлечение?

Протокол 3. Ритуал учёта времени

Две вещи, без которых работа превращается в суету: что считать и кто делает. Здесь подробная расшифровка одного элемента протокола Открытия сессии.

Рабочий продукт — единица учёта и основного внимания на разных временных периодах. Не «задача», а артефакт с критериями готовности. «Написать документ» — задача, можно делать вечно. «Спецификация Web App: 5 сценариев, модель данных, API endpoints» — рабочий продукт. Понятно, когда он готов. Каждый рабочий продукт получает номер, бюджет (часы), приоритет, связь с результатом месяца. Сейчас у меня WP-181 — это 181-й с начала года.

Роль и метод — фокус сессии. Перед каждой сессией: кто я сейчас? Стратег, кодировщик, исследователь, автор? Это не формальность — роль определяет, какие инструменты использовать, какие вопросы задавать, на что обращать внимание. И как я буду действовать? Для повторяющихся действий есть зафиксированные методы (описания методов). Для новых — выбираю ближайший и адаптирую.

Без этого ритуала легко скатиться: начал как стратег (думать, куда двигаться), а через 10 минут уже кодируешь — потому что «увидел баг». А бюджет времени утекает в незафиксированную работу, которую потом невозможно оценить. Рабочий продукт + роль + метод — три координаты, которые делают время видимым. Такие переключения в течение дня для обычного человека часто происходят незаметно, потому что он осознанно не фокусируется на сессии, РП и тп.

Формат 4. Организация знаний

Знание — не куча файлов. Это иерархия с чёткими уровнями доверия.

Принципы — фундамент, здесь нулевые, первые (FPF) принципы. Базовые правила, которые не меняются от проекта к проекту. Они задают рамку: что допустимо, а что нет.

Предметные знания (Pack) — база знаний конкретной области или вторые принципы. Архитектура платформы, модель домена, терминология. Pack — это то, что знает эксперт о предмете, независимо от конкретной реализации.

Производные знания (DS) — код, документация, конфигурации. Они реализуют знание из Pack, но не являются источником истины. Это третьи принципы.

Иерархия истины: когда два источника противоречат — кто прав? Производная документация уступает базе знаний предметной области. База знаний уступает принципам. Принципы — фундамент. На практике это спасает: «в документации бота написано одно, в архитектуре платформы — другое. Кому верить?» Иерархия даёт ответ без споров.

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

Формат 5. ВДВ — три аспекта любой системы

Любая система — это процесс, в котором кто-то получает что-то на входе, делает работу по методу и отдаёт результат на выходе. ВДВ – это вход – действие – выход.

Процессы (как делать): от кого получаем входные данные? На каком носителе — письмо, API, файл, сообщение в чате? Какой метод применяем? Кому отдаём результат и в каком виде?

Данные (что хранить): какие рабочие продукты возникают на каждом шаге? Какие системы их хранят? Какие интерфейсы между системами — кто с кем обменивается и через что?

Видимость (что увидит пользователь): какие экраны, отчёты, уведомления? Что человек видит и как взаимодействует с системой?

Пропустил одно — система кривая. Обычно пропускают данные: сделали интерфейс, написали код, а что хранить и в каком формате — не подумали. Или описали процесс, но не уточнили, откуда приходят данные и куда уходит результат — и на стыке систем всё разваливается.

Чеклист для любой новой системы: нарисуй входы и выходы (кто → что → кому), определи носители и интерфейсы, перечисли рабочие продукты на каждом шаге. Если не можешь — значит, система ещё не продумана.

Навык 6. Захват знания (Capture-to-Pack)

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

На каждом рубеже — подзадача завершена, паттерн замечен, решение принято, сессия закрыта — я спрашиваю себя и Экстрактора: есть ли тут знание, которое стоит записать? И если да — все сразу записывается в правильное место, поскольку ядро знаний правильно структурировано. И агент ИИ это хорошо знает, поэтому хаоса не будет, любое новое знание будет автоматически проверено на совместимость.

Доменное знание — в Pack (базу знаний предметной области). Реализационное решение — в документацию системы. Правило для всех проектов — в инструкцию. Крупный урок — в память.

Без этого правила я замечал, что одни и те же решения принимаю по 3-4 раза — потому что «забыл записать». Capture-to-Pack — это как автосохранение в игре: не ты помнишь, а система помнит.

Протокол 7. АрхГейт — оценка перед решением

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

Звучит бюрократично. На практике — спасает от «давайте быстренько прикрутим» с последующими месяцами исправлений.

Протокол 8. Стоп-краны (Pre-action Gates)

Набор автоматических проверок перед действием:

Получил задание → сначала проверь, есть ли оно в плане дня или недели
Собираешься реализовать какой-то процесс или кодить → сначала проверь, описан ли сценарий использования, выбрано ли решение по архгейту?
Собираешься добавить новый инструмент → сначала определи, куда он встроится и если описание ролей, рабочих продуктов и тп.

Каждый стоп-кран — это история одной ошибки. Когда-то я потратил день на реализацию одной красивой идеи, сценария которой не было в описании. С тех пор — Gate.

Навык 9. Осторожный мультитаскинг

Я пересмотрел своё отношение к мультитаскингу. То, что было нельзя в век до ИИ, сейчас не совсем актуально. Я работаю в нескольких окнах ИИ параллельно — но с правилами и ритуалами. Каждая сессия — свой рабочий продукт, своя роль. Не смешивать и не переключать внимание кроме открытых сессии.

Мультипликатор = сумма бюджетов завершённых рабочих продуктов / физическое время. Сейчас у меня цель — 1.5-2.5x. То есть за 6 физических часов — результат на 10-15 часов работы, если выполнять каждый РП последовательно. Это возможно, когда ИИ усиливает, а не заменяет мышление. Не всем это можно сейчас рекомендовать, поскольку ИИ-то справится, но сам человек может не понять из-за отсутствия беглости системного мышления.

Больше 3-4 параллельных сессий — coordination overhead съедает выигрыш. Проверено.

Навык 10. Мультиагентность — альтернативная проверка

Один ИИ-помощник — это усилитель. Два — это система с контролем качества.

Принцип простой: результат одной модели проверяется другой. Причём не обязательно более сильной — даже слабая модель (вроде Haiku) регулярно ловит ошибки, которые пропустила сильная (Opus). Потому что дело не в «уме», а в другой точке зрения и в другом контексте, который подается из ядра знаний. Один агент написал код — другой проверяет по чеклисту. Один составил план — другой ищет в нём дыры, опираясь на другие знания.

Это работает по той же причине, по которой работает code review между людьми: автор слеп к собственным допущениям. Второй взгляд — даже менее опытный — видит то, что автор принял за очевидное.

Практика: после завершения рабочего продукта — запускаю верификацию отдельным агентом с context isolation (он не видит процесс создания, только результат и критерии). Это дёшево по времени и регулярно спасает от ошибок, которые я бы иначе пропустил.

Навык 11. Экзоскелетный режим

IWE — это экзоскелет, а не протез. Разница принципиальная и она работает как система безопасности. Сейчас, наверное, нужно обязательно предупреждать всех, кто начинает работать с ИИ: "Осторожно – если не убьет, то может сделать интеллектуальным калекой".

Протез заменяет утраченную функцию. Если его снять — человек не может функционировать. Экзоскелет усиливает существующую функцию. Если его снять — человек может всё то же, просто медленнее.

Опасность любой системы продуктивности с ИИ: если она берёт на себя мышление — через полгода ты разучишься думать без неё. ИИ генерирует текст — и ты перестаёшь формулировать. ИИ планирует день — и ты теряешь навык приоритизации. Система стала костылём, без которого ты слабее, чем был до неё.

Мои правила экзоскелетного режима:

ИИ усиливает, человек решает. Модель предлагает — я выбираю. Модель проверяет — я подтверждаю. Финальное решение всегда за мной.
ИИ задает специальные вопросы, чтобы человек дал больше контекста и чтобы подумал над деталями. Он не бежит сразу исполнять любую волю.
Навык первичен, инструмент вторичен. Если я не могу объяснить, почему принял решение, без ссылки на «ИИ подсказал» — значит, это не моё решение.
Я сам продумываю высокоуровневые модели, хотя детали может потом подсказывать ИИ.
Я обязательно постоянно изучаю системное мышление и трансдисциплины интеллект-стека.

Тест простой: если завтра все ИИ-инструменты исчезнут — я продолжу работать, просто медленнее? Если да — экзоскелет. Если нет — протез, и пора это менять.

Навык 12. Самоисправление

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

Но исправлять ошибки — это только половина. Вторая половина — наблюдаемость (второй уровень архгейт). Я должен понимать, как IWE пришёл к любому результату. Откуда данные, какой логикой обработаны, почему именно этот вывод. Если я не могу проследить путь от входа к выходу — система непрозрачна, а значит неуправляема. Это как принять лекарство, не зная состав: может помочь, а может навредить, и ты не узнаешь, пока не станет поздно.

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

И самое важное: не спускать ошибки. Подход — как у въедливого руководителя или профессора, который не пропустит ни одну неточность. Каждое отклонение разбирается. Каждое «и так сойдёт» ставится под вопрос. Если не быть такой «душнилой» — эффекта не будет. Ошибки, которые спустил, становятся нормой. Норма деградирует. Через месяц система выдаёт мусор, и все привыкли, что так и должно быть.

Протокол 13. Стоп-лист для рабочих продуктов

Когда прекращать: бюджет исчерпан (потрачено больше 150% без прогресса), блокер больше двух недель, гипотеза опровергнута, приоритет упал.

Антипаттерн — «я уже столько вложил, жалко бросать». Sunk cost fallacy. Стоп-лист работает именно против этого: решение на основе будущей ценности, а не прошлых затрат. И приоритеты месяца могут быть пересмотрены.

Протокол 14. Эволюция системы

Операционная система мышления — не монумент. Она должна меняться вместе с тобой.

Каждый день при закрытии я задаю себе три вопроса: что я вынес и чему научился? какое правило мешало? Какого правила не хватало? Какое правило я обходил (а значит, оно или устарело, или я его не понимаю)?

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

Важно: эволюция — это не «каждую неделю всё переписывать». Это точечные изменения на основе реальных столкновений с реальностью. Правило появляется после боли. Правило уходит, когда перестаёт предотвращать боль.

Как это всё связано

Эти 14 элементов культуры работы — не независимые советы. Они скелет:

ОРЗ — ритм (когда что делать)
Каскад планирования — направление (зачем)
Ритуал учёта — единица измерения + фокус (что считать и кто делает)
Структура знаний — организация и иерархия истины (где правда)
ВДВ — проектирование (процессы, данные, видимость — с входами и выходами)
Capture — знание (куда записать, пока горячее)
АрхГейт + Gates — защита (от поспешных решений)
Мультитаскинг — мощность (больше за то же время)
Мультиагентность — контроль качества (второй взгляд ловит слепые пятна)
Экзоскелет — граница (ИИ усиливает, а не заменяет мышление)
Самоисправление — реакция (ошибка → немедленный фикс)
Эволюция — адаптация (система меняется вместе с тобой)
Стоп-лист — отпускание (вовремя закрыть)

Убери ОРЗ — нет ритма, работа не начинается и не заканчивается. Убери Capture — знание не копится, те же ошибки каждую неделю. Убери каскад — нет связи «зачем» с «что делаю сейчас». Убери мультитаскинг — одна сессия за раз, мультипликатор 1.0. Убери экзоскелет — через полгода ты слабее, чем до системы. Убери эволюцию — система окаменеет и перестанет помогать.

Три разреза культуры работы

Элементы культуры работы — не список для чтения. Каждый привязан к конкретному моменту в работе. По типу они делятся на три разреза:

Протоколы — формализованные последовательности, которые делаешь по шагам:

ОРЗ — при каждом открытии и закрытии сессии, дня, недели
Каскад планирования — при формировании плана недели и дня
Учёт времени — при взятии любой задачи (WP Gate)
АрхГейт — перед любым архитектурным решением
Стоп-краны — перед реализацией, коммитом, новым инструментом
Стоп-лист — при еженедельном ревью активных рабочих продуктов
Эволюция — при закрытии недели: ретроспектива самой культуры работы

Навыки — нарабатываемые способности, которые применяешь по ситуации:

Capture — на каждом рубеже работы: подзадача завершена, паттерн замечен
Мультитаскинг — при распределении слотов в плане дня
Мультиагентность — второй взгляд при завершении любого рабочего продукта
Экзоскелет — тест «останется ли навык без ИИ?» при каждом решении
Самоисправление — расхождение с реальностью → немедленный фикс, в любой момент

Форматы — стандарты оформления результатов:

Структура знаний — иерархия истины при любом обращении к документации
ВДВ — три аспекта проверяются при проектировании любой системы

Протоколы встроены в ритуалы (открытие дня, закрытие недели) — ИИ-помощник знает о них и не даёт начать без прохождения. Навыки нарабатываются со временем — это способ думать, который становится привычкой. Форматы задают единообразие результатов.

Я строил это годы и буду непрерывно их далее развивать. Не сразу, не по плану — каждый элемент появился после конкретной боли. Но вместе они образуют культуру работы — часть операционной системы интеллектуальной работы (IWE). Я думаю о содержании, а культура работы держит каркас.

А теперь — масштаб

Всё, что я описал выше, — это один компонент из четырёх, которые присутствуют в IWE. Культура работы отвечает на вопрос «как работаешь». Но IWE — это не только «как».

Четыре компонента IWE:

Ядро мышления — чем думаешь. Знания организованы не по папкам, а по принципам. В основе — 30 лет формализации мышления: от картины мира и универсальных принципов (5400+ текстов) до предметных знаний конкретной области. Пятиуровневая иерархия: картина мира → первые принципы → прикладные принципы → предметные знания → конкретные решения. ИИ работает с этой структурой на порядок точнее, потому что знает не просто файлы, а систему знаний.
Культура работы — как работаешь. Те самые 14 элементов, о которых весь этот пост. Протоколы, навыки и форматы — операционная дисциплина каждого дня. Здесь я, в частности, уже пользуюсь выстроенной структурой ядра знаний (в п.1 она прорабатывается и развивается).
Модель мастерства — куда растёшь, причем непрерывно и бесконечно. У нас есть 9 уровней квалификации: от Ученика до Просветителя. Это не геймификация — это лестница на десятилетия, на всю жизнь. Это не конечная игра. Чем дольше в IWE — тем ценнее среда, тем точнее ИИ-персонализация, тем глубже практика.
Сообщество созидателей — где живёшь. Это не просто профессиональная сеть и не «группа поддержки курса». Это продуктивная социальная среда — место, где человек формируется. Наставники, peer review, совместная практика на реальных задачах — всё это меняет не только то, как ты работаешь, но и то, как ты думаешь, чего хочешь, что считаешь нормой. Культура сообщества задаёт планку: что значит «сделано хорошо», что значит «разобрался», что значит «помог другому». Со временем эта планка становится внутренней — ты уносишь её с собой в любой контекст: в семью, в команду, в личные решения. Сообщество созидателей — это среда не только для работы, а для жизни. Потому что человек, который умеет думать, создавать и помогать другим — он такой везде, а не только с 9 до 18.

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

IWE работает поверх любой ИИ-платформы — Claude, ChatGPT, Copilot — как Ubuntu работает поверх любого железа. Это не привязка к инструменту. Это среда, которая растёт вместе с человеком.

Открыть библиотеку