Как писать статус-репорты

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

Автор статьи рассказывает про набор советов, которыми он руководствуется при написании таких отчетов. Некоторые мне кажутся странненькими, но вот те, которые точно утащу себе:

👉Регулярность переоценена. Вместо того, чтобы публиковать отчет по строгому расписанию, лучше делать перерывы разной продолжительности – иногда неделю, иногда три. Так будет создаваться ощущение, что у вас действительно появилась новая и интересная информация, и вероятность прочтения отчета повышается.
👉Если для вас такой режим подходит, то попробуйте headline driven development. Заранее запланируйте, когда будете писать следующий отчет, и к этому моменту постарайтесь сделать что-то весомое в проекте.
👉Всегда любой отчет начинайте с TL;DR в одно предложение и с короткого напоминания целей проекта. Во-первых, список читателей мог поменяться. Во-вторых, это для вас ваш проект – центр мира, а остальные люди его могут не держать в голове. В-третьих, любые новости проще воспринимать в общем контексте.
👉Все любят приятные сюрпризы. Можете заранее прикинуть, что может быть таким сюрпризом, и целенаправленно подготовить его для включения в отчет.
👉Если в проекте произошли какие-то изменения, особенно те, которые противоречат опубликованным вами ранее отчетам, обязательно в явном виде про них напишите. Неявные изменения могут легко привести к поломанным ожиданиям, а те к политическим проблемам.
👉Держите в голове три основных вопроса, которые могут быть у вашей аудитории, и постарайтесь на них ответить.
👉Если в проекте случились какие-то проблемы или появились новые риски – о них тоже стоит ясно рассказать. При этом обязательно упомяните, что вы будете с ними делать.

Как делать дата-проекты

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

👉Метрики качества данных и их полноты
👉Определение ответственных за тот или иной кусок данных
👉Из каких кусочков состоит роль руководителя в платформе данных
👉Что там происходит на рынке специалистов по работе с данными

Признаки того, что менеджер все продолбает

За последние шесть лет среднее количество прямых сотрудников у менеджера выросло почти в три раза. Это привело сразу к нескольким неприятным последствиям:

👉Менеджеры считают, что они отвечают за где-то на 50% больше вещей, чем им позволяет загруженность.
👉Все та же половина менеджеров сильно страдает от стресса и вымотанности, и не может уделять достаточно внимания персонализированной работе со своей командой.
👉У сотрудников таких менеджеров шансов стать топ-перформерами в два раза меньше, чем у других. А шанс того, что они уволятся, наоборот, в три раза выше.

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

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

Что делать, когда сотрудник не воспринимает обратную связь

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

Вот, что советуют в таких ситуациях:

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

В комментах к треду на Реддите, конечно, какие-то очень кровожадные люди собрались. Каждый второй комментарий про то, что человеку надо написать PIP, а потом уволить. Как страшно жить то, а.

Новые выпуски тимлидских подкастов

Тут вышло сразу два интересных выпуска, которые не стоит пропускать:

👉"Бреслав и Ложечкин" про карьерный рост руководителя: в чем отличия ролей линейного руководителя и менеджера менеджеров, как подготовиться к переходу между ними, какие бывают типичные ошибки и ловушки.
👉"Три тимлида заходят в бар", новый подкаст от Насти Абрашитовой, Жени Антонова и Виктора Корейши. Первый выпуск – про сложные разговоры с подчиненными. Как сказать человеку, что от него попахивает, надо ли помогать бороться с зависимостями и как побеждать в кондиционерных войнах.

Что выделяет топ-1% продактов

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

