Цели и задачи

Внимание пожалуй, самая важная составляющая разумной деятельности.

В нашем мозгу порядка 100 триллионов синапсов и десятки миллиардов нейронов. Обмен информацией происходит, по оценкам нейрофизиологов, примерно с частотой 200 Гц в активном режиме.

Считаем: $inline$200 * 100 * 10^{12} = 2 * 10^{16}$inline$ бит. Учитывая, что нейрон это не одна арифметическая операция, а своего рода микропроцессор, то получаем, что у нас петафлопсный суперкомпьютер на борту. А есть мнение, что и эксафлопсный.

Какой бы он ни был мощный ресурсы ограничены. Более того

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

Речь, слух, зрение, касания, ощущения, эмоции, эмпатия
Ох! Какая пошла!, Ой! Он косо на меня посмотрел!, Каким ты был таким ты и остался.
Это ни плохо, ни хорошо. Этонормально!
Есть, конечно, отклонения, но в основном это так.

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



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

Выбор цели

Цель оправдываЮт средства. Обратное утверждение скорее ложное.
Есть амбиции это здорово! Вы умеете мечтать отлично! А вот у соседа...
Но невозможно на велосипеде слетать на Луну. Пешком не дойти до Америки. На яблоне бананы не растут.
Собираясь в далекий путь, проведите ревизию в гараже. Может у вас там автомобиля нет. Может самого гаража. В итоге далекий путь будет получасовым походом в магазин.

Цель или целевой вектор легко описывается математически. Это список параметров и их значений (конкретных или диапазон).
Например: высота-100мм, ширина-50мм, вес-0.5кг, скорость-3м/с, количество ног-от 3 до 4шт.
Размер списка так же может варьироваться.

Выбор целевого вектора, конечно, зависит от имеющихся и планируемых в будущем ресурсов. Цель Построить крышу за 10 дней не имеет большого смысла если нет стен, а только фундамент. А если есть пожалуйста.
Включать параметр Оптимальное время кормления кота в целевой вектор, если его у вас нет (кота) бессмысленно, ровно как и Количество воды для полива помидоров, если нет дачи.
Сделать робота с размерами 50х50х50мм невозможно, если в качестве мозга у вас имеется только Raspberry Pi.

Это, на самом деле, здорово! Это ограничивает область поиска. Фокусирует на решении, которое уже подсказывает жизнь, а не вгоняет в некоторое подобие шизофрении А может..., А если....
Инновации это хорошо главное не потратить весь семейный бюджет на создание передового гоночного суперкара.


Установка порога целевой функции, которая выражает некую сумму свертку многомерного целевого вектора.

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

Поток

Замечали, когда вы погружаетесь в рабочий процесс, то вам не очень нравится, когда отвлекают?
Это происходит, потому что все мощности заняты, и процесс социального взаимодействия понижается в приоритете. Конечно, можно переключиться, но на это надо некоторое время. Плюс, ко всему прочему, теряется пресловутый Поток, которого так трудно достичь.
Мыслители, ученые, программисты вообще любят уединение таким образом, отсекается ненужная информация.

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

Поиск решения

То, что нам на ум приходят решение это не значит, что мозг их сразу формирует. Происходит перебор вариантов громадных масштабов. Часто проблемы не решаются годами и даже столетиями. Фокус + комбинаторика. Появляются новые технологии расширяется функциональный базис.

Множество людей, занятых решением одинаковых задач, идут к цели разными путями. Если решение находится, то не у всех. И так же верно, что разные люди приходят к похожим решениям и даже к одинаковым.

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

Время. Так же, если мыслить категориями целей, то мы обозначаем разумный временной период их достижений. Обычно у нас это вырабатывается само собой, по крайне мере для простых задач вроде: Сходить в магазин, Повесить люстру, Почистить зубы.
Мы ведь не делаем это неделю, верно?

Время очень удобный параметр для определения таких свойств как: мощность вычислительной системы, достижимость цели при существующих ресурсах, корректность выбранной модели для вычислений.

Мы можем даже сделать такой трюк выполнить расчет по 10% выделенного времени на 10 разных вычислительных архитектурах и увидеть, с высокой долей вероятности, лучшую систему для данной задачи.
Почему? Потому что одна архитектура может не дотянуться до цели и близко.
Это провал, Карл!

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

$inline$Ошибка = Цель - Результат$inline$

Точность, в процентах, можно определить как: $inline$Точность=100*(Цель-Ошибка)/Цель$inline$. Это как вариант.

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


И, как показывает практика, битва за каждый процент после 80% точности усложняет систему на порядок. После 95% точности разговор уже идет о долях процента.

Обратная сторона фокуса локальный оптимум. Обычно мы разбиваем задачу и решаем ее по частям. Это методика. Она работает. Но, добиваясь нужных нам параметров отдельного модуля, мы не сможем добиться оптимальных параметров системы в целом.
Яркий пример: отделы предприятия. У них у всех разные и достаточно противоречивые цели. И если директор не будет грамотно их регулировать, то получим результат как в басне Лебедь, Щука и Рак.


