Наставничество. Цели на неделю и цели на день

У Падавана есть 10 целей до конца февраля. Что делать дальше?

Я рекомендую сделать визуализацию достижения каждой цели на бумаге. Для этого в блокноте рисуем название цели на отдельной странице. Одна цель - одна страница. В самом низу страницы пишем результат, который мы хотим получить. SMART-результат если цель сформулирована в общем виде. Если не можете придумать этот SMART-результат, то представьте себе что должно изменится через 2 месяца если вы сделаете все идеально. Я называю это "Impact".

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

Далее для 3-х Focus целей сформулируйте 3 цели на неделю. 3 результата на неделю согласно текущему плану. Для остальных 7 целей выделите 1 самую важную задачу, которую нужно сделать. Я называю это "@next" цель или "следующий шаг"

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

В результате должен получится следующий "TODAY" список:

1. Цель 1 на день (Today) - это я ДОЛЖЕН сделать сегодня
2. Цель 2 на день (Today) - это я ДОЛЖЕН сделать сегодня
3. Цель 3 на день (Today) - это я ДОЛЖЕН сделать сегодня
4. Цель 1 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
5. Цель 2 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
6. Цель 3 на неделю (Saturday) - я постоянно вижу и фокусируюсь на ней
7. Next-цель по цели №4 - делаю когда появится возможность
8. Next-цель по цели №5
9. Next-цель по цели №6
10. Next-цель по цели №7
11. Next-цель по цели №8
12. Next-цель по цели №9
13. Next-цель по цели №10

При этом цели и визуализация плана по их достижению есть на бумаге. 

TODAY cписок всегда под рукой - тоже на бумаге или в электронном виде. 

Какие есть проблемы у Падавана здесь?

1) Цель лучше сразу формулировать в виде результата. То есть писать не процесс, а результат с метрикой. 

"Я сделал 1-3 слайда презентации по SpecByExample"

2) Всегда есть конфликт с текущим распорядком дня, где нет времени на выполнение этих задач. Вернее время выделяется домашнее, вечернее. "Я приду домой с работы и сделаю эти задачи". Это не работает. Эти задачи должны быть сделаны ASAP утром. Нужно выделять утром время на их выполнение и защищать это время от внешнего воздействия. Вам всегда будут мешать делать что-то полезное для себя, и вы не должны "прогибаться под мир".

3) Цели на день слишком крупные, и потому они не выполняются. В результате они переносится на следующий день. И так бесконечно. Цели на день нельзя просто переносить на завтра если вы их не сделали. Нужно их вычеркнуть и написать снуля, анализирую вчерашние неудачи.

- Я почитаю книгу про Agile Results (не сделано)

- Я прочитал 1-10 дни из книги Agile Results (прочитал 1-2 дни)

- Я прочитал 3-5 дни из книги Agile Results (прочитал 3-4 дни)

- Я прочитал 4-6 дни из книги Agile Results (Ура, сделал) 

Agile results - результаты за 2013 год

Уже пару лет используют технику Agile results.
Из тех логов что удалось найди. Выполнено

1. 37 целей на месяц
2. 161 целей на неделю
3. 424 целей на день

Из крупных/важных/интересных целей на 2013 год запомнилось:

• Подал налоговую декларацию на 2010-2011 чтобы получить налоговый вычет (без специальной цели год не мог это сделать) 
• Запустил первый тренинг
• Внедрил Impact Mapping (теперь в любом процессе системного мышления его выстраиваю) 
• Перешел на CEO распорядок дня (я так называю ложиться спать в 23 часа и просыпаться в 6 утра)
• Начал бегать по городу по утрам
• Внедрил Power engagement для повышения продуктивности через управление энергией
• Заработал первые деньги как Agile Coach
• Научился кататься на роликах (лет 5 собирался духом)
• Съездил в Америку
• Съездил в Париж
• Запланировал отдых на НГ

Но теперь это кажется таким простым. И 10 целей на январь-февраль будут сложнее. 

Лучшие книги 2013 года (из прочитанных)

У меня была цель - прочесть 50 книг за год.
Я прочитал только 36. Но даже эти 36 сильно изменили мое мышление. Как обычно жаль что я не прочел эти книги раньше.
Я думал что практика легко заменяет теорию - я сильно ошибался. 

