Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Как измерять качество Когда команда решает всерьез заняться качеством своего продукта, чаще всего первым шагом становится определение набора метрик, которым это самое качество определяется, вторым – постановка целей вокруг их улучшения, а третьим – изменение процессов таким образом, чтобы метрики действительно подросли. Все круто, все довольны, тимлид получает премию, а сеньоры – оценки "выше ожиданий" на перфоманс ревью. Как всегда рациональный Виталий Шароватов напоминает, что качество – субъективно, а, значит, любые метрики могут использоваться только как сигналы о том, что, возможно, качество меняется. При этом объективно измерить его невозможно. Вместо этого он предлагает следующий алгоритм: 👉Выберите набор метрик, которые, по вашему опыту, коррелируют с важными аспектами внешнего или внутреннего качества. 👉Следите за метриками с помощью карт Шухарта, которые помогают отличать незначительные флуктуации метрик от существенных отклонений. 👉При появлении пиков или провалов в метриках анализируйте их причины, и исправляйте их. 👉Регулярно пересматривайте свой набор метрик и ставьте под сомнение их корреляцию с качеством.

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

Где у руководителей точки роста Неплохая модель для того, чтобы порефлексировать о том, на развитии каких ключевых поведений вам стоит сфокусироваться как руководителю. Под фокусом здесь подразумевается влияние на бизнесовые цели компании, под автономией – то, насколько в среднем велико влияние других людей и прочих вводных на ваши решения. 1️⃣Low Focus, Low Autonomy - Вы нечасто думаете про цели компании. - У вас нет понимания, как конкретные проекты связаны с общей стратегией. - Вы в последнее время не инициировали никаких стратегических проектов. - Чаще всего вы делаете то, что вам говорят другие. - Как технический лид вы идете по пути наименьшего сопротивления, выбирая безопасные и абстрактные цели вроде "уменьшаем техдолг" или "рефакторим легаси". 2️⃣Low Focus, High Autonomy - Вы постоянно начинаете какие-то инициативы, бизнесовая польза которых неочевидна. - Вы отвечаете за разработку технической стратегии, не понимая стратегии компании. 3️⃣High Focus, Low Autonomy - Вы нацелены на получение бизнесового результата, но отвечаете за экзекьюшн, а не постановку целей. - Все, что вы делаете, определяется не вашими решениями, а внешними факторами. - Вы редко сопротивляетесь каким-то решениям или предлагаете альтернативы им. 4️⃣High Focus, High Autonomy - Вы активный участник встреч про стратегию бизнеса. - Вы спокойно объясняете командам смысл работы над любыми проектами. - Вы легко можете выделить свой личный импакт на результаты компании. Вот такая классификация. Здесь нет объективно плохих квадрантов – все зависит от текущей роли, в которой вы находитесь. При этом понимание того, лежат ли ваши основные точки роста в шкале фокуса или в шкале автономности может помочь в планировании собственной карьеры.

Подробный гайд про то, как работают опционы Чем выше уровень руководителя, тем сильнее растет переменная часть его зарплаты. А если вы работаете в стартапе, то чаще всего она будет состоять не из премии, а из опционов. Я никогда не вдавался в глубокие детали того, как они работают, и механика казалась довольно очевидной – приходишь в компанию, тебе дают пачку акций, спустя несколько лет ты можешь ее продать, а на вырученные деньги покупаешь домик с видом на море и новый порш. Но, как и всегда, все работает сильно сложнее: 👉Чтобы получить акции, опцион надо исполнить, заплатив деньги из своего кармана. И часто нужно много денег, при этом последующая конвертация акций в выручку не всегда гарантирована. 👉На стоимость и полезность опционов может повлиять много разных сценариев, начиная от банкротства компании или ее продажей, заканчивая истечением срока опционов. 👉Опционы покрываются сразу двумя видами налогов – подоходным на исполнение и налогом на прирост капитала на их продажу. 👉На стоимость опционов может повлиять еще и размытие акций – постепенный выпуск новых бумаг, тут надо внимательно читать правила конкретной компании. Короче, в статье разобрано огромное количество таких аспектов. Но еще интереснее – статистика! 📈СЕО обычно получает 5-10% акций, VP 1-2%, директор 0.4-1.25%, сеньор 0.33-1%, менеджер или мидл 0.2-0.33%. 📈Выход планировать стоит на через 10 лет, и быть готовым к 15 годам. При этом надеяться можно и на 5, но это очень оптимистично. 📉Присоединяясь к стартапу seed стадии с долей 1% ваш шанс заработать хотя бы $1М – всего 3.2%. Детальные расчеты есть в англоязычной версии статьи.

