Игорь Гранщиков homepage

У меня внезапно опять оказалось некоторое количество пригласительных на ИТ-Пикник завтра — отдаю тоже просто так. Кому надо — напишите, сегодня вечером или утром завтра поотправляю. Рандомайзер на случай превышения спроса над предложением в меня не влезет, времени мало, поэтому заранее прошу прощения если кому-то не достанется. upd: по одному билету можно пройти с одним взрослым (1+1) и двумя детьми до 16 лет. upd2: пригласительные розданы, всем не хватило, к сожалению. До встречи завтра на Пикнике! ps сам на этот раз я не в программном комитете, но научную часть буду в районе шатра про продукты от и до, можем пересечься там

Вредный оверперфоманс Бывает так, что вся команда перформит хорошо, а Петя ну прям очень хорошо. И это очень хорошо становится заметно уже всем в команде. Но при ближайшем рассмотрении обнаруживаются регулярные коммиты и прочие следы деятельности Пети в выходные дни, да и в будние в широком диапазоне времени от утра и до глубокой ночи. С одной стороны, руководителю команды вроде как надо порадоваться: есть замотивированный Петя, который фигачит на 100%+, чего плохого-то. С другой стороны, звоночек может быть тревожный — команда это всё видит и по мере накопления разрыва понимает, что в плюс-минус стандартном режиме работы сопоставимого результата добиться невозможно, а взять большее количество времени без риска быть выгнанным из дома ну просто неоткуда. Тут надо понимать, что ползунок между work и life у всех выставлен в разное положение и по разным причинам, комбинаций масса. С таким овер-перформером очевидно, что у Пети этот ползунок где-то очень близко к work. И, самое любопытное, ему самому это может быть абсолютно в кайф да так, что на всякие work-life-balance опросы Петя будет твердо и искренне отвечать, что все супер (да да, и здесь он будет в топе). Все супер у него, но не у команды. Команда начинает переживать, потому что при ближайшей раздаче пряников все пряники по их логике должны достаться Пете, а остальным — ну, что останется. И в лучшем случае возникнут молчаливые полюса напряжения, в худшем — как на картинке, что может закончиться бойкотом Пети, неспешными выгораниями, ротациями и увольнениями. Получается, перфоманс одного конкретного человека вырос, команды в сумме — упал. Все потому что повышение мотивации Пети вычитается из мотивации остальной части команды — что-то вроде закона сохранения энергии получается. Как же быть в данном случае руководителю? Как ни странно, не раздавать пряники за овертаймы сами по себе. И, скажу страшное, даже за результаты, которые были достигнуты ценой одних лишь овертаймов. "Работать нужно не 12 часов, а головой" — фраза, которую приписывают то Стиву Джобсу, то Джейсону Стэтхэму. И принцип этот ясно донести и Пете, и команде — так подход к перфомансу выравнивается, напряжение постепенно снимается. Дальше или Петя перестанет отправлять пулл-реквесты вечером в субботу, или команда постепенно перестанет из-за них переживать и спокойно ревьювит в понедельник. Исход зависит скорее от изначальных внутренних причин Пети. Если там было что-то ближе к синдрому самозванца — честный разговор и обратная связь на тему достаточного уровня перфоманса приводит все в норму. Если же внутренняя мотивация Пети — ничего не поделать, не мешайте Пете заниматься любимым делом, но и не используйте его результаты как бенчмарк при следующей оценке перфоманса остальной команды.

Пара слов про Team Topologies. Год назад я готовил доклад про организационный дизайн и был просто обязан прочитать Team Topologies — хоть и не очень люблю читать на английском. Основную мысль книги все и так знают: 4 типа команд и 4 типа взаимодействий. Если читать целиком не хочется, у Александра Поломодова есть разбор в трех частях Но самое интересное для меня нашлось не там, а в начале книги — там, где авторы объясняют, почему это вообще может быть важно, своего рода problem discovery. Ниже — вольный пересказ тезисов, которые осели у меня в хайлайтах. • Организация — это не механизм, а организм. Сложный и адаптивный, а не линейный и предсказуемый • Организационная диаграмма всегда врет. Не потому что её плохо нарисовали, а потому что она в принципе не показывает реальные паттерны коммуникации. Ровно как архитектурный док устаревает в момент старта разработки — орг диаграмма не совпадает с реальностью с первого дня. Смотреть нужно на фактическую структуру связей, а не на квадратики • Структур на самом деле три, и они не совпадают. Формальная (орг диаграмма) — про соблюдение правил. Неформальная — "сфера влияния" между людьми. И value creation структура — как работа делается на самом деле, на меж-личностной и меж-командной репутации и коммуникации. Управляешь обычно первой, а результат дает третья • Матрица не спасает. Подход "матричного управления" родился в 90-х и пытался справиться со сложной и неопределенной работой через двойное подчинение — бизнесу и функции одновременно. Фокус на бизнес-ценности там и правда выше, чем в чисто функциональной структуре. Но это все равно статичный снимок мира, который устаревает так же стремительно как стремительно эволюционируют бизнес и технологии (обратите внимание, когда была написана книга, лично я слова LLM еще не знал) • Монолит — это не только когда одно огромное приложение. Бывают Application Monolith, Joined-at-the-Database Monolith, Monolithic Builds, Monolithic Releases, Monolithic Thinking и даже Monolithic Workplace. Связность бывает не только в коде, но и в процессах, в головах и в рассадке • Как резать команды. Авторы дают каталог "плоскостей разлома" (fracture planes) — линий, по которым систему можно разделить так, чтобы шов был максимально естественным: Business Domain Bounded Context, Regulatory Compliance, Change Cadence, Team Location, Risk, Performance Isolation, Technology, User Personas • Turtles all the way down. Каждая платформа сама стоит на другой платформе — даже если низлежащую не видно или не очевидно • Анти-паттерны: тасовать людей между командами, проектная ориентация команд, экономия за счет аутсорса и джуновых команд без достаточного опыта И главное — про когнитивную нагрузку. Её три типа: • intrinsic — про саму суть задачи. "Как устроен класс в Java", "как написать метод". Неизбежная сложность предметной области • extraneous — про окружение, в котором задача делается. "Как это задеплоить", "как поднять тестовое окружение". Та сложность, которую в идеале хочется убрать в ноль • germane — про то, что требует отдельного внимания: бизнес-домен, ради которого всё затевалось. "Как именно считается инвойс" Вся идея в том, что у команды нет под это бесконечного сосуда. Нагрузка складывается, и если extraneous съедает половину — на germane, ради которого команда и существует, просто не остается места. Соответственно, идея в том, чтобы минимизировать extraneous там, где это возможно. Отсюда главный тезис: команды и их контекст нужно проектировать. Не "нарежем сервисы, посчитаем капасити, а команды как-нибудь разберутся", а берем когнитивную нагрузку как ограничение и оптимизируем её через проектирование правильных границ систем и зон ответственности. То есть те самые 4 типа команд и 4 взаимодействия — совсем не единственное зачем стоит прочитать книжку. Сначала ты признаешь, что команда — живой организм с конечной емкостью, а уже из этого ограничения выводится вся остальная конструкция. Так что если соберетесь читать — не проматывайте первые главы к красивым схемам. Самое интересное как раз до них.

