Инструменты: таск-трекеры, заметки, Zettelkasten, автоматизация рутины

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

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

Поэтому договоримся сразу о двух вещах.

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

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

Разберём инструменты по слоям: чем они отличаются, где ломаются, как выбирать и как перестать выбирать.

Часть 1. Четыре слоя и правило принадлежности

Личная система инженера хранит четыре принципиально разных типа объектов. Главная причина хаоса — попытка держать их в одном месте.

Правило принадлежности звучит так: объект живёт в том слое, вопрос к которому он отвечает. «Что я делаю дальше?» — слой обязательств. «Как это устроено?» — слой знания. «Когда я это делаю?» — слой времени.

Проверка на практике: если вы ищете, как настраивается ретрай в вашем HTTP-клиенте, и находите это в задаче «Разобраться с ретраями» — у вас смешаны слои. Задача давно закрыта, а знание должно было пережить её.

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

Часть 2. Критерии выбора, которые действительно предсказывают исход

Обзоры сравнивают инструменты по числу фич. Практика показывает, что предсказывают выживание системы совсем другие параметры.

Трение захвата

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

Замерьте честно. Откройте секундомер, представьте, что мысль пришла, и пройдите путь до записанной строки. Приложение, которое требует разблокировать телефон, дождаться синхронизации, выбрать проект и нажать «сохранить», проваливает тест, каким бы красивым оно ни было.

Доверие

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

Право на выход

Ключевой вопрос: сможете ли вы через три года забрать данные и уйти? Проверка простая — выгрузите всё прямо сейчас и посмотрите на результат. Markdown-файлы с человекочитаемыми именами — отлично. JSON с внутренними идентификаторами и ссылками вида block-id: 7f3a — тревожно. «Экспорт в PDF» — это не экспорт.

Это не паранойя. Приложения закрываются, меняют владельцев, переезжают на подписку, ломают модель данных. За последние пятнадцать лет через это прошли пользователи Google Reader, Wunderlist, Astrid, Springpad, Catch Notes и десятков менее известных сервисов. Плоский текст пережил всех.

Стоимость смены

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

Что в критериях отсутствует

Красота интерфейса, число интеграций, наличие ИИ-функций, мобильные виджеты, темы оформления, поддержка вложенности на семь уровней. Всё это не бесполезно, но не предсказывает, будете ли вы пользоваться системой через полгода.

Часть 3. Таск-трекеры: классы и честные компромиссы

Все личные трекеры сводятся к пяти классам. Внутри класса разница косметическая, между классами — принципиальная.

Из этой линии видно занятную вещь: форматы живут дольше приложений. Индексные карточки Дьюи и текстовый файл todo.txt пережили десятки продуктов с венчурными раундами.

Класс 1. Обычный текст

todo.txt (формат), markdown-файл, org-mode (orgmode.org).

(A) 2026-07-16 Починить N+1 в выдаче ленты +billing @глубокая-работа due:2026-07-20
(B) Отписать по ADR про очередь +platform @письмо
x 2026-07-15 2026-07-13 Разобрать алерты дежурства +oncall

Плюсы: ноль трения на запись, живёт в git рядом с кодом, ищется grep, парсится чем угодно, переживёт любое приложение, полностью ваше.

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

Кому подходит: тем, кто и так живёт в терминале и редакторе, и кому важно версионирование.

Класс 2. Терминальные трекеры

Taskwarrior, tasksh, надстройки над todo.txt.

# Задача с проектом, контекстом и зависимостью — всё в одной строке
task add "снять профиль запроса на стейджинге" project:billing +deep due:friday
task add "починить N+1" project:billing depends:1 +deep

# Контекст «глубокая работа»: показывать только то, что требует блока концентрации
task context define deep '+deep and status:pending'
task context deep
task next

Плюсы: очень быстрый ввод, мощный язык фильтров, зависимости между задачами из коробки, скриптуется идеально.

Минусы: своя база в ~/.task, а не человекочитаемый текст (хотя экспорт в JSON полный); порог входа; мобильные клиенты слабые; легко утонуть в настройке отчётов.

