Буквально в каждой группе, где мы преподаем «Джедайские техники», находится человек (а то и несколько) у кого возникают вопросы по поводу возможности (и целесообразности) обезьянопонятных формулировок сложных задач.
Как правило, подобные вопросы сопровождаются возражением: «а у меня есть задачи, где надо думать» и добавляют: «я не могу такие сложные задачи декомпозировать на обезьянопонятные шаги».
Отдельная тема – это как же тяжело людям объяснять, что не надо декомпозировать. Ты десять раз говоришь, что «не надо декомпозировать, нужен только первый шаг», «нам не нужны все задачи до победного конца, нужна одна, максимум две задачи до следующей точки, когда мы остановимся и снова подумаем», но с упорством, достойным лучшего применения, ряд людей почему-то решают, что сложную исследовательскую задачу обязательно надо именно декомпозировать, разложить на составляющие, расписать на подзадачи и т.п. Еще раз – не надо декомпозировать. Декомопозировать – не надо. По крайней мере на мелкие обезьянопонятные задачи уж точно.
Но все равно, даже если мы пройдем этот этап с декомпозицией, то часто встает другая сложность: «У меня очень сложная задача и я не могу декомпо… отщипнуть первый обезьянопонятный шаг». Ее надо делать сразу и единым куском:
- Разработать архитектуру
- Проанализировать данные по продажам
- Составить квартальный отчет
- Исправить баг
- Вычитать техническое задание
Вот ничего более мелкого нельзя отщипнуть. Совсем. Что тогда делать?
И тут мы вспоминаем зачем нам вообще нужна ясная формулировка. Ясная формулировка является индикатором нашего понимания того, как мы начнем делать эту задачу. Если я не понимаю, как хотя бы начать выполнять задачу, то с хорошей вероятностью я «сначала с мелочью разберусь», а потом «мне на нее времени не хватило» (все потому, что «лучше расскажите, как правильно приоритеты расставлять»).
Конечно бывает так, что я могу выполнить задачу даже несмотря на ее небрежную формулировку. В этом случае никаких проблем. Но если вдруг я столкнулся со сложной задачей и никак не могу «нормально ее сформулировать», тогда эту задачу можно использовать как тренажер для отработки навыка обезьянопонятных формулировок и вот как это сделать…
Предположим, я запланировал эту большую, сложную и неделимую задачу на сегодня, давайте вернемся к ней завтра и посмотрим – мне удалось ли ее сделать? Если да, то все ок. А если нет, то есть два варианта: я хотя бы приступил к ее выполнению или «опять времени не хватило»?
Если я приступил, то у меня есть два вопроса:
- Что мне удалось сделать?
- Что мне осталось сделать?
Ответом на первый вопрос будет то, что мне раньше надо было записать в список задач, а ответом на второй вопрос – то, что в список задач стоит записать сейчас. Вот так и тренируемся, сначала думаем над тем, как надо было сформулировать обезьянопонятный шаг раньше, а потом, как только у нас появиться определённая насмотренность, это у нас будет получаться уже чуть ли не на автомате.
Например, я взялся за задачу «Разработать архитектуру» (конечно же «было невозможно» записать более понятный шаг) и все, что я смог сделать к концу дня это:
• Составить список модулей,
• Погуглить системы с аналогичными параметрами
Вот давайте посмотрим на эти результаты и подумаем, а было бы хорошо, если изначально в моем списке были бы именно они? На сколько бы сразу снизился прокрастиногенный потенциал задачи «Разработать архитектуру» и на сколько раньше я бы приступил к ее выполнению?
И понятное дело, если задачу «Разработать архитектуру» я так и не доделал, то на следующий день я переношу ее в иной формулировке. В какой? А на это меня должен натолкнуть ответ на вопрос: «Что мне осталось сделать?». Натолкнуть. То есть, мне надо будет подумать: «А с чего я продолжу доразрабатывать архитектуру?».
Так что, если вдруг вы сталкиваетесь со сложными задачами, и не понимаете, как правильно записать их в список – не страшно. Давайте на таких задачах учиться правильным формулировкам, анализируя постфактум что, как и в каком порядке я реально делаю, выполняя эту задачу.
Вот оно
Как же просто. Концептуально :)
При случае стопора с задачей, этим и занимался. Вычислял, что бы могло быть началом задачи. Теперь будет более понятный вопрос - как начнёшь делать...
В список задач надо записывать не задачу, а ответ на вопрос как ты начнёшь делать эту задачу?.
Если сталкиваюсь с такой сложной задачей, то просто начинаю представлять (лучше с закрытыми глазами), что я к ней приступаю, и ответ, с чего именно начать, часто возникает сам собой.
Отвечаю от имени таракана в голове 🪳🥸. «Недостаточна для того чтобы успокоить мой стресс. Проект очень важен, и когда я добавляю несколько задач в список, я чувствую меньше стресса, так как я думаю что вероятнее сделаю больше по данному проекту.
Отколыпнутая задача должна быть очень простой, соответсвенно я выполню ее быстро, и мне нечего дальше будет делать.
А этот проект для меня важен, поэтому я хочу чтобы у меня было 3-4 шага вперед, и мне было достаточно работы для уменьшен я стресса по поводу этого проекта»
Мой рациональный внутренний голос возражает:
-Записать задачу не значит ее сделать
-Через декомпозицию в моем задачнике я скорее всего добавлю больше стресса, так как надо все равно будет переписать задачи после первых выполненных задач
Я буквально в июне перечитывал вторую книжку и до меня наконец-то дошло, что такое обезьянопонятная задача. Теперь у меня половина задачек по работе начинаются с фразы "Открой терминал и перейди в такую-то папочку".
В большинстве случаев главное начать, а дальше оно как-то само едет.
Якобы Хемингуэй рекомендовал заканчивать с вечера работу в месте, где абсолютно точно понятно, что делать дальше. Тут срабатывает такой же механизм. Значительно сложнее потом себя затормозить и переключиться на другую работу.
Навык написания действий, понятных обезьяне, освоен. Но:
Часто бывает, что нет сил правильно записать действие. Хотя это какие-то там 30 секунд времени. Вот правда бывает такое состояние, что нет сил на такое, казалось бы, простое и нужное действие. Поэтому часто остается в изначальном виде (и так понятно, что нужно делать). Уточнение - такое бывает при обработке объектов в инбоксе.
Для себя так и не сформулировал правила, когда задачу нужно конвертировать в проект, а когда достаточно оставить задачу в виде одинарной задачи (хотя формально она бьется на несколько действий). По факту практикую и то и другое, не для меня это несовершенство в системе. Неудобно жить ни с большим кол-вом проектов, ни с большим кол-вом задач несконвертированных в проекты.
😱 Комментарий удален его автором...
Интересная мысль про оглядывание назад, чтобы понять как надо было отколыпнуть задачу.
У меня лично присутствует «таракан»-страх, что слишком простая единственная отколыпнутая задача недостаточна, почему не знаю. Просто сидит таракан в голове. А когда записываю две, три, пять задач подряд, по какому-то проекту то начинает усложняется обдумывание, так как нужно теперь определить что делать впервую очередь, что во вторую, а после выполнения первой, понимание вопроса эволюционирует, и приходится все доуточнять и перепланировать.
Действительно, декомпозиция в рамках задачника и методики Джедайских техник это «мартышкин труд» 🙈хаха
@cartmendum работаю продактом в крипто стартапе, у меня на работе случилась дилемма, что правильно в моем контексте?
С одной стороны я соглашусь, для внутренней мотивации хорошо, когда мы начинаем проект с первого шага (первых трех шагов), чтобы с максимальной вероятностью начать и реализовать новый проект. Так работает с моими личными пет проектами.
С другой стороны, мой руководитель требует ставить дедлайны на идеи на дискавери этапе, где требуется творчество и результат максимально неопределенный. Мне кажется он думает, если есть дедлайны, то более вероятно идеи быстрее реализуются, но мне кажется это иллюзия контроля, поскольку дедлайн я могу в ноушене поменять и я точно в него уложусь. Я работаю по канбану, не по спринтам, поэтому, если вдруг придет реквест на более важную идею в работу от руководителя, то дедлайн запланированных на неделю идей придется менять. Поэтому я стараюсь не добавлять в план на неделю идеи из дискавери бэклога, соответсвенно по сравнению с другими сотрудниками на планерке у меня видно мало задач и руководитель иногда спрашивает про мой текущий фокус, я не готов обычно к ответу, потому что это происходит иногда, я начинаю перечислять и получается неловко. После общего митинга, требует показать свои бэклоги и просит ставить дедлайны, там где можно - Петля замкнулась.
Вопрос: продвигать своему руководителю концепцию с первым шагом, а потом задавать вопрос что делать дальше?
Или с учетом требований руководителя попадать в петлю с дедлайнами?
*Меня микро-менеджмент демотивирует. Доверие и договоренности держат в тонусе
Я думаю, что он биться что в непонятных задачах можно застрять на непонятное время.
Но это очень хороший повод поговорить с самим руководителем ;-)
Дедлайн в исследовательской задаче - это понятие весьма размытое. А результат, скорее всего, определен - нужно понять, имеет ли смысл вкладываться в эту идею или нет.
При такой постановке задачи все становится сильно проще: поступает новая идея и по умолчанию ответ: "нет, вкладываться не стоит". А дальше, сколько есть времени ты пытаешься опровергнуть этот ответ. Много времени - много попыток опровержения. Мало времени - мало попыток.