Система обеспечения для "автоматических weekly/yearly заметок"

При всей "игрушечности" целевой системы (и отсутствия надсистемы), я все-таки решил попытаться описать систему обеспечения для всего того, что ранее описал.

Что я сейчас пытаюсь описывать

Я хочу описать систему обеспечения, т.е. некоторую систему, в результате "действия" которой на свет будет произведена "система автоматических weekly/yearly заметок".

Система, которая создаст систему для автоматического создания и связывания недельных и годовых заметок с ежедневными, состоит из "меня, который пишет нужный код на emacs-lisp".

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

Стадии ЖЦ и соответствующие практики

  • замысливание
    Сначала появилось в формате исчезающих заметок, затем они были переработаны в связный текст, описывающий потребность в системе. Рабочим продуктом этого этапа должно быть описание готовой системы как черного ящика.
  • проектирование
    На этапе проектирования будут определены основные элементы системы. Рабочим продуктом будет перечень документов (исходных кодов), которые должны быть созданы, а также архитектура всей системы, указывающая то, как соответствующие этим документам компоненты будут друг с другом связаны. Пример: Компонент "исходный код функции this-day-weekly" и компонент "шаблон weekly заметки". Связаны между собой: "функция this-day-weekly должна вставить в текущий daily документ ссылку на соответствующий weekly документ, а если он не существует, то создать его на основе шаблона".
  • создание
    Используя практики "программирование на emacs-lisp" и чтение документации, создать все требуемые документы.
  • тестирование
    При наступлении нового дня использовать org-roam-dailies-capture-today, чтобы проверить корректность создаваемых заметок. В случае, если результат не соответствует требуемому, удалить созданные файлы, после чего вернуться к этапу "создания" для исправления обнаруженных ошибок.
  • эксплуатация
    При создании исчезающих заметок с помощью org-roam-dailies-capture-today автоматически будет происходить создание и связь объединяющих weekly и yearly заметок.
  • утилизация
    Для утилизации системы требуется удалить из рабочей конфигурации редактора документы (исходный код) функций и шаблонов, удалить из шаблона ежедневных заметок точку активации входной функции.

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

Так получилось, что из всех подролей менеджера к этому проекту удалось "применить" только роль CTO. Здесь нет никакой оргструктуры, а команда состоит из одного человека, поэтому оргстроитель и лидер оказались не у дел. Единственным ресурсом, за которым нужно следить, является личное время, поэтому финансист может составить отчет о потраченном времени (2 помодоро ночью с 27 на 28 ноября). Операционный менеджер как обычно бессилен в своих попытках чем-либо управлять.

Ну, роль лидера все же, полагаю понадобилась. Хотя бы для того, чтобы помочь себе встать в роль ученика и, в частности - написать такой яркий пост. Спасибо!

Лидер в этом случае подобен заклинателю погоды. Если “в результате его действий” туча пошла куда надо, то он “справился со своей работой”. Если нет, то “обстоятельства были сильнее”. В данном случае мне было интересно написать такой пост.

Спасибо за пост!

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

Анна не зря вам настаивает на необходимости соблюдения первого шага СМ - найти надсистему.

Давайте на примере. Я сейчас нафантазирую, что надсистема это вы читающий учебник системного мышления (в освобожденное за счет автоматизации время:)), а целевая система - генератор weekly/yearly заметок, с основной функцией генерировать заметки.
Потребность надсистемы - дополнительное время. И решение этой потребности мы будем проверять в момент приемки - целевой системы.
Только - приемки у вас не оказалось в стадиях ЖЦ:) Это для игрушечного примера - не плохо. Мне важно только подсветить места, которые оказываются упущенными и могут привести к необходимости - уже переучивать себя.

Дальше, этап замысливание. Это всегда этап работы предпринимателя. Тут кроме черного ящика, должны быть оценены - максимальные издержки и возможная выгода (глава о предпринимательстве - №9). Т.к. роли предпринимателя выявлено не было - мы упускаем и его рабочие продукты.

Остальные стадии выделены - верно, и практики и рабочие продукты отмечаете - хорошо. Только роли бы добавить - тестировщик, разработчик… И сразу появится объем работ для оргстроителя.

А за боль операционного менеджера - грущу вместе с вами:)

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