Класс 3. Облачные списки

Todoist, Things, TickTick, Microsoft To Do, Apple Reminders.

Плюсы: захват в две секунды с телефона, надёжные напоминания, естественный язык в вводе («в пятницу в 15:00»), синхронизация без вашего участия, разбор на ходу.

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

Класс 4. Базы и гибриды

Notion, Obsidian с плагином задач, Logseq, Anytype.

Плюсы: один инструмент под задачи и знание, произвольные представления, легко подогнать под свой процесс.

Минусы — тот же список, но с обратным знаком. Гибкость означает, что вы будете её настраивать, а настройка бесконечна. У Notion добавляется заметная задержка на запуск и открытие страницы, что убивает трение захвата.

Класс 5. Рабочие трекеры

Jira, Linear, GitHub Issues, YouTrack, Azure Boards.

Это не личные инструменты, и попытка сделать их личными — типичная ошибка. Рабочий трекер отражает обязательства перед командой: он оптимизирован под видимость, отчётность и планирование спринта. Ваша личная работа шире: там есть «дочитать RFC», «ответить Марине про схему», «разобраться, почему у нас два клиента к одному сервису».

Проблема двух систем

У любого работающего инженера минимум два места с задачами: рабочий трекер и личный список. Есть три стратегии, и все три имеют цену.

Синхронизация. Скрипт тянет тикеты из Jira в личный список. Цена: любая двусторонняя синхронизация рано или поздно расходится, и вы получаете два разных состояния одной задачи. Работает только в одну сторону и только на чтение.

Ссылка вместо копии. В личном списке лежит одна строка на тикет с идентификатором и вашим следующим действием, а вся детализация — в трекере.

- [ ] BILL-4127 — снять профиль запроса на стейджинге и приложить к тикету @deep

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

Разделение по природе. Рабочий трекер — всё, что видно команде; личный список — всё, что видно только вам. Ничего не дублируется. Цена: во время недельного обзора надо смотреть в два места. Это нормально; недельный обзор для того и нужен (см. горизонты планирования).

Чего делать точно не стоит: заводить личные задачи в командном трекере «чтобы всё было в одном месте». Ваши «дочитать статью» и «подумать про схему» превратятся в шум в чужих отчётах, а вы получите давление видимости на то, что должно оставаться личным.

Часть 4. Заметки: три разных инструмента под одним словом

Слово «заметки» обозначает три несовместимые задачи. Их смешивание — причина, по которой хранилища заметок разрастаются в свалку.

Мимолётные живут часы. Их задача — не потерять мысль до разбора. Они не требуют структуры и должны удаляться после обработки. Это тот же инбокс.

Справочные отвечают на вопрос «как это устроено». Runbook по сервису, конспект по протоколу, список нужных команд, ADR. У них есть очевидное место, они читаются поиском и навигацией, и им не нужны никакие двунаправленные ссылки.

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

Практический вывод: не тащите справочный материал в сеть связей. Runbook не становится лучше от того, что на него ссылаются шесть заметок. Ему нужен предсказуемый путь и свежесть, а не граф.

Часть 5. Zettelkasten: что это на самом деле

Никлас Луман (1927–1998) — немецкий социолог, автор около 70 книг и более 400 статей. Он работал с картотекой из деревянных ящиков; сохранившийся архив содержит примерно 90 000 карточек и оцифрован — его можно листать на niklas-luhmann-archiv.de. Сам Луман описал метод в эссе Kommunikation mit Zettelkästen (1981), где называет картотеку «партнёром по коммуникации».

Лучший академический разбор устройства архива — работа архивиста проекта Йоханнеса Шмидта Niklas Luhmann’s Card Index: Thinking Tool, Communication Partner, Publication Machine (2018). Массовую популярность методу принесла книга Зёнке Аренса How to Take Smart Notes (2017) — полезная, но заметно более уверенная в универсальности метода, чем позволяют факты.

