Как планировать на день задачи, в которых нужен рациональный тип?

Я решаю это постановкой задачи в помидорном виде: «20 минут заниматься Х». Это некоторый компромисс: и для обезьянки конкретика (ставим таймер и погнали, таймер прозвонил — задача выполнена), и для рационального сигнал (эта задача для тебя, поставили таймер — пора включаться в работу).

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

А иногда перерыв все же нужен — тогда продолжаю работать помидорами. Потом в «сделанном» ещё фиксирую, сколько реально помидоров ушло на задачу, чтобы оценить разрыв план-факт)

У меня точно такая же проблема. Я черчу чертежи и приходится думать. Разбиваю на отдельные элементы и пишу "Потупить над валом таким-то 10 минут", "Потупить над фланцем таким-то 20 минут", "Потупить над чертежами 30 минут". Отдельно в экселе есть план того, что надо сделать. Не задачи - план. Иногда, достаточно смотреть в план, что б делать. Иногда, надо писать задачи и засекать время, что б "завестись" и приступить к работе.

«Добавить функциональность» - почти всегда проект, а не задача. Имеет смысл найти минимально пригодный результат (Если бы дедлайн был завтра, то что я сделал бы сегодня?) и подумать, есть ли какой-нибудь шаг, который приблизит к этому результату. И уже вот этот шаг и станет задачей.

По примеру. На мой взгляд, рациональный тип должен один раз продумать разработку готового решения "Отзывы", которое впоследствии будет браться обезьянкой.

Если задача на 1-3 часа с подключением рационального типа, то это, скорее всего, проект. Может есть примеры более приближенные к описываемой проблеме?

Мне кажется, что это проект, а начальные задачи для Обезьянки уже сформулированы в посте:

1. делалось ли что-то подобное на других сайтах, может, взять оттуда?
2. есть ли готовое решение для данной админки?

Следующие задачи сформулируются по результатам решения двух первых.

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

Я сама задачи такого типа, как вы описали, вообще не ставлю задачами, а только планирую временными блоками в календаре. Типа вот тут 1,5 часа я занимаюсь этим проектом. Когда время пришло, открываю и смотрю, что там надо сделать, над чем подумать и т.д. Не делю на задачи для рац типа и обезьяны, потому что они могут очень уж близенько чередоваться, заманаешься сортировать.

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

Лично для меня на практике задачки по типу "подключить комментарии к сайту" - скорее проект на довольно много часов, если явно нет готового решения, но даже так нужно разобраться, сделать и протестировать качественно.

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

Далее определить первый шаг первого этапа (1-й шаг - провести разведку в своих проектах и в интернете), а лучше два первых шага (2-й шаг - создать директорию под новую ветку проекта, скопировать файлы). И всё! - больше не надо, а то по ходу выполнения могут измениться условия, и все досконально прописанные шаги обнулятся, придётся переписывать заново (я, условно, думал, что найду готовое решение в своём старом проекте, но оказалось, что там другая структура объектов в блоке с комментариями - нужно переписывать, а это совсем путь в другую сторону от первоначального плана). А за этими шагами уже затянет в работу и новые шаги будут на лету автоматически проявляться и выполняться.

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

А внутри этапа можно ещё и помидорки до кучи добавить, чтобы были хоть какие-то перерывы в ходе выполнения этапа работ, чтобы хоть пару раз за пару часов встать и размяться...

Это, конечно, больше теория идеалистичная, но иногда даже получается применять в полном объеме 😁

Вы пипец как недооцениваете свою обезьяну!!

• Она ленивая, а не тупая.
• Она знает всё, что знаете вы.
• Если она понимает как начать, после включения в контекст задачи, её может засосать в "состояние потока" (это желательно тоже ограничивать в разумных пределах, но нет ничего страшного чтобы иногда работать 3 часа подряд если работается и прёт)
• имейте под рукой бумажку для записывания проскакивающих идей, т.к. обезьянка в потоке может пролететь мимо чего-то важного, оставьте себе возможность к этому вернуться.

