CLOG в базе знаний программиста

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

Пока эта методика находится у меня на тестировании. Должно работать. Но может и взорваться...

Суть CLOG — creative log — создать запись в системе знаний, которая относится конкретному проекту. В этой записи делается минимум два блока: краткое описание проекта, над которым идет работа, и журнал работы над этим проектом. Что-то вроде такого:

# Сделать хорошо  

## Краткое описание  

- Нужно сделать хорошо по тикету MAKEITCOOL-112  
- Менеджеры ожидают, что все будет хорошо.  
- Срок: вчера, но ждет до завтра  

## Журнал  

### 2025-03-18  

Работал над концепцией и выяснял, что значит "сделать хорошо"  

### 2025-03-19  

Сижу и пишу код.  

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

Почему не писать в ежедневный журнал?

Дело в том, что в ежедневный журнал попадает слишком много текучки. Там обычно записи по нескольким проектам, а еще с пяток напоминалок про то, что и кому было обещано. Собрать из этих записей что-то внятное по отдельному проекту будет трудно.

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

При этом в CLOG не попадут сами документы, созданные в рамках проекта — только ссылки на них. Этим мне не нравятся MOC для рабочих проектов. MOC требует ссылок на другие документы в базе знаний. Программист пишет код, что в карту сохранять? Ссылку на код? В CLOG один из основных блоков — журнал. Вот туда всегда есть что записать, пока делаешь проект.

Почему не делать в трекере?

Цель CLOG — помочь себе вести проект. Цель записи в тикете проекта — показать другим, что проект движется. CLOG ведется только для личного использования. Это позволяет быть в нем менее сдержанным в формулировках, не заботиться об орфографии и пунктуации. Если вы понимаете, что там написано, хорошо. Часть информации можно дублировать и там, и там. Приоритет за CLOG: сначала в него, потом в тикет, если нужно.

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

Внедрение

Я начал внедрять CLOG на последних нескольких проектах. И пока эта запись в блог носит больше теоретический характер. Я не знаю, попадет ли этот метод в мою ежедневную практику или нет.

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

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

Также надо бы поступать с входящими запросами. С ними еще сложнее. Надо иметь не только пометку в соответствующем CLOG, но и в каком-то общем месте, где хранятся входящие запросы без ответа. У меня такого места пока нет.