Джейсон вернулся :) Год назад мы just for fun попробовали попереводить всякие умные менеджерские мысли в пацанские цитаты Джейсона Стэтхэма через chatgpt. Первые эксперименты были огонь и в кулуарах CTO Conf мы в голос смеялись над тем, что менеджер без влияния это как шаурма без лаваша и над тем, что когда у тебя есть миссия, даже кофемашина к тебе относится с уважением. Издевательство над llm продолжилось и под это было решено завести отдельный канал Джейсон и Джира: тимлидские цитаты. Но со временем chatgpt генерил все более и более однотипный контент, что довольно быстро приелось, несмотря на развесистые промпты. Поэтому канал тогда так и остался в закрытой альфе, а со временем был и вовсе заброшен. Интересный сайд-эффект — из-за включенной функции памяти и количества попыток сгенерить что-то оригинальное, мой chatgpt в рандомные моменты мне до сих пор иногда пытаться объяснить какие-то технологичные и менеджерские штуки языком пацанских цитат типа "репликация, брат — это когда пришел на стрелу с такими же кентами". Прошел год, модели прокачались и решено было попробовать его на опусе 4.8, результат вдохнул в Джейсона новую жизнь. Теперь все по-взрослому и Джейсон — это скилл с эвалами, составленный на основе избранных цитат и обученный на комментах под постами мистера Стэтхэма, на 80% автоматический. Юмора стало чуть меньше, жизы и пацанской мудрости — чуть больше. Оставшиеся 20% — по результатам открытой беты, которая объявляется с этого момента, в которую вас и приглашаю: https://t.me/teamlead_jason Короче, как сказал бы сам Джейсон, хороший контент собирает лайки. Великий — собирает данные для дообучения.

Про благотворительность Завершить серию невыложенного материала должен был пост из прошедшего сезона Подлодки, но там мы разбирали кейсы и не уверен, что это имеет ценность смотреть в записи. Зато за этот разбор мне полагался небольшой гонорар, который организаторами по моей просьбе был отправлен на благотворительность. И я решил написать именно про это — вообще, у меня есть небольшая система (фреймворк, если хотите) по которой я достаточно регулярно перечисляю некоторую денежку в помощь на лечение и реабилитацию детям. Например, туда по умолчанию отправляются все суммы, которые получаются из "скидывания на ДР" (но это не единственный юзкейс). Я пишу это не для того, чтобы похвастаться или показать что я тут весь в белом. Наоборот, у меня есть разные знакомые, кто вкладывается в благотворительные и волонтерские штуки гораздо мощнее меня: кто-то помогает больным детишкам, кто-то бездомным животным, кто-то отчищает птиц на пляже в Туапсе, кто-то устраняет последствия разливов в Анапе, кто-то помогает пострадавшим в Дагестане, а кто-то ночами ищет людей в ЛизаАлерт. Я специально не оставляю никаких ссылок, потому что это не призыв к действию — у каждого свои обстоятельства и свои возможности, это нормально. Это пост про то, что если в череде бесконечных дел серьезно задуматься на эту тему не хватало времени или, самое главное, повода — возможно это как раз он.