На мой взгляд никакого проекта тут нет. Просто одна потоковая задача с подзадачами и небольшой вариативностью решений.

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

И в таких исходных данных ваша обезьяна прекрасно решит эту задачу, гораздо быстрее чем вы думаете.

Рациональный тип у руля фактически 1-3 часа в сутки и нужен он для планирования, организации и генерации сложных неожиданных решений(хотя с последним в некоторых случаях обезьяна справляется лучше - у неё фактор неожиданности выше).
Всё остальное обезьяна умеет делать сама, просто не всегда хочет.

Обезьяна, как рабочий с лопатой, ей надо точно сказать: где начать копать и в какую сторону, до забора или до обеда, а если в глубь роем, то остановиться после нахождения нефти или алмазов?
Лопата просто у всех разная, кто-то ей код пишет, кто-то книги, кто-то ей людей лечит, кто-то ей руководит.

Заметила в ваших рассуждениях мысль, что рационального лучше всего включать утром, а потом в течение дня можно забыть о его существовании.
Да, рациональный наиболее свеж сутра, но если утром его не перегружать, то он и до вечера вполне может дожить.
У меня по специфике работы много таких задачек, которые тоже как-бы проекты, но как-бы и нет - прилетает типа вот тут проблема, нужно разобраться. Включаю рационального, чтобы задать проблеме вопросы, а ответы на них ищет обезьянка. Она всё нашла, снова включаю рационального, делаю выводы и задаю новые вопросы. И так в цикле условно 10 мин рац типа + 30 мин обезьянка, за несколько итераций можно решить любую сложную задачу и не заморить рационального. Переключения также не страшны, если делать их в середине цикла, т.е. после получения очередной пачки вопросов от рационального. На этом вполне можно сделать перерыв или заняться чем-то другим - обезьянка потом без проблем вернётся к поиску ответов (вопросы-то уже есть).

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

Я обычно выделяю себе кусок "продуктивного времени" где-то часа на 1.5-2. К началу этого куска подхожу восстановленный, отдохнувший, с полным баком мыслетоплива и примерным набором задач-"проектов", которые хочу сделать. И эти 2 часа делаю задачи, в том числе и плохо сформулированные, непонятные и т.д. Переформулирую, декомпозирую если надо, и делаю. Сделал задачу/проект - сразу беру следующую. За это время обычно сильно устаю, поэтому после продуктивного времени обычно следует заранне запланированное время восстановления и отдыха.

Объединил для себя комменты, в один алгоритм, попробую его применить, пока решил поделиться получившейся заметкой:

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

Рациональный тип у руля фактически 1-3 часа в сутки и нужен он для планирования, организации и генерации сложных неожиданных решений.

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

В Джедайских Техниках мы все-таки про то, как "делать приемлемо", нежели про "делать на пять с плюсом".

Исходя из этого не понятно как планировать на день задачи требующие размышлений Рационального типа

Возможное решение
Приходит с утра Рациональный тип, определяет примерные временные затраты, по необходимости, чтобы не упороться в перфекционизм, находит минимально приемлемый результат (Если бы дедлайн был завтра, то что я сделал бы сегодня?), после которого надо остановиться и подумать или просто закрыть задачу как выполненную.

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

Формулирует первые 1, 2 ну максимум 3 простых, обезьяно-понятных шага, в первом этапе проекта, (для погружения)
примеры первых шагов:

• делалось ли что-то подобное? Может, взять оттуда?
• Провести разведку готовых решений и в интернете.
• Найти или создать новую ветку проекта.
• Тупить одну помидорку над найденным решением.

И всё! - больше не надо, а то по ходу выполнения могут измениться условия, и все досконально прописанные шаги обнуляться, придётся переписывать заново.
Постановка задачи в помидорном виде: «20 минут заниматься Х». Это некоторый компромисс: и для обезьянки конкретика (ставим таймер и погнали, таймер прозвонил — задача выполнена), и для рационального может быть сигнал (эта задача для тебя, поставили таймер — пора включаться в работу).

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

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