Механика в четырёх правилах

1. Атомарность. Одна карточка — одна мысль. Не «всё про идемпотентность», а «повторный запрос безопасен только при наличии ключа, устойчивого к перезапуску клиента». Атомарность нужна не для красоты: она делает карточку пригодной к переиспользованию в чужом контексте.

2. Своими словами. Карточка — не цитата и не конспект. Луман разделял библиографические карточки (что прочитано, откуда) и постоянные (что я об этом думаю). Переформулирование — это и есть работа; без него вы просто перекладываете чужой текст.

3. Устойчивый идентификатор. У Лумана это была ветвящаяся нумерация (21/3d7a6 — так называемый Folgezettel): новая карточка вставлялась рядом с той, что её породила, а не в конец. Смысл нумерации — не классификация, а возможность вставить карточку между двумя существующими без перенумерации всего архива. В цифровой версии эту роль обычно играет метка времени: 202607161042.

4. Связи важнее категорий. Карточка находится не потому, что лежит в правильной папке, а потому, что на неё ссылаются. Дополнительно у Лумана были регистры — входные карточки по темам, дающие несколько точек входа в сеть.

Минимальная цифровая постоянная заметка выглядит так:

---
id: 202607161042
title: Идемпотентность требует ключа, переживающего перезапуск клиента
tags: [распределённые-системы, надёжность]
---

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

Отсюда практическое следствие: идемпотентность — свойство не эндпоинта,
а пары «клиент + эндпоинт». Наличие Idempotency-Key в API ничего не
гарантирует, если клиент генерирует его в момент отправки.

Связано:
- [[202607141120]] — outbox как способ пережить падение между записью и отправкой
- [[202606281530]] — at-least-once доставка вынуждает потребителя быть идемпотентным
Против:
- [[202607160915]] — для операций с естественным ключом отдельный ключ избыточен

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

Честный разбор: что известно и что нет

Здесь надо быть аккуратным, потому что вокруг метода накопилось много уверенных утверждений без оснований.

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

Что известно про соседние вопросы. Исследование Мюллера и Оппенгеймера (2014, The Pen Is Mightier Than the Keyboard) показало преимущество рукописных конспектов над дословным набором — обычно это цитируют в поддержку «переформулирования своими словами». Однако крупная репликация Морхеда, Данлоски и Роусона (2019) основной эффект не воспроизвела. Осторожный вывод: перефразирование, вероятно, полезнее дословной записи, но масштаб эффекта неизвестен и точно меньше, чем принято утверждать.

Что известно про поиск и организацию. Офер Бергман и Стив Уиттакер в The Science of Managing Our Digital Stuff (MIT Press, 2016) суммируют десятилетия исследований персонального управления информацией. Ключевые находки: люди устойчиво предпочитают навигацию поиску даже там, где поиск объективно быстрее; теги используются мало и непоследовательно; папочная иерархия работает лучше, чем считают её критики. Это прямой контраргумент к «просто свяжи всё со всем и найдёшь поиском».

Где метод ломается у инженера.

• Ложная валюта. Число заметок и красота графа связей приятны и легко измеримы, а результат — нет. Легко получить тысячу карточек и ни одного написанного документа.
• Затраты на вход. Хорошая постоянная заметка стоит 10–20 минут. Если у вас четыре часа сфокусированного времени в неделю, это дорого.
• Не тот тип знания. Большая часть знания инженера — процедурная и быстро устаревающая: команды, конфиги, версии. Ей нужен runbook, а не картотека. Zettelkasten оправдан там, где вы годами думаете об одном классе проблем и производите текст: RFC, статьи, доклады, архитектурные решения.
• Обслуживание. Сеть требует регулярной прополки. Без неё через год вы получите граф, в котором половина связей ведёт к заметкам, содержания которых вы не помните.

Минимальный полезный вариант. Если вы не производите текст регулярно, возьмите одну идею вместо всего метода: раз в неделю, во время обзора, записывайте одну мысль своими словами и связывайте её с одной старой. Это стоит пятнадцать минут и даёт большую часть эффекта без инфраструктуры.