Подкаст про фреймворки Подкаст про метрики у нас уже был, настало время подкаста про фреймворки, на который меня позвала Ольга Елисеева. Тема родилась из того самого стебного поста бота-прожарщика, который заключил, что "если у Игоря сломается тостер, он не понесет его в ремонт — сначала построит Дерево текущей реальности и проведет с ним performance review". Записывались вечером в пятницу и получился теплый разговор по большей части про смыслы и применимость фреймворков, чем how-to про что-то конкретное. Несколько тезисов для рубрики #поразгоняли: - фреймворк — упакованный чужой опыт. Когда у тебя в новой ситуации еще не наработалась интуиция — берешь готовый фреймворк. Когда уже есть — берешь интуицию. Интуиция, по сути, это твой собственный домашний фреймворк, который ты накопил через типовые решения на типовых ситуациях. - типовая ошибка — фреймворк ради фреймворка. Скрам, в котором никто не помнит, зачем эти церемонии. Ретро в пятницу "лишь бы досидеть". Когда форма есть, а проблема, которую она должна была решать, забыта. - дерево текущей реальности — дефолтный инструмент диагностики. Когда человек приходит с симптомами и ничего не понятно — берем доску и докапываемся до корневых причин через "почему". - future-back thinking и Tech Strategy Canvas, который мы сейчас доделываем. Идея простая: вместо того, чтобы пристраивать пристройку к текущему дому, представить дом целиком и от него размотать в обратную сторону. Пообещал таки добить и зарелизить в опенсорс — публично закоммитился. - LinkedIn-driven development и доклад-driven development. Когда внедряешь, чтобы потом рассказать, а не чтобы решить проблему. Мотивация в общем-то ничего, но проверочный вопрос все равно один — какую проблему мы решаем. - главная мысль: здравый смысл — базовый фреймворк и всегда лучше начать с применения именно его. А если у тебя уже что-то получается — может и не надо пытаться прикрутить фреймворк, а то есть риск как с сороконожкой, которая попыталась объяснить как она ходит и разучилась ходить. Слон целиком по ссылкам на платформах: 📺 YouTube 📺 VK Видео 🎙 Аудио подкаст 🎵 Яндекс подкаст 📺 Rutube

Отличия разных уровней менеджеров Вторым кулуарным спин-оффом дискуссии на Dream TeamLead был вопрос, а точнее, не вопрос, а утверждение, что разные уровни менеджеров в разработке особо ничем и не отличаются. Которое настоящим постом я намерен опровергнуть, кратко показав отличия каждого уровня от предыдущего по компетенциям, на примере карьерной линейки Авито. По сути, это картинка и мысли из доклада четырехлетней давности — и что самое интересное, за это время мое мнение по вопросу нисколько не поменялось. Engineering Manager — подтягиваются почти все компетенции, но особенно — управление людьми, управление командами, целеполагание. Ключевое отличие в майндсете — научиться управлять через тим-лидов (управление людьми, а точнее — теперь уже менеджерами) не трогая непосредственно команды (управление командами). Целеполагание предполагает увеличение горизонта планирования и необходимости координации работы команд между собой. Senior Engineering Manager — максимально прокачиваются бизнес-экспертиза, целеполагание и управление командами. Ключевая задача роли — понимать что вообще самое важное, та самая prioritization на языке Flight Levels. Для этого приходится делать долгосрочные ставки (горизонт-планирования и целеполагание), опираясь на понимание того какие возможности это откроет для бизнеса (бизнес-экспертиза). Ну и подстройка организации под достижение долгосрочных целей, за этим управление командами. Единственное, что изменилось за эти 4 года: доклад построен на в некоторой степени механистическом соответствии формальным ожиданиям, а нынешний я считаю, что между формальным соответствием и майндсетом важнее майндсет. Но он, увы, не так просто меняется — поэтому в механистическом соответствии особо ничего плохого и нет: начинаешь делать, делаешь правильно, а попутно понимаешь для чего это все было нужно.

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

Директивный стиль лидерства когда он не-нативный На панельке Яндекса для тимлидов я сказал, что воспитывал в себе директивный стиль лидерства — он мне не нативен, но нужен. В кулуарах несколько человек подошли с одним и тем же вопросом "а как именно?" Лично для меня нативный — демократичный стиль, когда у команды как можно больше полномочий и директивный стиль мне действительно пришлось в себе воспитывать, осознавая, что это обязательная часть профессии. Во-первых, сразу надо оговориться, что прилагательное, наиболее релевантное слову "лидерство" это "ситуативное". Это значит, что бывают ситуации, когда директивный стиль становится необходимостью и тогда стол, который обычно круглый, должен принять несколько другую форму. И здесь резонно задать два вопроса: что это за ситуации такие и как правильно этим стилем пользоваться? Ситуации, когда директивность необходима: кризис и временное давление, асимметрия экспертизы, команда стопорится и явно просит решения (бесконечные обсуждения по кругу — почти всегда сигнал), высокая цена ошибки + узкое окно, новая команда без контекста. Здесь можно вспомнить исторический пример, что знаменитые своей демократией римляне отказывались от демократии в пользу авторитарии цезаря в кризисные времена. Но даже если ситуация подходящая, синдром самозванца не забудет задать менеджеру очень своевременный вопрос: "а вдруг ты не прав?". И ответить на него поможет только доверие себе. Про которое обычно менеджер забывает, но которое, вообще говоря, очень хорошо дополняет демократичный стиль и доверие команде (но это отдельная история, которая была в докладе про волшебников). Суровая правда в том, что ты никогда не будешь на 100% прав и скорее всего да, ты где-то да ошибаешься, в большей или меньшей степени. Принцип здесь очень простой: ясные решения лучше правильных. Если совсем не уверен — за полчаса до встречи можно чуть глубже погрузиться в предмет и заодно обстучать свои мысли об условный chatgpt. Как ни странно, корень не-директивности обычно именно в этом: страх навязать команде ошибочное решение. Рефрейм: твоя работа, твоя обязанность и твой профессионализм — принимать решения в условиях неопределенности. Если ждешь полной уверенности, ты делегируешь решение не команде, а времени. Это хуже, чем решить директивно и быть готовым пересмотреть, когда появится дополнительная информация и туман войны немного рассеется. И да, когда менеджер 99% демократичен и включает директивный режим, это может быть (возможно, небольшим, но) шоком для команды. Поэтому важно этот режим обозначить — и для команды, и для себя — чтобы добавить доверия себе. "Сейчас я не спрашиваю мнения, я говорю как мы делаем — обсудим итоги через две недели". Команда понимает, что это осознанный режим, а не менеджер сломался и превратился в сурового диктатора. Правильный фрейм — не "стать директивным", а расширить палитру и научиться переключаться в нужных ситуациях. Это и проще, и устойчивее, и меньше шансов перегнуть (надеюсь).