👉Think big. Крутые продакты смотрят в будущее, не пытаясь ограничивать себя существующими сейчас рамками доступных ресурсов. Они целятся в большие возможности, и переводят их в конкретные планы по их достижению.
👉 Prioritize. Крутые продакты умеют держать баланс между проектами, которые приносят быструю выгоду, и долгосрочными инвестициями в платформу.
👉Execution. Крутые продакты делают все, что нужно, чтобы их проект дошел до результата. И почти всегда это значит выходить сильно за рамки их основной роли.
👉Forecast and measure. Крутые продакты умеют очень приблизительно, но при этом близко к реальности, оценивать потенциальную выгоду от инвестиций, используя свой предыдущий опыт и бенчмарки.
👉Trust. Крутые продакты умеют зарабатывать доверие своих стейкхолдеров, и затем пользоваться им, чтобы двигаться быстрее.
👉Push back effectively. Крутые продакты умеют не просто говорить "нет", но делать это так, чтобы не заводить себе врагов, а, наоборот, убеждать противников своих идей.
👉Driven by impact, not promotion. Крутые продакты думаю не о собственном промо внутри компании, а в первую очередь про импакт, который они могут принести. Промоушн – производная импакта.

Серия постов Шароватова про планирование

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

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

Как и в других статьях и выступлениях Виталика мне нравится, что он ведет все свои рассуждения от базовых принципов, поэтому спорить с ними довольно бессмысленно, даже если вам кажется, что именно ваша ситуация – вот точно совсем-совсем ДРУГАЯ. Короче, он там явно в своих заметках только разгоняется, поэтому посматривайте в канал!

Как ментальное здоровье влияет на работу

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

👉Основной источник стресса большинства людей – работа, а не личная жизнь. При этом рабочий стресс негативно повлиял на физическое здоровье аж у 77% опрошенных, а 75% набрали лишний вес.
👉Работа влияет на жизнь людей и с положительной стороны. 53% опрошенных благодаря работе нашли компанию людей с похожими интересами, 48% стали увереннее в себе, а 44% стали менее остро чувствовать одиночество.
👉Топ примеров того, как менеджеры негативно влияют на эмоциональное состояние: отсутствие понимания жизни сотрудника за пределами работы, неравное отношение к разным членам команды, нарушение границ рабочего времени.
👉А вот топ положительных примеров: гибкое отношение к рабочему времени, менторство, поощрение карьерных амбиций.
👉93% опрошенных считают, что работодатель должен помогать с ментальным здоровьем.

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

Разработка мобильных приложений на заказ от CleverPumpkin

Я очень давно и хорошо дружу с ребятами из CleverPumpkin, бутиковой студии, которая занимается разработкой мобильных приложений на заказ. С их СЕО мы как-то писали чудесный выпуск Подлодки про то, как вообще выстраивать аутсорс-компании, там работали много моих друзей, а сейчас в QA работает моя жена! Поэтому этот пост, хоть и рекламный, но в этот раз прям от чистого сердца!

Так вот, в чем суть – ребята сейчас активно ищут новых клиентов, для которых готовы сделать какие-то классные приложения. Почему вам стоит прийти именно к CleverPumpkin:

👉Они работают с одними из самых классных компаний в России: Хабром, Авиасейлс, Kassir.ru, Интерфакс, Sports.ru, Комитет, Подари жизнь, Пикабу и многими другими.
👉Помимо приложений на заказ делают и свои продукты, которыми многие из вас даже пользуются – например, Moneon для учета личных финансов.
👉Они угорают и по продуктовому, и по техническому качеству того, что делают – поэтому куча клиентов к ним приходит по рекомендациям.

Чтобы пост был не только рекламным, но еще и полезным, держите ссылки на крутой контент, который ребята делают:

🔗Гайд по этапам разработки мобильного приложения
🔗Как организовать трансфер проекта от аутсорса к инхаус команде
🔗Сколько вообще стоит сделать мобильное приложение

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

Как организовывать приоритизацию в командах, отвечающих за общие компоненты

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