Часть 6. Заметки инженера: четыре шаблона, которые окупаются

Здесь — конкретика, применимая завтра, независимо от того, приняли вы Zettelkasten или нет.

Дневная заметка (worklog)

Один файл на день, создаётся автоматически, живёт в том же хранилище.

# 2026-07-16, четверг

## Планирую (не более трёх)
- [ ] BILL-4127 — снять профиль запроса на стейджинге
- [ ] дочитать RFC про схему событий, отписать два вопроса
- [ ] ревью PR #812

## Журнал
09:40 начал профилирование, `EXPLAIN ANALYZE` на проде безопасно только с LIMIT
10:20 нашёл: N+1 не в ленте, а в сериализаторе аватарок
11:05 прерван инцидентом в оплате, вернулся 11:40 — потерял примерно 20 минут

## Ждёт ответа
- Марина — подтверждение схемы (спросил 15.07)

## В картотеку
- профилирование на проде: почему LIMIT обязателен → черновик заметки

Ценность журнала не в дисциплине, а в трёх вещах: он даёт материал для недельного обзора; он делает видимой стоимость прерываний (см. фокус); он спасает после отпуска, когда «на чём я остановился» стоит полдня.

ADR — запись архитектурного решения

Формат предложил Майкл Найгард в 2011 году (оригинальная заметка, каталог форматов — adr.github.io). Это, вероятно, самая высокая отдача на единицу написанного текста во всей инженерной документации.

# ADR-0014. Идемпотентность через ключ, создаваемый в outbox

Дата: 2026-07-16
Статус: принято (заменяет ADR-0009)

## Контекст
Платёжный клиент теряет Idempotency-Key при падении между отправкой и
получением ответа. За квартал — 4 инцидента двойного списания.

## Решение
Ключ генерируется при записи намерения в outbox, в одной транзакции с
бизнес-данными. Отправщик читает готовый ключ и никогда не создаёт свой.

## Последствия
+ повтор безопасен при любом падении клиента
+ ключ виден в БД, инцидент отлаживается запросом
- нужна миграция таблицы outbox и переезд двух сервисов
- клиенты без outbox (мобильные) остаются на старой схеме — отдельная задача

## Альтернативы
- дедупликация на стороне провайдера: отклонена, окно всего 24 часа
- хеш тела запроса как ключ: отклонён, ретрай с изменённой суммой считается повтором

Практическое правило: ADR пишется в момент решения, занимает 15 минут и никогда не редактируется задним числом — устаревшее решение заменяется новым ADR со статусом «заменяет». Тогда файл становится историей мышления команды, а не документацией текущего состояния.

Runbook

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

# billing-api — runbook

## Быстрая диагностика
1. Дашборд: <ссылка> — смотреть p99 и долю 5xx
2. Если p99 > 800 мс и растёт: почти всегда пул соединений к БД
   `SELECT count(*) FROM pg_stat_activity WHERE state = 'active';`
3. Если 5xx с кодом PROVIDER_TIMEOUT: смотреть статус провайдера, не наш инцидент

## Известные ловушки
- Рестарт пода НЕ помогает при исчерпании пула: соединения висят на стороне БД до таймаута.
- Метрика `billing_success_total` считает и повторы. Реальная конверсия — в дашборде аналитики.

Дежурство — контекст, где качество заметок конвертируется в сон. Runbook, написанный после инцидента, экономит следующему дежурному (иногда — вам) полчаса паники.

Заметка «почему я так решил» для себя

Отдельный жанр: короткая запись о собственном решении, которое через месяц покажется странным. «Не стал выносить в отдельный сервис, потому что команда одна и деплой связанный; пересмотреть, когда появится второй потребитель». Стоит две минуты, экономит спор с самим собой.

Часть 7. Автоматизация рутины: как считать

