Как планировать на день задачи, в которых нужен рациональный тип?
Публичный постКогда мы формулируем задачку для обезьянки, один из критериев звучит как "Задача выполнима с минимально возможным использованием мозга"
И вот тут для меня пока есть один неясный момент. Рассмотрим его прям сразу на примере.
Возьмем для примера обычного веб-разработчика
Задача: добавить функционал "Отзывы" на сайт. (Верстка прикладывается. ТЗ есть. Конечный результат понятен)
Задача на 1-3 часа. Но она по сути своей не для обезьянки, так как нужно включить рационального типа, который сначала подумает - а делалось ли что-то подобное на других сайтах, может, взять оттуда? А есть ли готовое решение для данной админки? А как лучше прикрутить: вот так или так? А лучше вот эту функцию использовать или другую? И т.п.
Если сразу допустить обезьянку и сделать бездумно на автомате, то это будет не всегда оптимально.
Если все продумывать изначально в момент планирования, а потом уже ставить максимально конкретно (функции а, b, с; использовать там и тут), то как тогда будет выглядеть рабочий день?
Разработчик утром включает рационального типа, он сначала продумывает одну задачу, ставит максимально конкретно, потом переходит к другой задаче и т.д. Это тогда будет на полдня планирование, так как в разработке ты можешь продумывать 20-30-40% от основного времени всей задачи. Получается, продумал всё, осталось допилить - и прерываться на другие задачи? Ну странно ж?
Пример для разработчика, но мне кажется, что в любой профессии куча задач такого типа.
Вот и вопрос - как тут быть?
У меня (я руководитель) пока так: запланировал задачи на день, формулировки по ДТ, задачу начинаю с продумывания, подключения рац типа. Пока мыслетопливо есть, особых проблем нет. Продумал - сделал. Иногда могу отложить, или вообще делегировать.
Если задача начинает откладываться, то пробую переформулировать, переделать на первый явный шаг и т.п.
Мне кажется, что это проект, а начальные задачи для Обезьянки уже сформулированы в посте:
Следующие задачи сформулируются по результатам решения двух первых.
Я решаю это постановкой задачи в помидорном виде: «20 минут заниматься Х». Это некоторый компромисс: и для обезьянки конкретика (ставим таймер и погнали, таймер прозвонил — задача выполнена), и для рационального сигнал (эта задача для тебя, поставили таймер — пора включаться в работу).
А дальше, когда первая помидорка закончилась, можно действовать по ситуации. Часто бывает так, что мозг уже разогнался, помидоры ему дальше не нужны, целевой уровень концентрации достигнут и проще уже доделать, чем прерываться каждые 20 минут.
А иногда перерыв все же нужен — тогда продолжаю работать помидорами. Потом в «сделанном» ещё фиксирую, сколько реально помидоров ушло на задачу, чтобы оценить разрыв план-факт)
Вы пипец как недооцениваете свою обезьяну!!
На мой взгляд никакого проекта тут нет. Просто одна потоковая задача с подзадачами и небольшой вариативностью решений.
Итого: пришел с утра Рациональный, прикинул первые три подзадачи по задаче, определил примерные временные затраты, по необходимости задал минимально приемлемый результат после которого точно надо остановиться и подумать или просто закрыть задачу как выполненную, организовал вокруг себя время и пространство так, чтобы можно было выполнить эту задачу(убрал телефон, перенес совещания, повесил табличку не беспокоить), после чего пошел курить бамбук пока снова не понадобится.
И в таких исходных данных ваша обезьяна прекрасно решит эту задачу, гораздо быстрее чем вы думаете.
Рациональный тип у руля фактически 1-3 часа в сутки и нужен он для планирования, организации и генерации сложных неожиданных решений(хотя с последним в некоторых случаях обезьяна справляется лучше - у неё фактор неожиданности выше).
Всё остальное обезьяна умеет делать сама, просто не всегда хочет.
Обезьяна, как рабочий с лопатой, ей надо точно сказать: где начать копать и в какую сторону, до забора или до обеда, а если в глубь роем, то остановиться после нахождения нефти или алмазов?
Лопата просто у всех разная, кто-то ей код пишет, кто-то книги, кто-то ей людей лечит, кто-то ей руководит.
«Добавить функциональность» - почти всегда проект, а не задача. Имеет смысл найти минимально пригодный результат (Если бы дедлайн был завтра, то что я сделал бы сегодня?) и подумать, есть ли какой-нибудь шаг, который приблизит к этому результату. И уже вот этот шаг и станет задачей.
Заметила в ваших рассуждениях мысль, что рационального лучше всего включать утром, а потом в течение дня можно забыть о его существовании.
Да, рациональный наиболее свеж сутра, но если утром его не перегружать, то он и до вечера вполне может дожить.
У меня по специфике работы много таких задачек, которые тоже как-бы проекты, но как-бы и нет - прилетает типа вот тут проблема, нужно разобраться. Включаю рационального, чтобы задать проблеме вопросы, а ответы на них ищет обезьянка. Она всё нашла, снова включаю рационального, делаю выводы и задаю новые вопросы. И так в цикле условно 10 мин рац типа + 30 мин обезьянка, за несколько итераций можно решить любую сложную задачу и не заморить рационального. Переключения также не страшны, если делать их в середине цикла, т.е. после получения очередной пачки вопросов от рационального. На этом вполне можно сделать перерыв или заняться чем-то другим - обезьянка потом без проблем вернётся к поиску ответов (вопросы-то уже есть).
А режим, когда за несколько часов сутра рациональный выжимается до суха и потом весь день проживается обезьянкой - это чисто для стратегического планирования и только по выходным, строго один день в неделю. Каждый день так жить, имхо, нереально.
У меня точно такая же проблема. Я черчу чертежи и приходится думать. Разбиваю на отдельные элементы и пишу "Потупить над валом таким-то 10 минут", "Потупить над фланцем таким-то 20 минут", "Потупить над чертежами 30 минут". Отдельно в экселе есть план того, что надо сделать. Не задачи - план. Иногда, достаточно смотреть в план, что б делать. Иногда, надо писать задачи и засекать время, что б "завестись" и приступить к работе.
Я знаю одного товарища, который делит свои дни. Один день он - человек идей, а следующий день - человек труда. То есть, всё планирование в один день, а вся фигачка на следующий. И так через день и повторяется. В итоге, в день, когда он человек идей, остаётся довольно много свободного времени, а вот когда человек труда - там он фигачит, пока глаза не закроются, потому что в режиме обезьяны это несложно.
Я сама задачи такого типа, как вы описали, вообще не ставлю задачами, а только планирую временными блоками в календаре. Типа вот тут 1,5 часа я занимаюсь этим проектом. Когда время пришло, открываю и смотрю, что там надо сделать, над чем подумать и т.д. Не делю на задачи для рац типа и обезьяны, потому что они могут очень уж близенько чередоваться, заманаешься сортировать.
Набравшись мудрости в комментариях, и обобщив свои представления, как бы можно было решить эту задачу эффективно и в рамках понятий Джедайских техник, скажу так:
Лично для меня на практике задачки по типу "подключить комментарии к сайту" - скорее проект на довольно много часов, если явно нет готового решения, но даже так нужно разобраться, сделать и протестировать качественно.
Первое что бы сделал: разбил бы проект на этапы (готовая полезность по результату этапа, то есть система ещё не работает, но фундамент, условно, уже построен).
Далее определить первый шаг первого этапа (1-й шаг - провести разведку в своих проектах и в интернете), а лучше два первых шага (2-й шаг - создать директорию под новую ветку проекта, скопировать файлы). И всё! - больше не надо, а то по ходу выполнения могут измениться условия, и все досконально прописанные шаги обнулятся, придётся переписывать заново (я, условно, думал, что найду готовое решение в своём старом проекте, но оказалось, что там другая структура объектов в блоке с комментариями - нужно переписывать, а это совсем путь в другую сторону от первоначального плана). А за этими шагами уже затянет в работу и новые шаги будут на лету автоматически проявляться и выполняться.
Этапы же нужны, чтобы была точка прерывания "непорочного круга работы над проектом". Если нет точки, в которой можно остановиться, взглянуть на проделанную работу, оценить предстоящую и глянуть в список дел на сегодня, то есть большой риск упереться в одно это дело на весь день без остатка, не сделав ничего другого из списка дел на сегодня.
А внутри этапа можно ещё и помидорки до кучи добавить, чтобы были хоть какие-то перерывы в ходе выполнения этапа работ, чтобы хоть пару раз за пару часов встать и размяться...
Это, конечно, больше теория идеалистичная, но иногда даже получается применять в полном объеме 😁
Я обычно выделяю себе кусок "продуктивного времени" где-то часа на 1.5-2. К началу этого куска подхожу восстановленный, отдохнувший, с полным баком мыслетоплива и примерным набором задач-"проектов", которые хочу сделать. И эти 2 часа делаю задачи, в том числе и плохо сформулированные, непонятные и т.д. Переформулирую, декомпозирую если надо, и делаю. Сделал задачу/проект - сразу беру следующую. За это время обычно сильно устаю, поэтому после продуктивного времени обычно следует заранне запланированное время восстановления и отдыха.
По примеру. На мой взгляд, рациональный тип должен один раз продумать разработку готового решения "Отзывы", которое впоследствии будет браться обезьянкой.
Если задача на 1-3 часа с подключением рационального типа, то это, скорее всего, проект. Может есть примеры более приближенные к описываемой проблеме?
Объединил для себя комменты, в один алгоритм, попробую его применить, пока решил поделиться получившейся заметкой:
Один из критериев формулировки для внутренней обезьяны, звучит как "Задача выполнима с минимально возможным использованием мозга"
Рациональный тип у руля фактически 1-3 часа в сутки и нужен он для планирования, организации и генерации сложных неожиданных решений.
Если задача требует работы рационального типа >1 часа, то это вероятно проект.
В Джедайских Техниках мы все-таки про то, как "делать приемлемо", нежели про "делать на пять с плюсом".
Исходя из этого не понятно как планировать на день задачи требующие размышлений Рационального типа
Возможное решение
Приходит с утра Рациональный тип, определяет примерные временные затраты, по необходимости, чтобы не упороться в перфекционизм, находит минимально приемлемый результат (Если бы дедлайн был завтра, то что я сделал бы сегодня?), после которого надо остановиться и подумать или просто закрыть задачу как выполненную.
Если задача длительная (дольше пары часов), прикидывает и разбивает проект на этапы. С хоть какой-то полезностью по результату этапа, то есть "система ещё не работает, но фундамент, условно, уже построен". Этапы нужны, чтобы была точка прерывания "непорочного круга работы над проектом". Если нет точки, в которой можно остановиться, взглянуть на проделанную работу, оценить выполненную и еще предстоящую, глянуть в список дел на сегодня, то есть большой риск упороться в перфекционизм и упереться в одно это дело на весь день без остатка, не сделав ничего другого из списка дел на сегодня.
Формулирует первые 1, 2 ну максимум 3 простых, обезьяно-понятных шага, в первом этапе проекта, (для погружения)
примеры первых шагов:
И всё! - больше не надо, а то по ходу выполнения могут измениться условия, и все досконально прописанные шаги обнуляться, придётся переписывать заново.
Постановка задачи в помидорном виде: «20 минут заниматься Х». Это некоторый компромисс: и для обезьянки конкретика (ставим таймер и погнали, таймер прозвонил — задача выполнена), и для рационального может быть сигнал (эта задача для тебя, поставили таймер — пора включаться в работу).
Если и этапы или шаги у задачи длительные, можно ее тоже на Pomodoro разбить, чтобы были хоть какие-то перерывы в ходе выполнения этапа работ, чтобы хоть пару раз за пару часов встать и размяться...
Если ближайшая задача окажется сложновата, то мозг, в зависимости от вашей точки зрения может, всё равно запрокрастинировать несмотря на таймер.
Организуем вокруг себя время и пространство так, чтобы можно было выполнить эту задачу(убрал телефон, перенес совещания, повесил табличку не беспокоить), после чего пошел курить бамбук пока снова не понадобится.
Работаем
В процессе работы или тупления, возникают навязчивые мысли, отвлекающие от выполнения этапа, задачи или проекта. Чтобы не забивать ими голову и не бояться что "обезьянка" в потоке пролетит мимо чего-то важного, следует выгрузить их в один из Inbox и вернуться к ним позже. После включения обезьяны, в контекст задачи, её может засосать в "состояние потока" (это желательно тоже ограничивать в разумных пределах, но нет ничего страшного чтобы иногда работать 3 часа подряд если работается и прёт)
После выполнения этапа или полной сессии помодоро, делаем перерыв на отдых.
Зовем Рационального типа на построение следующих шагов. Если уже большая усталость или в принципе сегодня буйная обезьяна (очень ей надо в соцсети), то задачи могут мельчать и мельчать. И иногда помогает помодорка на "потупить над проектом пристально разглядывая все места" это не сложно совсем, ещё и с чайком.
В процессе тупления появляются понятные идеи, что ещё сделать, складывается картина проекта в голове. Обычно записываются ещё задачки. Для записи задачек нужно каждый раз на пол минуты приглашать человечка.
вечером или по окончани оценивааем и коректируем ожидания (Калибровка), или подход к задачам подобного типа.
Мне кажется, что корень проблемы здесь в том, что в таких задачах кроме явного слоя (собственно написать код для "Отзывов") присутствует очень значимый скрытый слой, иногда по объему работы превышающий слой явный. Этот скрытый слой - понимание (= построение модели) контекста задачи, сопутствующее задаче исследование. Как тут в ответах примеры приводили - поискать существующий код, прояснить все не до конца понятные места и возможные расхождения в понимании разных участников и т.п.
Вопросов подобных может быть очень много, их список заранее неясен, непонятно, какие их них важнее, если вы их как-то перечислили - остается непонятным, как понять, что не упустили какой-то важный именно в данном случае вопрос. Работы над изучением этого всего требуется много, а задача на это изучение явно не поставлена, поэтому непроизвольно усилия на исследование экономятся, оно проводится по минимуму, "в уме", или не проводится совсем, соответственно - понимание исходной задачи остается довольно туманным, и рациональному типу, и обезьяне над ней работать тяжело, обоих не дозовешься.)
Честно говоря, мне кажется, что среди базовых типов объектов в Джедайских техниках (Задача, Проект, Кейс, Идея, Образ жизни) недостает типа "Исследование". Этот тип похож на Кейс, но все-таки отличается, потому что неизвестен конечный результат и результаты промежуточных шагов требуют специфической обработки.
На практике я стал гораздо лучше чувствовать себя с такими задачами после того как под каждую программистскую задачу (которые я рассматриваю как Проект) пишу раздел в своей персональной википедии (использую ZimWiki, если кому-то интересно, ее можно просто взять и использовать без дополнительного изучения). Сваливаю туда все: вопросы, на которые нужно найти ответы, и сами ответы, любую справочную информацию по контексту задачи (используемые инструменты и способы их использования, наброски архитектуры, ссылки на существующий код с похожим функционалом), само ТЗ и уточнения по нему, любые свои мысли по проекту. Стараюсь организовать это в духе Цеттелькастен, но без излишнего формализма. Получается такая смесь документации по проекту и отчета о выполненой работе. Ставить Задачи для обезьяны в рамках работы над этими заметками гораздо проще, потому что атомарной задачей делается добавление чего-то в заметки (написать ответ на какой-то вопрос или написать список вопросов, проверить какую-то гипотезу, задать вопрос постановщику задачи о неясном месте в ТЗ и т.п.) . А по мере роста количества заметок задачи по кодированию тоже становятся "Задачами для обезьяны". Только хочу подчеркнуть, что написание заметок и написание кода - это не две стадии работы, они идут параллельно обычно.
Этот раздел персональной вики я считаю настолько же значимым результатом исходной задачи, как и собственно получившийся код. И для этого есть все основания: на основе этих заметок легко пишется документация по коду, с их помощью легко вернуться в контекст задачи и через час, и через год (я такие разделы по задачам не удаляю после завершения задачи, а переношу в Архив), и качество мышления над задачей резко повышается за счет того, что мысли четко формулируются в письменном виде, а не крутятся мутной кашей в голове (подробнее об этом можно погуглить "Мышление письмом" Анатолия Левенчука, вот, например, https://ailev.livejournal.com/1513051.html). В общем, очень рекомендую делать что-то подобное, моя программистская жизнь очень упрощается, когда я использую этот подход.
Я это обходил так. Задача для обезьянки не сделать админку а посвятить написанию админки 30 минут.
От обезьянки требуется понять что вот сейчас вполне можно что то делать 30 мин подряд, запустить помидорку и переключить то что может отвлечь в режим не беспокоить на эти 30 мин.
Дальше управление может передаваться произвольно.