Баланс. Все вышеперечисленные концепции надо грамотно сбалансировать. Все хорошо в меру.
Выставляются приоритеты целей, которые постоянно меняются. Это нормально.

Хочешь жить умей вертеться!

Если мы сами не ставим себе цели, то внешний Мир делает это за нас.
Многие говорят: Это карма!, когда постоянно попадают в один и те же ситуации. Но если выработать алгоритм поведения в них, решить задачу, проблема обычно уходит. Появляется новая проблема и цикл повторяется.
Ошибки, фрустрация взрыв мозга и срочная перестройка.

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

Мотивация

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



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

Мотивация для ИИ происходит так: подаем на вход ИНС громадный набор данных и добиваемся максимума целевой функции соответствия выходным данным, полученным и проверенным в результате мыслительной деятельности людей.

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

Страсти и эмоции появляются, когда есть свобода выбора.

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

Все взаимосвязано, поэтому мы ходим по кругу.
Но если у нас есть цель, мы всегда знаем, куда нам идти.
Вот и весь фокус!

Зачем нужны цели? Как их формулировать? Какие проблемы могут возникнуть? По случаю Я.Субботника Pro я подготовил доклад, основанный на нескольких годах опыта ведения целей для команд в Яндексе.

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

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



Дисклеймер: о чем я не расскажу в докладе? Я не буду вам рассказывать всякие энциклопедические определения что такое SMART, OKR, KPI. Все это уже сто раз изложено в Википедии. Вы, наверное, и сами слышали все эти вещи. Если нет, быстрый поиск с помощью вашего любимого поисковика даст вам ответ. Там полно очень хороших статей. Буквально сегодня ночью проверял.



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

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

Зачем вести цели?

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

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



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



Вторая народная мудрость надо просто очень-очень много работать, брать побольше и кидать подальше, не забывать отдыхать. Такая трудолюбивость всё перемелет, и будет неважно, какие у вас цели. Это все, конечно, правда. Но лишь отчасти.



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

Второе: если вы руководитель, то возникает проблема одну и ту же вещь можно сделать очень большим диапазоном разных способов. И вам нужно понимать, как оценивать на ревью то, что сделали ваши подчиненные.

У меня есть доклад, посвященный нашей системе ревью. Там я подробнее рассказываю именно о том, как устроена наша внутренняя RPG: с уровнями, левел-апами, оценками и т. д.

Жизненный цикл

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



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



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

Что у нас есть? Разные части нашего процессного фрактала. Есть шестимесячные интервалы ревью сотрудников.



Каждые три месяца мидревью, где мы подводим промежуточные итоги ревьюшного периода.



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



И те самые двухнедельные спринты.



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



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

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



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

В рассказе про измеримость я приведу антипример. У меня есть крылатое (внутри Яндекса) понятие чекбоксовые цели.

Чекбоксовые цели

Это антипаттерн. Ваши цели, скорее всего, не очень хороши, если они звучат как сделать новую версию компонента X, запустить сервис Y или отрефакторить Z. Почему это плохо?

• Потому что, как я уже говорил, способов достижения целей в нашем мире очень много. Усилия на эти достижения расходуются суперНЕлинейно. Можно, например, сделать, тяп-ляп или сделать суперхорошо: упороться, написать документацию, все автотесты, а потом еще и выложить это в опенорс, что тянет за собой еще больше трудозатрат. То есть можно вообразить большую шкалу возможностей, как именно можно сделать ту или иную вещь.
  
  И если цель чекбоксовая, то совершенно нет ответа на вопрос насколько проработанным мы запускаем сервис X? Как много сил мы на него тратим?
• Если нет способа померить вещи друг относительно друга, эта приоритизация усложняется. Неизбежно возникнет ситуация, что нужно сделать и это, и это. Если задача сделать X, то вы не сможете по понятному курсу разменять это на что-то другое.
• Усложняется оценка результата. Например, вам нужно оценить две команды. Без процесса ревью и калибровок вы не сможете обнаружить, что одна команда поработала тяп-ляп, MVP-стайл, а вторая всё сделала хорошо, на века и очень подробно.

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

Создание метрики и определение таргетов часть работы над целью

Может возникнуть вопрос, что что-то очень сложно померить. И иногда уже нужно начинать бежать. Уже понятно, что нужно сделать сервис X или рефакторинг Y, но еще нет никаких метрик, которые позволили бы это измерить. Мы не понимаем, какие таргеты хотим себе поставить в качестве целевой картины. Как быть?

Мы используем паттерн о том, что сам процесс создания метрики и определения таргетов уже является частью работы над целью. Необязательно блочить начало работы над целью, если она у вас сформулирована не до конца.



Я приведу пару примеров из наших реальных целей. В Яндексе есть команда, которая занимается так называемой Красотой Серпа, делает его красивее. Когда она появлялась, была только общая идея. Нате вам столько-то человек, делайте.

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


Суть системы: мы делаем сравнение side-by-side старой версии и новой. Затем считаем сумму позитивных изменений от каждого нашего внедрения на протяжении какого-то участка времени.

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



Второй пример в контексте работы над метриками один из наших старейших контуров, команда, которая занимается скоростью интерфейсов.

