Продолжаю свою серию постов по заданиям курса “Моделирование и Собранность”.
Прошлый раз был уже 5 недель назад, но это не потому, что я так люблю откладывать прохождение курса, а потому, что я ждал обновления 7ого раздела, в котором, согласно комментарию, я мог узнать что-то полезное для написания этого поста. Хотя пока, кажется, что не так это актуально оказалось, и вообще теория в разделах не так уж сильно помогает выполнять задание…
А “благодаря” тому, что пост отложил, ещё и сильно пришлось напрячься, перелистывая прочитанную ранее теорию и предыдущие посты с комментариями - так что лучше бы не откладывал 
В целом про задание хотелось бы сказать, что оно трудное, и описываемый далее результат выполнения я бы скорее назвал “неудовлетворительным” для преподавателя, хотя сам я им, может быть, и удовлетворюсь
Целей 1) определить реальное количество выполняемых работ «мимо плана» и начать вырабатывать привычку делать ее явной и 2) уменьшить объем работ, который вы выполняете - я скорее не достиг, хотя ценность в попытке достижения, в проходе по предлагаемыем чеклистам определённо какая-то есть. Пишу общий пост для двух подразделов задания, чтобы не плодить фейл-репортов…
По самому первому пункту ввести правило «не делаю ничего, что не записано в планировщике». Все работы должны «проявляться» через экзокортекс, я уже начал отвечать в прошлом посте:
- Привычки “не делаеть чего-либо, не описанного в экзокортексе” у меня нет, и нет уверенности, что стоит бросаться в эту крайность. Если задача плюс-минус на несколько минут, то время на её описание и трекинг в экзокортексе уже сопоставимо с выполнение самой задачи. А если таких задач много (кажется, мой случай), и они не являются подзадачами одной более общей, то получается, что неучтённой в экзокортексе остаётся немалая часть продуктивной мощности.
Нужно добавить, что несколько минут - это не обязательно “пара минут”, а может быть и пара десятков минут. И объединять в какой-то осмысленный класс такие задачи бывает всё-таки совсем непонятно как - я пытался: в ходе попыток, правда, понял, что часто это всё-таки можно записать в подзадачи для каких-то более высокоуровневых задач. И получается, что как раз из-за таких незапланированных подзадач, возникающих по ходу выполнения основной задачи, срок исполнения и увеличивается сильно в сравнении с изначально планировавшимся для этой задачи.
Для “неклассифицируемых” мелких задач, как и коллега, выходом вижу планировать в “буффер”.
Срочные задачи тоже добавляем в очередь на выполнение. Нет задачи в экзокортексе – она не выполняется.
Тут в момент “прилёта” я предпочитаю быстро распознавать, стоит ли за задачу браться действительно срочно, и настолько ли она срочная, чтобы я приложил усилия по переключению контекста, или всё-таки ещё можно успеть довести до какого-то более оптимального состояния выполнявшуюся в данный момент основную задачу.
Часто получается, что если реально срочно всё горит, то тебе уже не до внесения этого “прилёта” в экзокортекс… но надо бы постараться постфактум, наверное, вносить такие задачи (заодно и с примерной оценкой, сколько времени на эти задачи было израсходовано). Не скажу, что я эту практику освоил хорошо, но продолжаю пытаться…
В конце дня / начале следующего подведите итог: сколько задач вы записали и выполнили, а сколько оказались скрытыми. Пометьте, к какой мощности относились эти задачи.
Вот здесь всё плохо… Мои попытки вести такие списки заканчивались скорее неудачно.
-
Основной проблемой вижу слабую структурированность таких списков (у меня возникали трудности с разбивкой задач по проектам, и вообще с выделением проектов, хотя я думаю в сторону PARA Экзокортекс. Часть 2. Ведение заметок - Подготовительные курсы - SystemsWorld Club). В итоге список с десятками элементов всего за день становится неудобоваримым, что уж говорить про попытки делать это не только один день.
-
Задачи записываются условно с утра, по ходу их выполнения возникают “прилёты”, а в конце дня (и тем более начале следующего) уже не всегда помнишь, какие из работ относились к каким записям в списке (если не уделил немало времени созданию описания, а не только названия задачи). Да и нет гарантий, что не забыл постфактум записать какие-то задачи.
-
Время затрекано коряво, из-за корявости интеграции каких-нибудь trackingtime.co / clockify.me c coda.io / notion.so. Жду получения доступа к ClickUp 3.0, либо когда-нибудь запрограммирую в предыдущих двух этот функционал по-нормальному… Трекинг времени предполагался, конечно, не в этом задании, а в предыдущем, но считать просто “количество” задач может быть крайне странно, с учётом большого разброса по их размеру.
-
Плюс ко всему вся эта самоменеджерская работа, особенно не поставленная на поток, а выполняемая ad-hoc отнимает уйму усилий, и конкретно в эти дни “попыток её выполнения” продуктивность по основным задачам падает, так что кажется, получаешь весьма смещённые оценки своей средней работоспособности.
Определите, что из реально выполняемых работ можно:
- Не делать?
- Делегировать?
- Ускорить их выполнение (автоматизировать, сделать иначе)?
Среди последних моих программистских задач по рабочему проекту (основные), кажется, что можно довольно многое было “не делать” в плане того, что это не пошло в конечное приложение, однако не сделав этих задач “руками”, не поразмыслив моделирование/программированием, нельзя было бы перед выполнением понять, что это можно “не делать”.
Делегировать другим разработчикам пока не представляется возможным (некому), хотя в будущем надеюсь кто-нибудь из помощников появится… заодно и будет понятнее, какие задачи не надо делегировать, потому что их вообще лучше “не делать”
А с ускорением выполнения какими-нибудь Github Copilot я экспериментирую, но пока много пользы от этого не получаю (с классической автоматизацией, кстати, у меня вроде всё хорошо).
Если говорить про “неосновные” задачи, по личным проектам, то там уже кажется простор для оптимизации ещё меньше, как-то эволюционно он порешался до устраивающего оптимума.
Посмотрите на свой список проектов. Есть ли среди них те, которые сейчас неактуальны и только отъедают время? Можем ли их:
- Убрать
- Отложить
- Ускорить завершение?
Вот с этим, как я уже писал ранее, тяжело. Некоторые проекты, например, выглядят примерно бесконечными, и надо научиться их разбивать на что-то более ограниченное по времени. Какие-то, кажется, надо дробить на более мелкие в плане их целевых систем и типичных рабочих продуктов. Но понимания тут пока мало, даже с учётом того, что я довольно далеко забежал в курс Системного мышленя уже. Продолжаю изучать тему, и надеюсь когда-то получить здесь хорошие результаты.