Если интересно какие книги я бы рекомендовал, то они далее. Без приоритетов.
Ссылки на Amazon есть на самом Shelfari. У меня можно взять PDF версии.

Делать продукты через оказывание положительного влияния на наш Мир

Как проводить изменения в своей жизни и жизни окружающих

Управление не временем, а энергией для более продуктивной жизни

Lean Startup мышление в разработке продуктов

Практическая инструкция по запуску продуктов/стартапов 

Дополнение к системному мышлению о том как измерять неизмеряемое

Теперь любой бизнес/продукт рассматриваю с точки алого и голубого океанов

Что нужно измерять и как влиять на процесс

Куча всего нового про управление людьми в рамках Agile мышления

Уровни лидерства. Раскрыла глаза о том, что Эксперт это самый первый уровень. Самый простой.

Пусть будет ровно 10 книг. 

А вы проводите ретроспективы для своей жизни?

Вроде бы есть традиция под НГ анализировать что произошло за прошедший год и строить планы на следующий. Или мы в разных компаниях делали анализ результатов проекта и строили вывода как мы будем делать лучше в следующей проекте. Отличная стратегия, но почему делать это нужно раз в год или раз в полгода.

В Scrum есть отличная практика делать ретроспективу в конце каждого спринта. Я делаю ретроспективу в конце каждой недели в пятницу утром пока голова соображает.

Это выглядит как запись в дневнике в формате

1. Мои победы/успехи за неделю
2. Мои неудачи
3. Что изменить

Анализирую относительно того, что случилось за неделю (это обычно про победы) и того, как достигнуты недельные цели (это обычно неудачи).

Главное признать что

1. что проблемы есть (здесь важна техника ставить корректные цели)
2. что результаты не достаточны
3. что это твоя вина

Из моих побед следует решение что я должен продолжать делать. Из неудач следует что нужно изменить или начать делать. Здесь нужно потратить минут 5-10 на анализ (см. всадник, слон + окружение) и сразу принять решения/действия на следующую неделю.

В обычном контексте я бы не смог принимать такие изменения - они достаточно "дорогие" и "не приятные". Вести дневник, бегать по утрам? Ха. Но когда ты видишь какую проблему это может решить и у тебя есть остается мотивация на достижение цели - это работает горадно лучше.

Половина изменений по результатам ретроспективы оказываются мусором - не работают для меня, не толкают к цели. Но value от остальных 50% достаточно для прогресса.

Итак, что дает личная ретроспектива:

1. Рефлексия на стеройдах. Не случайная, постоянная, плановая.
2. Анализ текущих проблем, которые самые Важные сейчас, так как не дают достигать самых Важных для вас целей.
3. Ведет к изменениям, которые проще внедрить с использованием "остывающей", но еще "живой" мотивации.
4. Возможность найти простое решение, и не использовать Heroic mode. Когда вы решаете что нельзя быть тряпкой и тратите на цель больше усилий чем могли бы.

Планирование и визуализация

Размышлял над проблемой достижения целей.
Есть 10 целей на ноябрь-декабрь.
Стратегия №1:

• Нужно каждый день делать небольшой шаг к каждой цели и в результате ты придешь к ней. Например, Бизнес-Молодость или подобное на Smartprogress.ru 

В результате по истечению времени ты оказываешься в какой-то точке на ПУТИ достижения цели, не достигнув ее. Это походит - как мы спринты исполняем. Мы просто делаем что успеем, и в конце спринта смотрим что получилось. "Burndown chart" у нас не работает.

Стратегия №2

• Запланируй как будешь достигать цель и только после этого начни что-то делать.

Это лучше, но планирование 1-2 часа в самом начале для цели на 2 месяца недостаточно. Все слишком сильно меняется.

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

Так же решил перенять burndown chart из Scrum и визуализировать проблему. В результате есть такое.

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

Определение целей

Как определить Цель продукта

Долго время я делал ИТ проекты/продукты, и все это время мне не было никакого дела до Цели (с большой буквы). Ну как не было - цель всегда была. Она указывается в пункте 2.4 в каждом ТЗ и ЧТЗ, и мы всегда свободно вписывали туда все что считали нужным. Часто путали что такое "цель" и что такое "назначение" - не знаю смогу ли я сейчас это правильно определить.