Паттерны организационного дизайна — теперь статья Обещанный материал сам вносит свои приоритеты — сегодня на Хабре вышла моя статья "Паттерны организационного дизайна: практическое руководство". Тема оргдизайна для меня была актуальна всегда и в какой-то момент накопилось столько всего, что я решил из этого сделать доклад. Там заодно я рассказывал как этот доклад сначала стал пересказом Team Topologies, а потом стал "не Team Topologies едиными", что за прошедший год стало еще более актуальным. А потом из доклада я сделал статью и это оказалось ох как не просто, превратить материал для презентации в годный материал для чтения (но своими иллюстрациями я все равно не до конца доволен). Тем не менее, разложить по паттернам вроде получилось и теперь дело сделано, паттерны увековечены, почитать можно тут: https://habr.com/ru/companies/avito/articles/1036614/ Спасибо всем, кто помогал готовить доклад и команде тех-пиара Авито за помощь с публикацией! #струкрутируйэто здесь как нельзя к месту — получилась структура о том как делать структуру

Один день из жизни руководителя разработки Рабочий режим, AI-дофамин и неожиданно наступившее Московское лето выкололи все возможные опции в календаре, хотя за прошедший месяц скопилось некоторое количество материала, которым, несмотря на прекрасную погоду, настало время постепенно делиться. Начнем с записи дискуссии "Один день из жизни руководителя разработки" с прошедшего в Яндексе Dream TeamLead. Уникальность дискуссии в том, что она предполагалась такой, чтобы не быть похожей на дискуссию, а быть похожей на интервью. И мне кажется, такой она и получилась — модерация Мади для меня открыла просто какой-то новый уровень модерации, это было очень круто. Интервьюеруемыми оказались Татьяна Фомина, Анатолий Панов и, собственно, я. 50 минут без подготовки, без слайдов, без best practices — cкорее разговор на кухне про то, как на самом деле живется большим техническим руководителям. Чтобы не оставлять просто ссылку, несколько тезисов, которые #поразгоняли и которые зашли лично мне: • Самый частый класс ошибок — не в технологиях, а в людях. Ставка на "не тех" обычно дороже, чем неудачная ставка на стек. И с такими людьми чаще всего ничего не происходит — это и есть ошибка. • Увольнение бывает освобождением для обеих сторон — но это не повод делать его легко. Бережно, уважительно, с соблюдением базы, которую сотрудник не должен из тебя выдушивать — ты ее сам предлагаешь. И да, это тяжело, всегда. • Все думают, что на месте руководителя сделали бы лучше — и так на всех уровнях. Сотруднику кажется, что начальник тупит. Становишься руководителем — кто-то снизу думает то же самое про тебя. Этот байас не уходит с ростом. Единственное противоядие — объяснять свои решения людям, иногда из объяснения вылезает решение лучше твоего. • You are always alone at the top. Развивающий руководитель в какой-то момент пропадает. Опора смещается на команду минус один и на горизонтальные связи — те самые "токсичные чатики" с равными, где можно проораться и обсудить, что вообще, блин, происходит. • Disagree and commit как конструктивная позиция, а не капитуляция. Споришь до последнего, пока есть время, но если решение принято единственный выбор это его выполнять. Если это "выполнять" идет в разрез с твоими ценностями — вежливо прощаешься. • Интуиция это не магия, а концетрированный и спресованный опыт. Не "я почувствовала", а "моментально превратила насмотренность в решение". Неосознанная компетентность, никакой мистики. • Делать работу хорошо — недостаточно. В школе работала модель "выучил, сижу с умным лицом, учитель заметит и похвалит". Во взрослой жизни так не работает: если не потратил отдельных сил на то, чтобы про твою работу знали — никто и не узнает. Внутренний промоушен своих результатов — отдельная работа, и ей приходится учиться. И да, требовать признания результатов и достижений — нормально. • Управление временем — искусство отказа, а не оптимизации. Принцип Илона Маска: откажись → делегируй → автоматизируй. Логика простая: задача руководителя — двигать вперед, а не только поддерживать существующее. • Технический руководитель — новая работа каждый день. Контекст и технологии меняются быстрее, чем ты успеваешь освоиться. Обратная сторона той же роли — постоянная внутренняя ответственность и тревожность как спецэффект от этого. И синдром самозванца здесь не дефект характера, а часть устройства профессии. Ну а целиком 50 минут видео вот тут: • плейлист на YouTube • плейлист на VK Видео (заодно в плейлисте там можно походить по записям остальных докладов, из того что я успел посмотреть — там годнота)

