Golos Blogs

Прилетело очередное письмо от Scott Young “Set Goals in the Middle” (оригинал, англ: www.scotthyoung.com/blog/2018/01/31/set-goals-in-the-middle). Касающееся постановки целей (которую трудно переоценить как в языковых проектах, так и за их рамками - так что, разбираемся подробнее. Кроме того, в качестве примера Scott приводит свой языковой проект Year without English (это когда он учил 4 языка, по кварталу на язык, с погружением - в смысле, жил в стране изучаемого языка это время), что добавляет ценности данному тексту в наших глазах ;) ). Итак:

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

У вас может возникнуть вопрос, как такое вообще возможно? Разве цель не определяет проект в целом? На самом деле, есть немало аспектов целеполагания/планирования, часть из которых необязательна вначале.

Как правило, цель проекта содержит следующие элементы (qualities):

общая цель/мотив (привести тушку в форму, выучить французский);
конкретная цель (сбросить N кг, говорить свободно);
временнЫе рамки (за 6 мес.);
ограничения или методологию (потреблять меньше калорий, тренироваться каждый день);
общие затраты времени/усилий (несколько часов в неделю).

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

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

Вопрос, который следует себе задать: в какой момент времени все эти элементы должны “сойтись”? Далеко не все из них нужны к началу проекта.

Впервые Scott применил такую стратегию целеполагания (Set Goals in the Middle) к языковому проекту (Year without English). Многие элементы были фиксированными: время (3 месяца на страну), метод (не говорить по-английски, некоторые элементы обучения), требуемые усилия (практически полное погружение (full time)).

Что не было жестко зафиксировано - конкретная цель (уровень владения языком). Поскольку Scott не был уверен, чего можно достичь за установленное время - он не заморачивался детальной постановкой цели (говорить свободно или сдать определенный тип языкового экзамена).

Поначалу Scott думал, что это может быть недостатком (по сравнению с целеполаганием в его предыдущем проекте, MIT Challenge (это когда он проходил за год 4-летнюю магистерскую программу Computer Science по программе MIT)) - когда он с самого начала поставил амбициозную цель.

Со временем Scott выяснил, что такой подход (Set Goals in the Middle) работает лучше, так как позволяет скорректировать ожидания и уровень сложности (challenge level), когда у вас уже побольше информации. Поэтому Scott применил тот же подход в изучении китайского (для сдачи языкового экзамена HSK 4). Решение сдавать этот экзамен (сделать это целью языкового проекта) он принял только через месяц пребывания в Китае, когда уже мог оценить скорость своего прогресса в китайском.

Что приводит нас к правилу: когда цель с высокой степенью неопределенности (на предмет достижимости того или иного результата за определенный отрезок времени), лучше эту цель устанавливать в середине проекта, а не в его начале.

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

Дополнительные аргументы в пользу более поздной постановки целей

Большинство литературы по постановке целей сходится в том, что:

постановка целей улучшает производительность;
трудные цели лучше, чем легкие;
обратная связь приносит пользу…

Поэтому Scott попытался найти контр-примеры, особенно для индивидуальных задач. Ну, и нашел, конечно же :) Вкратце: сложные цели требуют полной загрузки ваших когнитивных способностей, а мониторинг производительности - тоже требует загрузки когнитивных способностей… (и в целом это всё снижает продуктивность).

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

Применим ли такой подход для всех типов целей?

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

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

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

Как ставлю (и обновляю) цели я - и, да, я вовсе не призываю вас такой подход копировать: это, можно сказать, для повышения эрудиции :)

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

Цель, которая ставится вначале (приступая к проекту, или к интенсивной предпроектной подготовке - в общем, переход от “замысла” к “проекту”) - она пессимистична. В том смысле, что если этого результата (набора результатов) не достичь - то незачем в проект ввязываться, лучше заняться чем-нибудь другим. И, соответственно, по ходу проекта, если я вижу, что “не вписываюсь” даже в этот минимальный прогресс (достижения цели) - это серьезный повод, чтобы свернуть проект. Помогает избежать ущербной логики принятия решений в стиле “я уже ввалил сюда N часов/месяцев/долларов - давай ввалю еще M, а вдруг что-нибудь хорошее таки получится…”)

Ну и, по-хорошему, приходится управлять ведь не одним проектом, а портфелем/программой… Что требует дополнительного инструментария (но это уже выходит за рамки сегодняшнего поста). А вот увязывать цели одновременно реализуемых проектов (а также переиспользование результатов уже реализованных проектов для усиления текущих) - рекомендую.

P.S.: Для тех, кто не читал - ранее мы уже рассматривали несколько размышлений от Scott Young: