Про ошибку планирования

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

Почему мы склонны постоянно совершать эту ошибку:

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

Как измерять качество

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

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

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

Как проводить осмысленные карьерные разговоры

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

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

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

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

Автор предлагает еще одну простую модель, которая помогает в таких разговорах – обсуждать два измерения роста, скоуп и импакт.

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

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

Как читать бизнес-книги

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

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

4 года холакратии

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

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

Метод, методология и методика

Я постоянно путаю эти три термина, и меня не раз ругали за это. Недавняя статья на Хабре хорошо укладывает все три определения в понятную стстему:

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

Одна и та же сущность в зависимости от контекста может быть и методом, и методологией, и методикой. Например, Scrum. Руководство по нему описывает методологию. На практике используются конкретные Scrum-методики, основанные на общей методологии. А в контексте более широкой методологии SAFe, Scrum – это просто метод, вместо которого могут использоваться и другие.

Еще раз про то, насколько тяжело сейчас будет джунам

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

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

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

Короче, ничего нового – те же самые советы джунам давали и до AI. Отличие только в том, что раньше найти работу можно было и просто научившись работать с API пары фреймворков, а теперь этого будет совсем недостаточно.

Антипаттерны в работе со сложными системами

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

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

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

Нерегулярная рубрика на канале – "Какие подкасты про тимлидство послушать". Погнали:

👉Бреслав и Ложечкин про собеседования: нанимать ди универсальных программистов, нужно ли знать математику, как нанимать студентов и что не нужно проверять на входе.
👉Три тимлида заходят в бар про тайм-менеджмент: борьба с прокрастинацией, заметки на встречах, техники пустого инбокса и чеклисты.
👉Подлодка про чистый код: Кирилл Мокевнин разбирает, насколько еще актуальны советы из легендарной книги.

Как нанять СЕО

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

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

Исследование руководителей разработки

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

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

Про аллокацию ресурсов на задачи

Приходилось ли вам когда-нибудь распределять приоритеты работы, управляя процентом выделяемых ресурсов на несколько направлений? Например, 20% времени планировать тратить на техдолг, 50% – на новые фичи, а еще 30% – на поддержку существующей функциональности. Если да, то у меня новости – такой подход работает не очень оптимально.

👉Такой подход прячет за собой реальное определение приоритетов. Мы тратим на техдолг 20%, потому что это наименее важное для нас направление, или потому что нужно обслуживать более срочные задачи?
👉Помимо приоритетов, он прячет и наши ожидания от вложенных ресурсов. Что именно мы ожидаем от вложения 20% ресурсов в техдолг? Точно ли этого достаточно? Как вообще определяется достаточность?

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

Как защищать свои идеи

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

Несколько советов из статьи:

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

Как менялась корпоративная культура в России

Забавное микроисследование российских объявлений о работе за период с 90х по наше время, которое показывает, как менялись основные ценности корпоративной культуры, а рынок колебался от работодателя к работнику.

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

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

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

Манипуляции при увольнении

Я тут совсем пропустил скандал с увольнением толпы разработчиков из Рольфа, большую часть из которых уговорили подписать заявление по собственному желанию без каких-то выплат. Но черт бы с ним с самим скандалом – в публичный доступ утекла презентация, в которой HR Рольфа делятся как раз таки практиками увольнения. Помимо мемных рекомендаций, там есть и статистика про то, что вроде как только половина увольнений по собственному желанию за все время сопровождались компенсацией.

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

Правило бойскаута для тимлида

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

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

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

Как в разных компаниях сотрудники получают доменный опыт

👉Uber – выделяет сотрудникам несколько сотен долларов в месяц на использование своих сервисов. Похожая схема, кстати, точно есть и у Bolt.
👉Carta, платформа для equity management, оплачивают получение своими сотрудниками соответствующей профессиональной сертификации. А для топ-менеджеров работает другая программа – каждый из них назначается "спонсором" одного из крупных B2B клиентов. Это значит, что он находится в постоянном контакте с ним, знает все про его проблемы и сценарии, и адвокатирует за него при обсуждениях роадмапа.
👉Stripe – все читают книгу про работу платежек в США, а многие еще и поднимают свой собственный магазин.
👉Intercom – на всех тимбилдингах команды пытаются проходить типичные пользовательские сценарии и встраивать формы интеркома в разные сайты.

А теперь немного из моего опыта:
👉В JetBrains все довольно просто. Чаще всего мы делаем продукты для людей, довольно похожих на нас, поэтому хорошо понимаем доменную область. Но есть и исключения. Например, команда, которая делает UI фреймворк Compose Multiplatform, регулярно собирается похакатонить простые приложения на основе своего же фреймворка, повторяя пользовательские сценарии.
👉В Авито одно время сотрудникам накидывали бонусы на услуги платного продвижения. Потом, правда, перестали, но это не меняло того, что продуктом и как покупатели, и как продавцы, и так пользовались практически все.

Очередь задач вместо сторипойнтов

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

Как AI команда может замедлять компанию

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

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