AI и дофаминовая награда Чаще синдрома самозванца в нашей профессии встречается разве что синдром отличника. Мы годами учимся получать пятерки и обменивать их на дофамин. Вот скопмилировался код — молодец, держи свой дофамин. Выкатил в продакшен — снова дофамин. Получил первую 1000, 10'000, 100'000, 1'000'000 пользователей... Только вот скомпилированный код уже как-то не радует как радовал прежде. Да и выкат в прод стал какой-то рутиной. Ставки повысились. Дальше команду ты собрал, проект запустил, потом еще команду и еще проект. Потом больше команд и больше проектов. Причастность чувствуется все меньше — это же команда сделала, а не вот я сам. Все на радость самозванцу, а не отличнику. Ставки растут дальше и приучившийся мозг требует все больше и больше, чтобы выдать новую дозу дофамина. А если его не получает — живет в напряжении. И тут начинает хотеться снова код пописать, что-нибудь самому руками сделать, чтобы можно было сказать, да даже самому себе — вот смотри, это я сам. Не цель кому-то поставил, не вдохновил, не проконтролировал, а взял инструмент и сынженерил — поставьте мне мою пятерочку, вот дневник. Но не тут то было — менеджерский календарь обычно представляет собой swiss cheese calendar, в котором если и есть свободные дырочки, то маленькие и рандомные, в которые ничего особо и не сынженеришь. Вот сядешь погружаться в этот ваш поток, минут пятнадцать въезжаешь в контекст — и как только въехал справа сверху под звук "дзиньк" выплывает напоминалка о том, что до следующей встречи осталось 15 минут. И со временем привыкаешь не пытаться в эти небольшие окна делать чего-то тяжеловесного — отвечаешь в мессенджеры, смотришь почту, упорядочиваешь следующие привалившие встречи, а на сдачу — лупишь в рилсы или телеграм-канальчики с короткими постами, время на потребление которых в эти оставшиеся минуты укладывается. И тут внезапно на помощь приходит AI, недокументированной фичой которого лично для меня как раз и оказалось сокращение времени погружения в контекст. Не нужно 15 минут, чтобы разобраться в предыдущей работе и простроить ментальные связи в голове — LLM вгружает концентрированный контекст прямо в мозг, а если что-то сходу не понятно — моментально ответит на вопросы. Таким образом, полчаса между встречами вполне становится промежутком, за который можно сделать что-то осмысленное. И из суммы не вычитаются накладные расходы на каждый эпизод погружения — работа продолжается с того места, на котором остановилась до. Этот инсайт я поймал несколько недель назад и теперь осознанно стараюсь использовать. И да, получается — в конце дня или недели остаются завершенные крупные куски работы руками, и речь не только про код. Сразу вспомнилось как было в универе: если есть методичка, то задачу решим. Потом такой методичкой стал StackOverflow, а вслед за ним LLM. Теперь AI это методичка, которая всегда под рукой, да еще и искать ее не нужно, как и адаптировать решение под свой кейс. В наши дни только ленивый менеджер еще не попробовал навайбкодить для себя какую-нибудь кастомную тулзу для автоматизации рутины: от реализации управления календарем через чат, которых я уже видел около дюжины (признаюсь, имею и собственную) до каких-нибудь нетривиальных или неочевидных интеграций, вроде голосового управления жирой через эксель. И тут возникает очень интересный спецэффект и дело совсем не в сэкономленных с помощью навайбкоженного питон-скрипта или агента минутах, часах или даже днях. Дело в дофамине — скучавший отличник получил свою долгожданную награду. Награду за то, что наконец-то что-то сделал сам, своими ручками. А голосовое управление календарем через эксель это так, для души.

Подкаст "Свободный слот" про метрики Есть у ребят из Авито подкаст "Свободный слот", в котором собираются тимлиды, у которых нашелся свободный слот и рассуждают про всякое. В этот раз #поразгоняли про метрики — точнее, не сами метрики, а подходы к их использованию в разработке. С меня как с участника — традиционно тезисы, которые мне показались интересными: • с одной стороны, все мы знаем про закон Гудхарта. С другой стороны, когда дело доходит до SMART-цели, выполнение S и M лучше всего выражается в виде как раз метрики. Получается, брать метрику в цель не так уж и плохо. А вот когда цель превращается в KPI, люди перестают договариваться и начинают оптимизировать число • вообще, если люди красят метрики — чаще всего это рациональная реакция людей на систему KPI • метрика показывает сигнал, но что за ним стоит — она не скажет. Продуктовый подход: прокрасился AB-эксперимент — хорошо. Но если ты не понимаешь почему, это просто цифра — в одной руке у тебя должны быть количественники (те самые метрики), а в другой — качественники, которые эти метрики объясняют (обратная связь от пользователей или набор гипотез например) • метрики часто важны в динамике: не какое сейчас число, а как оно менялось и почему (привет качественники). mNPS = 80% это хорошо или плохо? Сложно сказать: у одного менеджера 50% это норма, у другого 100% — не норма и оба вполне могут быть правы • в каждом автомобиле есть спидометр. Но мы не ездим на машине ради того, чтобы выполнять скорость (за редким исключением). Спидометр показывает, как машина едет — но цель поездки в другом, а скорость просто нужно не превышать • руководителю не нужно постоянно смотреть на 50 графиков. Ему нужен светофор: зеленый — едем дальше, желтый — присмотрись, красный — разбирайся. А под светофором — айсберг из детальных метрик, который скорее дебаг информация, которая достается по необходимости А еще мы порассуждали, надо ли считать строчки кода и можно ли по сторипоинтам сравнивать инженеров — но самые кликбейтные вопросы как полагается — по ссылкам (трекинг в ссылках — из оригинального поста): 📺 YouTube 🔵 ВК Видео 🎧 Яндекс Музыка