Инженер автоматизирует по инстинкту, и это одновременно его сила и его ловушка. Классическая иллюстрация — xkcd 1205 «Is It Worth the Time?» с таблицей окупаемости и парная к ней xkcd 1319 «Automation», где реальный график всегда хуже ожидаемого.

Формула, которая учитывает обслуживание

Наивный расчёт — «пять минут в день, значит окупится за две недели» — систематически ошибается, потому что игнорирует поддержку. Честная версия:

Экономия за горизонт H = (T_ручное - T_авто) * N(H) - T_разработка - T_поддержка(H)

где N(H)         — сколько раз операция случится за горизонт H
    T_поддержка  — ремонт после смены API, версии, формата, ОС

Горизонт H стоит брать не больше двух лет: дальше меняется работа, команда, стек. Практическая эвристика: если операция случается реже раза в неделю, а автоматизация занимает больше часа — не автоматизируйте, задокументируйте. Запись в runbook стоит пять минут и не ломается.

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

Что автоматизировать в первую очередь

Начните не с продуктивности, а с переключения контекста. Самая дорогая рутина инженера — не набор команд, а восстановление окружения после отвлечения.

#!/usr/bin/env bash
# ~/bin/pick — вход в задачу: ветка, черновик PR, дневная заметка, ссылка на тикет.
# Использование: pick BILL-4127
set -euo pipefail

TICKET="${1:?укажите идентификатор тикета, например BILL-4127}"
NOTES_DIR="${NOTES_DIR:-$HOME/notes}"

# Заголовок тикета тянем из трекера один раз и переиспользуем везде.
# jq и gh должны быть установлены; для Jira замените на её API.
title="$(gh issue view "$TICKET" --json title --jq .title 2>/dev/null || echo "")"
slug="$(printf '%s' "${title:-$TICKET}" \
        | tr '[:upper:]' '[:lower:]' \
        | sed -E 's/[^a-z0-9]+/-/g; s/^-+|-+$//g' \
        | cut -c1-40)"

branch="${TICKET,,}-${slug:-work}"
git switch -c "$branch" 2>/dev/null || git switch "$branch"

# Рабочий файл задачи: контекст, который иначе живёт только в голове.
work_note="$NOTES_DIR/work/$TICKET.md"
mkdir -p "$(dirname "$work_note")"
if [ ! -f "$work_note" ]; then
    cat > "$work_note" <<EOF
# $TICKET — ${title:-без названия}

