Смотреть доклад

SPL
Параллельно ребята работали над достижением содержательной цели — сокращения этих самых байтиков.
Измерить неизмеримое
Следующий вопрос, который может возникнуть: хорошо, мы хотим измерять и со скоростью фронтенда более-менее понятно — есть линейка, позвояющая засекать байтики. Но как измерить нечто вообще неизмеримое? С красотой вы придумали 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, отказаться от каких-то целей или еще чего-то. Тут мы оказываемся в той же самой ситуации, что и при первоначальном целеполагании, только уже в динамике.
Следите, чтобы вы не сдавались при первых трудностях даже в динамике, когда вы продолжаете менять развесовку целей, но и не бились лбом в стену, когда это уже не дает никакого результата.
Последнее, про что хочу рассказать на этом слайде, — про баланс между разными целями. Иногда цели начинают конфликтовать друг с другом.
У нас конкретно в этом месте существуют понятные методологии размена одно на другое. Но и остальные, такие же конфликтующие цели важно оценивать с достаточного отдаления. По какой форме можно было бы разменять одно на другое?

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

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

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

===========
Источник:
habr.com
===========
Похожие новости:

• [IT-инфраструктура, ERP-системы, CRM-системы, Управление проектами, Управление продуктом] Новый формат отдела разработки ПО
  
• [*nix, Управление проектами, Венчурные инвестиции, Бизнес-модели, Финансы в IT] Apple 4:1 – не упустите шанс заработать
  
• [Тестирование веб-сервисов, Управление проектами, Развитие стартапа, Будущее здесь, IT-компании] Определились победители открытого конкурса готовых цифровых решений «Инновации против кризиса»
  
• [Управление проектами, Управление персоналом, IT-компании] Простые средства информирования внутри компании
  
• [Разработка веб-сайтов, Программирование, ReactJS, Управление проектами] Как не закопаться в рефакторинге на фронте. Советы новичку
  
• [Интерфейсы, Usability, Звук] Впихнуть невпихуемое
  
• [Big Data, Разработка для интернета вещей, Управление проектами, Облачные сервисы] Мониторинг производственного оборудования: как с этим дела в России
  
• [Поисковые технологии] В поисках свежести
  
• [Ненормальное программирование, Python, Управление разработкой] «Я что-то накодил и все упало»: провалы в Python-разработке на Russian Python Week 2020
  
• [Обработка изображений, Управление проектами, Робототехника] Наша огромная гордость: мирные советские роботы-комбайны убрали первый урожай в южных регионах

Теги для поиска: #_interfejsy (Интерфейсы), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_tseli (цели), #_tseli_i_zadachi (цели и задачи), #_revju (ревью), #_metriki (метрики), #_blog_kompanii_jandeks (
Блог компании Яндекс
), #_interfejsy (
Интерфейсы
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
)