Работаем
В процессе работы или тупления, возникают навязчивые мысли, отвлекающие от выполнения этапа, задачи или проекта. Чтобы не забивать ими голову и не бояться что "обезьянка" в потоке пролетит мимо чего-то важного, следует выгрузить их в один из Inbox и вернуться к ним позже. После включения обезьяны, в контекст задачи, её может засосать в "состояние потока" (это желательно тоже ограничивать в разумных пределах, но нет ничего страшного чтобы иногда работать 3 часа подряд если работается и прёт)

После выполнения этапа или полной сессии помодоро, делаем перерыв на отдых.

Зовем Рационального типа на построение следующих шагов. Если уже большая усталость или в принципе сегодня буйная обезьяна (очень ей надо в соцсети), то задачи могут мельчать и мельчать. И иногда помогает помодорка на "потупить над проектом пристально разглядывая все места" это не сложно совсем, ещё и с чайком.
В процессе тупления появляются понятные идеи, что ещё сделать, складывается картина проекта в голове. Обычно записываются ещё задачки. Для записи задачек нужно каждый раз на пол минуты приглашать человечка.

вечером или по окончани оценивааем и коректируем ожидания (Калибровка), или подход к задачам подобного типа.

Мне кажется, что корень проблемы здесь в том, что в таких задачах кроме явного слоя (собственно написать код для "Отзывов") присутствует очень значимый скрытый слой, иногда по объему работы превышающий слой явный. Этот скрытый слой - понимание (= построение модели) контекста задачи, сопутствующее задаче исследование. Как тут в ответах примеры приводили - поискать существующий код, прояснить все не до конца понятные места и возможные расхождения в понимании разных участников и т.п.

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

Честно говоря, мне кажется, что среди базовых типов объектов в Джедайских техниках (Задача, Проект, Кейс, Идея, Образ жизни) недостает типа "Исследование". Этот тип похож на Кейс, но все-таки отличается, потому что неизвестен конечный результат и результаты промежуточных шагов требуют специфической обработки.

На практике я стал гораздо лучше чувствовать себя с такими задачами после того как под каждую программистскую задачу (которые я рассматриваю как Проект) пишу раздел в своей персональной википедии (использую ZimWiki, если кому-то интересно, ее можно просто взять и использовать без дополнительного изучения). Сваливаю туда все: вопросы, на которые нужно найти ответы, и сами ответы, любую справочную информацию по контексту задачи (используемые инструменты и способы их использования, наброски архитектуры, ссылки на существующий код с похожим функционалом), само ТЗ и уточнения по нему, любые свои мысли по проекту. Стараюсь организовать это в духе Цеттелькастен, но без излишнего формализма. Получается такая смесь документации по проекту и отчета о выполненой работе. Ставить Задачи для обезьяны в рамках работы над этими заметками гораздо проще, потому что атомарной задачей делается добавление чего-то в заметки (написать ответ на какой-то вопрос или написать список вопросов, проверить какую-то гипотезу, задать вопрос постановщику задачи о неясном месте в ТЗ и т.п.) . А по мере роста количества заметок задачи по кодированию тоже становятся "Задачами для обезьяны". Только хочу подчеркнуть, что написание заметок и написание кода - это не две стадии работы, они идут параллельно обычно.

Этот раздел персональной вики я считаю настолько же значимым результатом исходной задачи, как и собственно получившийся код. И для этого есть все основания: на основе этих заметок легко пишется документация по коду, с их помощью легко вернуться в контекст задачи и через час, и через год (я такие разделы по задачам не удаляю после завершения задачи, а переношу в Архив), и качество мышления над задачей резко повышается за счет того, что мысли четко формулируются в письменном виде, а не крутятся мутной кашей в голове (подробнее об этом можно погуглить "Мышление письмом" Анатолия Левенчука, вот, например, https://ailev.livejournal.com/1513051.html). В общем, очень рекомендую делать что-то подобное, моя программистская жизнь очень упрощается, когда я использую этот подход.

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

Дальше управление может передаваться произвольно.