Strategic Cone или Cone of Plausibility При размышлениях про стратегию, особенно техническую, важно учитывать что мир меняется и то, каким он будет на горизонте стратегии сильно отличается от того какой он есть в момент её создания. При этом сказать каким он будет точно нельзя — все же, магический шар пока не изобрели и поэтому будущее представляет собой некоторое пространство вариантов. Для визуализации такого подхода существует прекрасный инструмент Strategic Cone, он же Cone of Plausability / Cone of Probability. Cone, как и следует из названия, представляет собой что-то вроде проекции в виде конуса от текущей точки в заданную точку в будущем, как в камере Обскура. И чем более далекий горизонт планирования, тем более сильный может быть разлет вариантов, а значит и диаметр проекции — отсюда и форма конуса. Проекция будущего на заданном горизонте раскладывается в несколько вложенных друг в друга секторов будущего (все они называются на одну и ту же букву, как мы любим в рубрике #структурируйэто ): • Projected — простая проекция настоящего. То есть если все будет развиваться максимально линейно и мир не поменяется. Как в "Задаче трёх тел", когда прилетели софоны и заблокировали фундаментальный научный прогресс на ближайшие 400 лет • Probable — то что скорее всего случится. Обычно базируется на каком-то сильном тренде. Например, предыдущие лет 30 можно было спокойно брать закон Мура и утверждать, что через 2 года будут доступны вдвое более производительные чипы • Plausible — то что возможно случится и есть какая-то вероятность этого, скажем, выраженная двузначным числом в процентах. Например, ну могут на горизонте 3х лет повсеместно появиться self driving cars — ну могут же, уже куча наработок в мире есть. Но есть и ряд препятствий. • Possible — то что теоретически может случиться, но скорее нет, чем да. Например, квантовый компьютер или пилотируемый полет на Марс в ближайшие 3 года Ну и конечно Preferable — то будущее, которое мы хотим, чтобы произошло и вот с ним начинается самое интересное. Хотеть же можно просто хотеть и как японский самурай сидеть на берегу и ждать, когда мимо проплывет будущее. А можно обозначить этот образ желаемого будущего и выбирать действия в настоящем, которые при прочих равных приближают к этому образу — это и есть future-back thinking. Да, тут нам помогут границы остальных зон, которые будут задавать рамки и возможности будущего мира как мы его видим, мы их должны учитывать и на них опираться. Еще важно, что окружность Preferable будущего единственная неконцентрическая относительно остальных и это не просто так. Этим фреймворк напоминает нам, что образ будущего будет статической картинкой, только если мы не будем на неё влиять. А если будем — весь конус будет смещаться в сторону того будущего, которое мы определили как желаемое. Картинку я не помню откуда сохранил, но точная копия нашлась тут — будем считать источником

Organizational Decision Records (ODR) Как это обычно бывает когда надо сделать реорг: составляются какие-то схемы в доске, что-то по факту отличается, непонятно кто видел и кто согласовал, где-то что-то разъехалось, непонятно с какой даты изменения вступают в силу. В лучшем случае все существует в голове автора, который может это объяснить на пальцах или прислать ссылку с названием вроде "Реорг 2026 v7 (draft)" — которая больше напоминает фиче-ветку, которая случайно уехала в прод, чем стабильный master. Оказывается, все лучшее уже придумано — пару лет назад я подсмотрел у уважаемого Владимира Коноплева подход, который моментально захотел переиспользовать — Organizational Decision Records или ODR. Да-да, это как TDR в Авито или ADR в Google при проектировании инженерных систем, только для проектирования и описания организационных изменений. И обладает теми же преимуществами, что и TDR / ADR — остается артефакт, а вместе с ним зеленые галочки от ревьюверов и аппруверов. Шаблон я немного переработал и применил у нас, а неделю назад обнаружил, что подход очень даже прижился — искав один свой прошлогодний ODR, я заодно нашел целую пачку ODR, которые сделали коллеги для своих реоргов за прошлый год. Получилось, что основные блоки примерно такие: • as is и to be структура, прям схемой — для визуалов • описание мотивации изменений — самое мясо и объяснение зачем • альтернативы и компромиссы — мои любимые блоки, позаимствованные из TDR • данные по зоне ответственности и ее изменению • всякие данные по численности • порядок и таймлайн вступления изменений в силу • и сверху список авторов с датами, а также список согласующих, тоже с датами и с их визами о согласовании • а, снизу еще есть чеклист на соответствие принципам орг дизайна, принятым в компании — как юнит-тесты для самопроверки Итого получается вся важная информация, собранная на одной страничке и доступная всем заинтересованным — тот самый стабильный мастер, который можно смело катить в прод. #структурируйэто

Должен ли тимлид быть психологом В Москву резко пришла весенняя погода, засветило солнышко и запели птички, а всего несколько дней назад, когда на улице бушевала метель, на уютном 15-м этаже Авито проходил Тимлид Дринкап, уже пятый по счету. На этом дринкапе я оказался за столом, тема которого была слово в слово такая же кликбейтная как заголовкок этого поста. И в какой-то момент от участников пошли такие мощные мысли, что я начал конспектировать их в заметку, а теперь хочу поделиться ими с вами (все анонимно!). • голова, выражаясь языком бездушного капитализма, является средством производства в нашей профессии и следует поддерживать это средство производства в порядке. Или если простыми словами, "усидчивость кукухи — важный фактор" (с). Разработка это командный вид спорта и если у кого-то в команде что-то идет не так, рано или поздно это может повлиять на всю команду. Не допустить этого — ответственность тимлида. • что вообще есть "быть психологом": одно дело понимать людей и это тимлид как бы должен, другое — заниматься психотерапией и это уже как бы нет. Здесь важный навык это "эмоциональный интеллект", который нужно в себе прокачивать. Или, если по Gallup strengths, что-то из Empathy или Individualization, грань между которыми в пропускании эмоций через себя. И это у каждого тимлида может быть по-разному развито — опираясь на теорию Адизеса, разные степени прокачки разных навыков (а я к своему стыду не читал "Идеального руководителя" и забрал таки прочитать) • конечно же, был тезис про мед образование: полноценную помощь может оказывать только тот, кто имеет соответствующую квалификацию. Если бы наш стол назывался "должен ли тимлид быть стоматологом" у всех скорее был бы весьма однозначный ответ — приходит к тебе такой миддл бэкэнд инженер и говорит "дорогой тимлид, посмотри, что там у меня с зубом?" и ты врядли будешь ему ставить 1-1 на эту тему • с мед образованием за столом никого среди нас не было, а вот человек, который прошел курсы первой помощи — был (кстати, я понял, что тоже хочу пройти). И тут появилась любопытная аналогия — в случае обнаружения проблем, тимлиду следует оказать первую помощь и дальше передать специалисту. Точно так же если рядом человек упал и сломал палец, ты не будешь ему его вправлять, а найдешь лед и отправишь в травмпункт • комбинируя предыдущий тезис с тезисом про ответственность, получается что в случае если у человека в команде что-то пошло не так, ответственность тимлида — минимизировать влияние этого чего-то на команду, а исправить это что-то — ответственность самого человека Пользуясь случаем, хочу сказать спасибо участникам за живой откровенный разговор и крутые мысли, а Косте — за шикарную модерацию! Если что, выводов и моей собственной позиции по вопросу здесь не будет — я постарался собрать мысли других и ими поделиться, а заодно, поскольку это уже не первый пост такого формата, завести в канале новый тег #поразгоняли

Tech Strategy Canvas — закрытое бета тестирование Мы с Анатолием Пановым и командой достаточно давно работаем над инструментом, который называется Tech Strategy Canvas — это специальный фрейм внешне сделанный наподобии Lean Canvas, но заточенный под разработку именно технической стратегии. Чем он может помочь: он сильно задает мыслительный процесс по которому должна формироваться тех стратегия и поэтапно проводит нас от диагностики к замыслу и действиям. С ним вопросы "с чего начать?", "что делать дальше?" и "что должно получиться?" закрываются сами собой. План: сделать его полностью open source и выложить в публичный доступ. Канвас прошел уже очень длинный путь, был опробован и на тестовых кейсах, и на реальных (например, актуальную тех стратегию с моей командой мы делали с помощью него). Чтобы оценить длину пути, скажу только, что текущая версия имеет номер 11.7. Я как всякий инженер не хочу катить в прод не проведя последний тест — в этот тест я приглашаю вас. Сразу скажу, тест закрытый и канвас мы отправим ограниченному количеству людей. Основной критерий — применимость в реальных условиях в ближайшие месяц-два. Если вы прочитали это и поняли, что именно канваса вам не хватало вот прямо сейчас — заполните вот эту форму и в течение недели мы отправим (или не отправим) вам материалы. Stay tuned

Hard ↔ Soft skills Тема исторически холиварная и единого правильного определения не существует. Если загуглить отличия и пройтись по ссылкам с первой страницы, можно залипнуть надолго: найдется множество моделей которые пытаются объяснить отличия и ни одна из них не является полностью универсальной. Когда я готовил доклад про интервью, я отдельно опросил около дюжины старших менеджеров и рекрутеров, которые нанимают менеджеров и для себя сформировал три основных системы координат по отличию одного от другого: 1) Взаимодействие с машиной ↔ Взаимодействие с человеком — самое простое определение "в лоб". Первое получается про работу с системами, инструментами, технологиями, а второе — про взаимодействие с людьми: коммуникацию, влияние, договоренности. 2) Можно измерить ↔ Поведенческие проявления — интересный подход с позиции ассессмента, который предполагает, что оценить харды можно с помощью какого-нибудь теста, а вот для оценки софтов это сделать невозможно — поможет как минимум интервью, а лучше — некоторый период наблюдения и 360 в конце. Но оба этих подхода разбиваются об утверждение, которое наверняка хотя бы однажды слышал каждый "Для менеджера харды — это софты". Это как блин вообще? То есть получается что мало того, что общепринятого определения не существует, оно еще и отличается для разных ролей? Действительно, мы же научились раскладывать менеджерские компетенции в матрицы и даже придумали ассессмент для этих матриц в виде оценки менеджерского опыта — получается, измерить это +/- можно (про это кстати и был упомянутый доклад). И вот тут на сцену выходит третье определение, которое я считаю максимально универсальным: 3) "Что я умею" ↔ "Как я это делаю" — к первому относятся языки, технологии, инструменты, методики — здесь и взаимодействие с машиной, и взаимодействие с человеком. Это и поведенческие проявления, и это можно так или иначе оценить. А ко второму относится как общаюсь, как влияю, как принимаю решения, как веду людей через неопределённость. И такая система координат вполне допускает попадание одних и тех же навыков в "харды" и "софты" в зависимости от роли. Потому что для инженера архитектура, алгоритмы, базы данных — харды. А для менеджера способность договориться, создать ясность, настроить процесс — это уже его профессиональные навыки, то есть по сути харды его роли.