👉Вы раздаете обещания налево и направо, пытаетесь угодить всем заказчикам, но в итоге подводите по срокам всех. Нереалистичные коммитменты постепенно нарастают друг на друге, и доверия к вашей команде все меньше. Единственный плюс такого подхода – вы выглядите довольно выгодно первые несколько циклов планирования. Основной минус – это впечатление длится недолго.
👉Вы приоритизируете задачи в вакууме, избегаете конфликтов, и противопоставляете части неудовлетворенных заказчиков хороший трек рекорд законченных проектов и собственных выполненных целей. Плюсы – вас ничто не ограничивает, команда движется быстро, дает какой-то результат. Минусы – доверия к команде все еще мало, так как она действует как черный ящик.
👉Вы строите систему, в которой ваши заказчики сражаются друг с другом за приоритеты в очереди задач. Плюсы – удобно для команды, вы снимаете с себя ответственность и ничем не рискуете. Минусы – вас начинают воспринимать сугубо как сервисную команду.
👉Вы делаете так, чтобы в компании появилась сквозная приоритизация для проектов. Условно говоря, если для всей компании проект А важнее, чем проект Б, то и ваши задачи для проекта А получают понятный приоритет. Такой подход дает всем командам понятные ориентиры и позволяет автономно принимать решения. Минус – менеджмент обычно не любит принимать такие сложные решения.

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

Podlodka Crew про софт-скиллы

Через неделю стартует новый сезон конференции Podlodka Soft Skills Crew про то, как правильно применять софты на собеседованиях. Вот несколько топовых сессий:

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

Среди спикеров такие классные ребята как Женя Антонов, Алексей Шаграев, Вероника Ильина и Валерий Бабушкин.

📆Дата: 13-17 мая, две сессии в день
👉Регистрация

Не бросайтесь сразу же исправлять все проблемы

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

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

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

2️⃣Фокусируйтесь на нескольких самых важных проблемах, отложив десятки остальных. Автор называет это правилом 63 – выбираете 3 проблемы для исправления, а остальные 60 осознанно отпускаете. Такой подход помогает не размазывать свой ресурс слишком тонким слоем, и добиваться видимого результата.

Про когнитивную нагрузку

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

Автор предлагает смотреть на когнитивную нагрузку с помощью следующей ментальной модели:

cognitive_capacity = individual_cognitive_strength - (environment_cognitive_friction + task_cognitive_weight

👉Cognitive strength – количество ментальной энергии, которое конкретный человек или команда могут выделить на работу в конкретный день.
👉Cognitive friction – влияние рабочего окружения на ментальную нагрузку. Коимат в команде, качество кода, комфорт рабочего места, автоматизация рутины.
👉Cognitive weight – сложность конкретной решаемой задачи, как неотъемлимая, так и порождаемая плохой декомпозицией.

Гайд по внутренним коммуникациям

37signals написали классный гайд про организацию коммуникаций внутри компании. Общая философия – уводить все общение в асинхронный режим, все важное фиксировать в долгоживущих документах, а митинги проводить, только когда нет другого выбора. А детали сформулированы в виде 30 принципов. Вот некоторые из них:

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

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

👉Автоматические сообщения вроде "Какую книгу вы сейчас читаете?" или "Встречали ли вы в последнее время примеры классного дизайна?". Такие опциональные вопросы дают людям дополнительную возможность завязать разговор и сблизиться, что особенно важно удаленным командам.
👉Heartbeats: 6-недельные статус репорты команды, департамента или конкретного человека. Они содержат обзор самых важных ачивок, подчеркивают важность работы и рассказывают про интересные мелочи. Цель – рефлексия о текущем прогрессе и предоставление сводки тем, кто в ней заинтересован.

Как писать дизайн-доки

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

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

Как строить команду менеджеров

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

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

👉Проактивно объясняйте свои ожидания от менеджеров, начиная с интервью, заканчивая привязкой к повышению в карьере.
👉Относитесь к ним как к настоящей команде. Вместо 1-1 обсуждений старайтесь вести общие коммуникации, иметь один канал в Slack, устраивать совместные тимбилдинги и всякое такое, что делает нормальная команда.
👉Поощряйте взаимопомощь в рамках группы. Находите способы подтолкнуть людей к совместной работе.
👉Делитесь своими проблемами с командой, и подключайте к совместносу их решению.

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

Как подойти к succession planning

Succession planning – это подготовка своего преемника на тот случай, если вы двинетесь дальше по карьерной лестнице, решите уйти из компании, или вас собьет автобус.

1️⃣Проанализируйте, чем вы занимаетесь

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

2️⃣Распределите преемственность

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

Вы восхитительны, и только что проделали succession planning! Повторять упражнение надо хотя бы раз в год.