Далее был Agile и Scrum. Члены настоящей Agile-команды должны понимать куда идет продукт/видеть цель. И это не проблема. Часто рассказываешь Что и Зачем - они вроде кивают, понимают.

Потом пришел Гойко Аджич (опять он) и сломал мне все мироощущение со своим Impact mapping.

Оказалось что все это время в проектах не было Цели - вернее Цель была ложной. И по моей текущей модели это корень зла всех проблем:

1. Большинство Fail-ов в разработке software 
2. Бесполезные ИТ-системы, которые никто не использует (особенно государственные системы)
3. Бесконечные списки замечаний от Заказчика, когда ты приходишь к нему в конце проекта с восклицанием "Подписывай акты, Чувак! Все круто получилось!" 

IMHO, это все следствие того, что Цель проекта не была согласована между Заказчиком и Исполнителем, причем обеим сторонам она казалась такой очевидной.

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

"Нет метрики - нет цели" (с) Т.Д.

И правда - без метрики на цель самой цели быть не может. Какая же метрика?
Наша метрика на цель - пройти испытаний и передать Систему в промышленную эксплуатацию, подписать акты.
Их метрика на цель - Мы не знаем??? Просто решите нашу проблему, вы же профессионалы.
И тоже как то не сходится.

Но вернемся к Impact mapping.
Представим что есть Заказчик, у него есть проблема. Мы собрались вместе подумать что и как мы будем делать. И первый вопрос - "Какая наша цель, и какая метрика на ее достижения?"
Варианты:

Вариант А. 
Исполнитель подсказывает самый популярный и естественный вариант. "Цель проекте - это создание системы А. Метрика цели - система работает." Далее, если желание создавать Impact map не пропало, то рисуется какая-то хрень, состав которой следует из ТЗ. Разбежались. 2-10 месяцев и имеем результат, который описан в самом начале.

Вариант В.
Так как Impact map рисует Исполнитель, то через пару минут появляется такая мысль. Цель - заработать денег. Метрика - 15 млн. руб. Здесь всегда интересно следующее. Цель должна быть прозрачна, то есть с ней должен согласится Заказчик. Как происходит тот диалог, на котором Исполнитель сообщает Заказчику, что конечная цель всего мероприятия в том, что Исполнителю нужно заработать 15 млн. И как на это должен согласится Заказчик. С такой целью весь Impact mapping хочется закопать поглубже и забыть.

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

Итак, после долгих измышлений мы взяли проблему Заказчика и решили трансформировать ее в Цель.
Для примера представим, что есть процесс управления инвестиционными проектами. Нас пригласили его автоматизировать.

Вариант С.
Спасибо, Виктор. Цель - создание системы по автоматизации процесса управления инвестиционными проектами. Метрика - процесс управления стал быстрее. Беда в том, что метрика и цель совсем никак не связаны, вернее притянуты за уши. Мы боимся признать, что процесс создания системы это никак не цель, это лишь одно (но видимо ГЛАВНОЕ) наше предположение для достижения цели. Мы боимся так как процесс достижения цели не полностью зависит от нас, и значит любые проблемы по достижению это цели - будут нашими проблемами. Проще не брать эти проблемы на себя - проще просто сделать систему по "нашему" же ТЗ, которое бедный Заказчик имел неосторожность подписать.

И последний вариант.
Например, Цель - сделать процесс согласования инвестиционных проектов быстрее.
Метрика
1) Название - время согласования инвестиционных проектов
2) Способ - Время от инициации проекта до получения статуса "Согласовано"
3) Текущие значение - 60 дней
4) Минимально допустимое - 20 дней
5) Целевое - 5 дней

И уже после этого мы начинаем создавать Impact map, придумывать предположения и договариваться с Заказчиком что и зачем мы будем делать.

А вы понимаете Цель своего текущего проекта?

Идея №38. Бизнес

Новая идея для валидации. Попал на сайт - http://game.molodost.bz/ и http://molodost.bz/entry/
Сделал те же самые выводы что и неделей ранее

1. Нужно ставить больше целей - здесь это 10 одновременных целей за 3 месяца
2. Цели должны быть более амбициозные, сложные, valuable

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