9boxes Период перф ревью и калибровок — отличное время, чтобы поговорить про 9boxes, который я открыл для себя в прошлом году. Открыл именно для себя, потому что фреймворк себе существовал и вы возможно про него знаете, просто это я про него никогда не слышал. Суть очень простая: все сотрудники в команде раскладываются на 9 боксов по двум шкалам, производительность и потенциал. Под производительностью следует понимать перфоманс в моменте (про что это такое — тема отдельного разговора раз, два, три), а под потенциалом — возможный перфоманс в будущем. То есть какой перфоманс человек может показать, но пока не показывает. Понятно, что количественного метода заполнения не существует и расстановка людей по этим группам — полностью субъективный процесс. Но при этом системный, который позволяет обоснованно выбрать стратегию взаимодействия с сотрудником и в этом главная ценность фреймворка. Для людей с высоким потенциалом надо подбирать задачи на рост, чтобы превратить ту самую потенциальную энергию в кинетическую энергию перфоманса. Высокопроизводительных — награждать и смотреть, чтобы не сгорели. Рабочих лошадок зачастую лучше не трогать — это отличные ребята, которым хорошо на своем месте и не всегда нужно к ним лезть с этим нашим развитием, лучше отвалить и не мешать делать любимую работу. Основа команды — по ситуации, но часто это тоже вполне устойчивая группа, требующая не супер-интенсивного развития. Отдельная категория — проблемные гении. Часто это умнейшие головы, которые могут раскрыться не во всякой среде — тут важен и проект, и команда, и руководитель. Но если раскрыть удалось, проблемный гений может быстро стать очень и очень яркой звездой. Зона особого внимания и ошибки подбора — внимательно работать с перфомансом (опять же вот тут про это) и стараться переводить в основу. Ну и конечно, с течением времени, прокачкой и ростом грейда люди могут перемещаться между боксами постепенно раскрывая свой потенциал. То есть картинка динамическая и, как и любая система, требует регулярной ревизии раз в квартал-полгода. Самое забавное, что я очень похожую координатную сетку когда-то давно придумал сам, когда вместе с тим-лидами проводил их первые калибровки и пытался объяснить что это вообще такое. В центре матрицы у нас помещался эталонный перфоманс, а все остальное калибровалось относительно него. Но, как это часто бывает, оказалось, что у хорошего подхода уже есть и название, и система. Ну и конечно, работа с результатами заполнения должна быть прозрачной для сотрудников. Не в том смысле, что вывести на слайде на всю команду как ты их отранжировал, а с каждым обсудить персонально стратегию по нему. Вот в тебе я вижу потенциал, давай вместе его раскроем. Вот ты отлично делаешь работу — я не хочу тебя заставлять качаться в следующий грейд, но если у тебя есть желание, давай это обсудим. Система, хоть и система, но все же субъективная, а значит, не исключает ошибок, поэтому открыто поговорить важно. Ведь цена ошибки тут высокая — это и чья-то карьера, и перфоманс команды. (картинка отсюда) #структурируйэто