Когда она начиналась, тоже был общий посыл: сделайте, пожалуйста, чтобы Серп грузился быстрее. Но как измерить, быстрый он или нет? Были претензии вида: Я вот у себя открываю на телефоне, мне чего-то кажется медленно. Поисковики конкурентов быстрее!. Чтобы начать эту работу делать, не нужно было формулировать именно метрику. Мы знали банальные вещи: если пересылать по сети много байтиков, много кода запускать в JS, то будет долго. Давайте начнем что-то делать, а попутно собирать реальные метрики, понимать, как мы будем это измерять.

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


Параллельно ребята работали над достижением содержательной цели сокращения этих самых байтиков.

Измерить неизмеримое

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



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

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

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

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

Пара ключевых слов, которые помогут в опросах пользователей: csi nps. Но я думаю, идея понятна.

Метрика антибага

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

Сейчас расскажу, как она устроена. На ней можно проиллюстрировать сразу несколько моментов.



Первое: мы построили для команд суммарные графики взвешенного количества багов. То есть мы считаем в плавающем окне количество возникающих багов и расставили им веса соразмерно их приоритету. У нас миноры, тривиалы, нормалы, критикалы и блокеры отличаются друг от друга на порядок. У минора и тривиала вес 1, у нормала 10, у критикала 100, у блокера 1000. Получается такой график, который отражает, сколько сейчас на сервисе багов с учетом их приоритетов.

Второе: мы начали строить такие графики отдельно для багов, которые нашла сама команда и тестировщики команды, и для тех, которые зарепортили внешние пользователи. Затем мы подвесили составную часть цели, провели таргет. У нас внутри этот процесс называется zero bug policy. Но понятно, что zero это такой недостижимый идеал и у каждой команды в каждый момент времени может быть разный zero. Там определен threshold что вес не больше 50 или 100.

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

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

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

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

Вы просто расставляете этим критериям веса, проценты и говорите, что одно влияет на 40%, второе на 20%, третье на 40%. Вот такой пример, и эта метрика позволяет более-менее унифицированно на десятки команд в Яндексе распространять работу над антибагом.



Мы вновь подходим к ключевому слову баланс. Его нужно пытаться найти. Я расскажу про несколько балансов, сам факт наличия которых нужно держать в голове, когда вы занимаетесь процессом целеполагания.

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



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

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

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

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

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

Нужен баланс между двумя формулировками: вовремя переориентироваться под изменившуюся реальность и сдаться при первых трудностях. Иногда вы можете начать что-то делать и обнаружить, что задачи оказались сложнее, чем ожидалось. Или же случились внешние факторы, например коронавирус или еще что-то. Очень велик соблазн, руководствуясь принципом Agile, гибко подстроиться под изменившуюся реальность и, например, занизить себе KPI, отказаться от каких-то целей или еще чего-то. Тут мы оказываемся в той же самой ситуации, что и при первоначальном целеполагании, только уже в динамике.

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

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

У нас конкретно в этом месте существуют понятные методологии размена одно на другое. Но и остальные, такие же конфликтующие цели важно оценивать с достаточного отдаления. По какой форме можно было бы разменять одно на другое?



И еще пара таких аналогий и картинок про баланс. Он, в том виде, в котором я его для себя формулирую, бывает двух типов:

1. Бывает баланс кататься на кайте. Это когда естественная сила гравитация, ветер, что-то еще тянет вас в одну сторону, а вам нужно изо всех сил сопротивляться.
   
   Сюда входят вещи, связанные с перфекционизмом. Андрей Миронов сказал: Надо стараться делать всё хорошо, а плохо оно само получится. При прочих равных, вы скорее совершите больше ошибок, чем меньше. Поэтому нужно прикладывать специальные усилия, направленные на исправление багов: при прочих равных людям больше нравится делать обычные фичи.
2. Второй тип баланса я называю велосипедным. Это когда у вас есть две крайности, и между ними нельзя свалиться одинаково ни в одну, ни в другую сторону. Тут уже сложнее. Мне кажется, что первый вид баланса сильно проще: просто бери и с максимализмом изо всех сил делай что-то одно. Второй баланс требует тонкой настройки системы, ощущения того, в какую из сторон лучше не сваливаться. Но даже понимание того, какой вид баланса сейчас перед вами, может вам помочь в развесовке ваших сил.

Итого

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

Короткое резюме всего доклада: целеполагание это сложно. Вы, возможно, обнаружите, что само по себе занятие целеполаганием отнимает существенное количество времени. Но оно того стоит! По крайней мере, это мое оценочное суждение, основанное на моем личном опыте.

Я очень рад, что мы вообще пришли к системе с целями и продолжаем её эволюционировать, совершенствовать. Все эти усилия, как мне кажется, окупаются.

Здесь могла бы быть реклама нашего или любого вашего инструмента, потому что плюс-минус любой инструмент ведения задач или целей может быть использован. Просто поищите в любимом поисковике [название вашего инструмента, пробел, цели]. Вы наверняка найдете статью, которая описывает, как именно это сделать. Спасибо за внимание. Желаю вам всем такого же удачного попадания в цели, как на этой гифке.