Зачем нужны цели? Как их формулировать? Какие проблемы могут возникнуть? По случаю Я.Субботника 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. Второй тип баланса я называю «велосипедным». Это когда у вас есть две крайности, и между ними нельзя свалиться одинаково ни в одну, ни в другую сторону. Тут уже сложнее. Мне кажется, что первый вид баланса сильно проще: просто бери и с максимализмом изо всех сил делай что-то одно. Второй баланс требует тонкой настройки системы, ощущения того, в какую из сторон лучше не сваливаться. Но даже понимание того, какой вид баланса сейчас перед вами, может вам помочь в развесовке ваших сил.

Итого

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

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

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

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