Апдейт GTD-системы: Приоритет недели Начало года — отличное время, чтобы пересмотреть разные подходы. Для меня это, помимо прочего, еще и ежеквартальный апдейт системы управления своими персональными задачами. Основное полезное для меня нововведение — появился блок "Приоритет недели". В него я тезисно записываю ключевое, что хочу чтобы было сделано за эту неделю. Это как цель спринта, главный фокус. Помогает в приоритезации остальных задачек и что из Inbox-а сразу отправлять в работу, если это помогает достичь Приоритет недели. Например, на эту неделю у меня один из (целей спринта же может быть несколько) приоритетов "запилить воркфлоу в n8n для автоматизации действий команды" (тоже не совсем так, но чтобы и суть передать, и лишнего не наболтать), а на прошлую был единственный "кик-офф работ по ключевым целям года" (могу отдельно рассказать почему это считаю достойным приоритета недели и почему это Change). И да, тут в основном change-вещи, а от деления бэклога на Run и Change я вообще отказался. Понятно, что во времена всяких перфоманс ревью бэклог забит фидбэками, а календарь калибровками — Run поэтому никуда не девается, просто аккуратно замешивается в бэклог недели так, чтобы не противоречить Приоритету. Если что, я все это не только сейчас придумал — это скорее изменения, которые со мной прожили квартал и которые по итогу мне нравятся. В этом квартале подъехали другие изменения, которые, однако, требуют проверки временем — если все приживется, через квартал будет про что рассказать.