Принцип "No Known Bugs", он же "Zero Bug Policy" В чем суть принципа – исправление любого бага по умолчанию приоритизируется выше, чем разработка любой новой фичи. С таким подходом, при условии отсутствия предыдущего бэклога из тысячи нерешенных проблем, и при разработке короткими итерациями, вы сможете повысить скорость решения багов до нескольких дней. У такого подхода, конечно, есть и недостатки. Один из ключевых – команде в среднем гораздо интереснее заниматься разработкой новых штук, а не прерываться постоянно на то, чтобы передвинуть кнопочку чуть левее, или задебажить неуловимое некорректное поведение системы. Справиться с этим помогает несколько вещей: 👉Дисциплина. Как только вы начинаете отдавать приоритет вообще всем багам, даже в том случае, когда появляются споры, баг ли это или фича, приходится тратить меньше когнитивных усилий на принятие решения о приоритизации. 👉Нужно держать перед глазами конечную цель. Она не в скорости закрытия багов, а в том, чтобы система, за которую вы отвечаете, была качественной, и вы могли бы строить поверх нее новые фичи с уверенностью. 👉Рефрейминг – относиться к багам как к незапланированным продуктовым улучшениям. Ведь любой баг – это отклонение системы от идеального поведения, а значит его исправление – приближение ее к этому поведению, следовательно улучшение. Таким образом приоритизация между багами и фичами превращается в то, что в приоритизированный заранее бэклог продуктовых улучшений периодически прилетают незапланированные, которые по умолчанию оказываются сверху списка. Такая вот ментальная бухгалтерия. Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.

Метрики в работе технической поддержки Если есть команды, в которых сбор метрик операционной эффективности чаще всего осмысленен и не вреден, то это разные виды технического саппорта. В статье рассказывают про отличный пример покрытия метриками команды, находящейся на первой линии разбора вопросов, связанных с безопасностью. Для привлечения внимания некоторые из аспектов работы команды, покрытые метриками: 👉Время реакции на запросы и процент разобранных обращений 👉Корректность разбора алертов 👉Загруженность саппорта Рекомендую почитать в том числе тем, кто занимается поддержкой внутренней инфраструктуры или платформенных продуктов – я сам применял похожие практики, например, для оценки SLA обращений за помощью в Slack.

Про эффект Линди Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет. Немного переформулировав, эффект Линди можно применить и к росту продуктов – насколько большими бы вы не были, скорее всего вы сможете вырасти еще в два раза, просто продолжая делать все то же самое, что вы уже делали для роста раньше. В статье эта идея раскручивается в обратную сторону – если вы растете линейно, то шансов, что вы покажете 10х рост, практически нет, если вы не измените полностью что-то значительное. Еще одна область, где эффект Линди вполне применим – рост команды. Скорее всего, вы сможете вырастить команду в два раза, не сильно перестраивая культуру, процессы и оргструктуру, но вот вырасти на порядок так уже не получится.

Как общаться прямо, но не быть грубым 👉Не используйте слова, которые могут показаться собеседнику эмоционально заряженными, оценочными или хоть как-то направленными на личность. 👉Перед тем, как выражать свое сильное мнение, выслушайте вторую сторону и попробуйте их понять. Как вариант – встраивайте открытые вопросы, так любую обратную связь проще принять. 👉Прямую обратную связь стоит подкреплять очень четкими фактами и объяснять логику за вашими размышлениями. 👉Говорите уверенно, но при этом сохраняя вежливость. 👉Старайтесь не использовать в коммуникации факт своей сеньорности, большего опыта или должности.

Интересы тимлида и рекрутера не совпадают На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов: 👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий 👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов. Рекрутеру в среднем важно не то, насколько подходящего человека вы наймете на открытую позицию, и точно не то, сколько лет он потом проработает в вашей команде. Сама система мотивации оптимизирует его эффективность по шкале, которая не просто не имеет ничего общего с качеством найма, но скорее противоположна ему. Именно поэтому я всегда говорю о том, что главным заинтересованным в процессе найма должен быть тимлид, и его ни в коем случае нельзя полностью делегировать в HR.

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

Обеспечение качества зависит от контекста У качества может быть много разных определений. То, которое использую я, очень близко к автору статьи. Качество – поведение программы, соответствующее ожиданиям пользователя и нефункциональным требованиям. Но несмотря на то, что это определение общее и для высоконагруженных интернет-сервисов, и для небольших мобильных приложений, и для супер-сложной системы вроде компилятора, подходы к обеспечению качества будут совсем разными. Вся статья посвящена тому, чтобы показать, что методы обеспечения качества зависят от вашего контекста, и вводит модель, которая помогает рассуждать об этом контексте. Вот на какие параметры предлагается смотреть: 👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот. 👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы 👉Team maturity – уровень навыков команды и знания предметного контекста В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя. Помимо этой золотой мысли, в статье выстраивается ментальная модель фидбэк лупов создания продукта с хорошими рассуждениями о том, на каких из них фокусироваться в зависимости от перечисленных выше параметров. Очень рекомендую статью для тех, кто хочет уложить в понятную модель свои мысли про то, как обеспечивать качество.

Что почитать тимлиду Пятница – отличный момент, чтобы выбрать себе новую книгу на выходные. Держите неплохую подборку менеджерских книг, которая выгодно отличается от других тем, что содержит не только самые очевидные рекомендации, например: 👉Dr. James Stanier «Become an Effective Engineering Manager» 👉David Marquet. «Turn the Ship Around» 👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»