Ветка: \`$branch\`
Начато: $(date -I)

## Что уже понятно

## Что проверить

## Тупики (чтобы не повторять)
EOF
fi

echo "ветка: $branch"
echo "заметка: $work_note"

Секция «Тупики» — самая полезная строка в шаблоне. Она не даёт вам через три дня заново проверить гипотезу, которую вы уже отбросили.

Автоматизация вокруг заметок

Дневная заметка должна возникать без вашего участия. Вариант без зависимостей:

#!/usr/bin/env bash
# ~/bin/today — открывает дневную заметку, создавая её из шаблона при первом вызове.
set -euo pipefail

NOTES_DIR="${NOTES_DIR:-$HOME/notes}"
day="$(date +%F)"
file="$NOTES_DIR/daily/$day.md"
mkdir -p "$(dirname "$file")"

if [ ! -f "$file" ]; then
    # Незакрытые пункты вчерашнего дня переносим явно: невидимый перенос
    # создаёт иллюзию, что вчера всё сделано.
    prev="$(find "$NOTES_DIR/daily" -name '\ast .md' ! -name "$day.md" | sort | tail -1)"
    carried=""
    if [ -n "$prev" ]; then
        carried="$(grep -E '^- \[ \] ' "$prev" || true)"
    fi
    {
        printf '# %s, %s\n\n' "$day" "$(LC_TIME=ru_RU.UTF-8 date +%A)"
        printf '## Планирую (не более трёх)\n'
        [ -n "$carried" ] && printf '%s\n' "$carried"
        printf '\n## Журнал\n\n## Ждёт ответа\n\n## В картотеку\n'
    } > "$file"
fi

exec "${EDITOR:-vim}" "$file"

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

Сбор материала для недельного обзора

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

#!/usr/bin/env python3
"""Собирает факты прошедшей недели для недельного обзора.

Источники: git-коммиты в указанных репозиториях и дневные заметки.
Сложность: O(C + L), где C — число коммитов за период, L — суммарное число
строк в семи дневных заметках. Память O(C + L) — всё держим в списках,
на недельном объёме это десятки килобайт.
"""
import datetime as dt
import pathlib
import subprocess
import sys

NOTES = pathlib.Path.home() / "notes" / "daily"
REPOS = [pathlib.Path.home() / "work" / name for name in ("billing", "platform")]


def week_bounds(today: dt.date) -> tuple[dt.date, dt.date]:
    """Понедельник—воскресенье завершившейся недели."""
    monday_this = today - dt.timedelta(days=today.weekday())
    return monday_this - dt.timedelta(days=7), monday_this - dt.timedelta(days=1)


def commits(repo: pathlib.Path, since: dt.date, until: dt.date) -> list[str]:
    """Свои коммиты за период. Чужие в личный обзор не нужны."""
    if not (repo / ".git").exists():
        return []
    out = subprocess.run(
        ["git", "-C", str(repo), "log",
         f"--since={since}", f"--until={until + dt.timedelta(days=1)}",
         "--author", subprocess.run(
             ["git", "-C", str(repo), "config", "user.email"],
             capture_output=True, text=True, check=False).stdout.strip(),
         "--pretty=format:%ad %s", "--date=short"],
        capture_output=True, text=True, check=False,
    ).stdout
    return [line for line in out.splitlines() if line]


def daily_sections(since: dt.date, until: dt.date) -> dict[str, list[str]]:
    """Вытаскивает из дневных заметок незакрытые пункты и кандидатов в картотеку."""
    result: dict[str, list[str]] = {"открыто": [], "ждёт": [], "в картотеку": []}
    day = since
    while day <= until:
        path = NOTES / f"{day.isoformat()}.md"
        day += dt.timedelta(days=1)
        if not path.exists():
            continue
        section = None
        for line in path.read_text(encoding="utf-8").splitlines():
            low = line.lower()
            if low.startswith("## ждёт"):
                section = "ждёт"
            elif low.startswith("## в картотеку"):
                section = "в картотеку"
            elif line.startswith("## "):
                section = None
            elif line.startswith("- [ ] "):
                result["открыто"].append(line[6:])
            elif section and line.startswith("- "):
                result[section].append(line[2:])
    return result


def main() -> int:
    since, until = week_bounds(dt.date.today())
    print(f"# Обзор недели {since} — {until}\n")

    print("## Что сделано (коммиты)")
    total = 0
    for repo in REPOS:
        rows = commits(repo, since, until)
        total += len(rows)
        for row in rows:
            print(f"- {repo.name}: {row}")
    print(f"\nвсего коммитов: {total}\n")

    sections = daily_sections(since, until)
    for name, rows in sections.items():
        print(f"## {name.capitalize()}")
        # Дубли за неделю схлопываем, порядок сохраняем.
        for row in dict.fromkeys(rows):
            print(f"- {row}")
        print()
    return 0


if __name__ == "__main__":
    sys.exit(main())

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

Мелкая автоматизация с высокой отдачей

• Расширение текста. Espanso (кросс-платформенно), Keyboard Maestro, AutoHotkey. Шаблоны ответов на типовые вопросы, заголовки PR, ссылки на дашборды. Экономия небольшая, но снимает микротрение.
• Хуки git. Прогон форматтера и быстрых тестов до коммита; проверка, что в сообщении есть идентификатор тикета. Через pre-commit — чтобы конфигурация жила в репозитории, а не только у вас.
• Правила почты. Автоматические письма из CI, мониторинга и трекера не должны попадать во входящие. Подробнее — в статье про информационную гигиену.
• Файловые правила. Hazel на macOS, systemd.timer плюс скрипт на Linux: разбор ~/Downloads, архивация старых веток, чистка контейнеров.
• gh и API трекера. Черновик PR из шаблона, автоматическая простановка меток по путям файлов, напоминание о своих незакрытых ревью.

Куда автоматизацию не пускать

Есть класс операций, где автоматизация вредна, потому что ручное действие и есть смысл.

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

Общее правило: не автоматизируйте то, что должно вызывать у вас дискомфорт. Дискомфорт здесь — рабочий сигнал, а не баг.

Часть 8. Автоматизация как форма прокрастинации

Отдельно, потому что это профессиональная болезнь.

Признаки, что вы автоматизируете вместо работы: скрипт пишется третий час при заявленной экономии в две минуты; вы добавляете в него флаги, которыми не пользуетесь; вы начали писать к нему тесты; вы объясняете коллегам, какой у вас получился элегантный сетап. Явление известно как yak shaving — цепочка подготовительных задач, уводящая от исходной.

Практическая защита — три правила:

1. Таймбокс. Час на автоматизацию, жёстко. Не успели — скрипт откладывается в бэклог, работа делается руками. Механика таймбокса — в статье про фокус.
2. Правило трёх раз. Сначала сделайте операцию руками трижды. К третьему разу вы будете знать её реальные крайние случаи, и скрипт получится вдвое короче.
3. Отдельное время. Автоматизация делается в специально отведённый слот (например, пятница после обеда), а не в момент, когда вы наткнулись на рутину. Это то же различие, что между захватом и выполнением: заметили рутину — записали в инбокс, не бросили текущую задачу.

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

Часть 9. Три референсных сборки

Ниже — три работающих комбинации целиком. Не «лучшие», а внутренне непротиворечивые: детали внутри каждой поддерживают друг друга.

Сборка A: терминальная

• Захват: скрипт in на глобальном хоткее, дописывает строку в ~/notes/inbox.md
• Задачи: Taskwarrior, контексты deep / shallow / waiting
• Знание: markdown-файлы в git, поиск через ripgrep, дневные заметки скриптом today
• Календарь: рабочий корпоративный, локально просматривается через khal или веб
• Автоматизация: pick, today, недельный сборщик, хуки pre-commit

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

Сборка B: обсидиан-центричная

• Захват: мобильное приложение Obsidian, кнопка быстрой заметки в inbox.md
• Задачи: плагин Tasks поверх тех же файлов, доска через Kanban-плагин
• Знание: то же хранилище, папки для справки, сеть связей для постоянных заметок
• Календарь: внешний, интеграция через Periodic Notes
• Автоматизация: Templater для шаблонов, синхронизация через git или платный Sync

Плюсы: один инструмент на всё, файлы остаются вашими markdown, есть и папки, и граф. Минусы: соблазн бесконечной настройки плагинов; плагины ломаются при обновлениях; на больших хранилищах мобильная версия тормозит.

Сборка C: облачный минимализм

• Захват и задачи: Todoist или Things, быстрый ввод с телефона и с ноутбука
• Знание: Google Docs или Notion для справки, ADR — в репозитории рядом с кодом
• Календарь: рабочий, с блоками времени
• Автоматизация: почти никакой, кроме правил почты и шаблонов текста

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

Если вы не знаете, с чего начать, — начните с C. Она требует наименьших вложений и даёт наибольшую долю эффекта. Переезжать в A или B имеет смысл, когда вы упрётесь в конкретное ограничение, которое можете назвать вслух.

Часть 10. Типичные ошибки

Смена инструмента вместо смены привычки. Симптом: «в этом приложении я наконец начну вести недельный обзор». Не начнёте. Обзор не начинается из-за приложения и не начинается из-за его отсутствия.

Идеальная структура до наполнения. Заведение пятиуровневой иерархии папок в пустом хранилище. Структура должна расти из накопившегося материала, а не предшествовать ему. Начинайте с трёх папок и заводите четвёртую, когда в одной из них станет тесно.

Дублирование источников правды. Одна задача в трекере, в личном списке и в календаре. Через неделю три версии расходятся, и вы перестаёте верить всем трём. У каждого объекта ровно одно каноническое место, остальное — ссылки.

Хранилище-свалка. Сохранение статей «на потом» без чтения и переформулирования. Такой архив не помогает: он создаёт иллюзию, что вы это знаете. Правило: сохраняете статью — сразу пишете одно предложение о том, зачем она вам. Не смогли написать — не сохраняйте.

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

Настройка вместо использования. Метрика здоровья: сколько времени за последний месяц вы потратили на настройку системы против времени, когда она вам помогла. Здоровое соотношение — примерно 1 к 20.

Синхронизация ради синхронизации. Двусторонний мост между двумя трекерами — почти всегда ошибка. Он расходится, и разбирательство стоит дороже, чем ручной перенос пяти строк в неделю.

Часть 11. Где всё это честно ломается

Когда виноват не инструмент. Если вы не успеваете, потому что на вас три проекта и дежурство, никакая система не поможет. Инструменты решают задачу «не потерять и не переключаться зря»; они не решают задачу «работы больше, чем времени». Это организационная проблема, и обсуждать её надо с руководителем, а не с приложением. Про перегрузку и её последствия — статья про выгорание.

Когда команда работает иначе. Ваша личная система живёт внутри командного процесса. Если у команды всё в Jira и обсуждения в тредах, автономный красивый сетап будет постоянно рассинхронизирован с реальностью. Стройте личный слой поверх командного, а не рядом с ним.

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

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

Мини-итог

• Инструмент не система. Сначала решения и привычки, потом хранилище.
• Четыре слоя — захват, обязательства, знание, время — держите раздельно; объект живёт там, на чей вопрос он отвечает.
• Выбирайте по трению захвата, доверию, праву на выход и стоимости смены; не по числу фич.
• Проблема двух систем решается ссылкой на тикет с вашим следующим действием, а не двусторонней синхронизацией.
• «Заметки» — три разных инструмента: мимолётные, справочные, постоянные. Runbook и ADR дают больше отдачи, чем красивый граф связей.
• Zettelkasten — реальный метод с одним впечатляющим кейсом и без контролируемых исследований. Полезен тем, кто регулярно производит текст; дорог для всех остальных.
• Автоматизируйте частое и детерминированное; редкое и детерминированное — документируйте чеклистом. Считайте обслуживание, а не только наклон кривой.
• Таймбокс на автоматизацию, правило трёх раз, отдельный слот. Иначе автоматизация превращается в приятную прокрастинацию.
• Меняйте инструмент, когда можете назвать вслух ограничение, в которое упёрлись. Не чаще.

Источники

• Ofer Bergman, Steve Whittaker. The Science of Managing Our Digital Stuff. MIT Press, 2016 — эмпирика персонального управления информацией: навигация против поиска, судьба тегов.
• Johannes F. K. Schmidt. Niklas Luhmann’s Card Index: Thinking Tool, Communication Partner, Publication Machine, 2018 — академическое описание архива Лумана.
• Цифровой архив Лумана: niklas-luhmann-archiv.de
• Sönke Ahrens. How to Take Smart Notes, 2017 — популяризация метода; читать с поправкой на энтузиазм.
• Pam Mueller, Daniel Oppenheimer. The Pen Is Mightier Than the Keyboard, Psychological Science, 2014; репликация: Morehead, Dunlosky, Rawson, Educational Psychology Review, 2019.
• Michael Nygard. Documenting Architecture Decisions, 2011; каталог форматов — adr.github.io
• Google SRE Book, глава Eliminating Toil — определение рутины и критерии её устранения; лучший инженерный текст про границы автоматизации.
• xkcd 1205 «Is It Worth the Time?» и xkcd 1319 «Automation»
• Документация инструментов: orgmode.org, taskwarrior.org, todo.txt, obsidian.md, espanso.org, pre-commit.com
• Andy Matuschak. Evergreen notes — практика постоянных заметок, изложенная самим методом.

Что дальше

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