Давайте пообсуждаем пост про DISC тут. Обновленный спам-бот в чате типизирует себя как D по DISC, поэтому доминантно принял решение сам, и удалил комменты к прошлому посту.

Что определяет сильных инженеров

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

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

Баги – не проблема, а ее симптомы

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

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

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

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

Что посмотреть на выходных

Когда-то я очень сильно угорал по организации конференций. Началось все с небольших камерных митапов про iOS разработку, которые мы с командой собирали на мансарде Рамблера, продолжилось совместными с Онтико полноценными конфами AppsConf и ProductFest, а закончилось уже собственными онлайн-конференциями Podlodka Crew, когда мы в пике делали что-то около 40 мероприятий в год. Главная вещь, которую я за это время понял – конференции вообще непредсказуемы. Насколько успешно получится привлечь посетителей, с какими организационными проблемами предстоит столкнуться, какие спикеры исчезнут в самый последний момент – все эти вопросы будут не выходить из твоей головы до самого последнего момента.

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

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

Месяц с AI-джуном в команде

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

На деле все оказалось, конечно, совсем не так весело. Команда, попробовавшая поработать с ним в течение месяца на реальных задачах, скорее разочарована:

👉Из 20 делегированных ему проектов он справился с 3, завалил 14, и в еще 3 случаях задачу хоть и решил, но лучше бы это сделал человек. Вот тут, кстати, есть поисание всех задач.
👉Лучше всего ему даются задачи с небольшим скоупом и очень хорошо сформулированные. При этом пользы от делегирования их AI не очень много, потому что времени они не отнимут и у обычного инженера, осоьенно вооруженного нормальным AI ассистентом.
👉Он подвержен той самой проблеме 70%, о которой сейчас модно рассуждать: первые видимые результаты можно получить очень быстро, но докрутить до продакшн-состояния занимает столько времени, что проще все было сделать самому.

Но я вообще AI-оптимист, и верю, что вот такие заметные провалы – необходимый шаг для того, чтобы получить реальный рабочий инструмент. Способности моделей продолжают быстро расти, UX вокруг взаимодействия с человеком, валидирующим результаты их работы, улучшается, они учатся использовать все больше и больше инструментов и опираться на все более сложный контекст. Еще год-два, и спокойно сможем делегировать агенту заполнение таймшитов в Jira и хождение на дейлики!

Что означают девятки в надежности сервисов

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

1️⃣ С каждой следующей девяткой сложность инфраструктуры растет экспоненциально. Например, если для 99.9% надежности достаточно сервера в одном регионе, то 99.99% влечет за собой деплой сразу во много регионов, автоматический хелсчек и более сложные алгоритмы восстановления.
2️⃣ Такая оценка дает лишь очень приближенное представление о реальной надежности, так как скрывает много нюансов. Например, игнорирует частичный отказ сервисов, и предполагает равномерное распределение отказов по времени. Для пользователя картинка выглядит по-другому, и одно падение на час может быть существенно хуже, чем 200 минутных падений в течение года.
3️⃣ Не стоит стремиться к наибольшему количеству девяток, так как более высокая надежность влечет за собой кучу трейдоффов. Например, будут страдать скорость разработки и существенно расти косты на поддержку. Иногда придется даже жертвовать пользовательским опытом – упрощать фичи, чтобы архитектура системы была проще, или заменять синхронное действие сложными асинхронными распределенными транзакциями.

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

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

Откуда берется бюрократия

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

Новые выпуски подкастов про менеджмент

👉"Подлодка" про смену роли в IT. В этот раз мы не стали звать никаких гостей, и делились своим собственным опытом. Я, например, рассказывал и про переход из линейного разработчика в тимлиды, и из пипл-менеджмента в продакты. Если вас периодически посещают мысли, не попробовать ли что-то новое в сравнительно безопасных условиях – обязательно слушайте!
👉"Три тимлида заходят в бар" про managing up – как проактивно выстраивать отношения со своим руководителем и управлять его ожиданиями.
👉"Бреслав и Ложечкин" про то то, как выживать в мире позивной дискриминации, и то, насколько действительно имеет место гендерное неравенство.

Как организовать succession planning

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

Вот как организовать процесс у себя:

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

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

Методологии разработки, о которых вы не слышали

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

1️⃣ShapeUp от BaseCamp

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

Выглядит похоже на стандартный Double Diamond, с небольшими локальными подкрутками.

2️⃣Plan > Build > Ship

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

3️⃣Get Shit Done

Внутренний процесс Shopify, который в основном крутится вокруг их внутреннего же инструмента трекинга. Вся работа бьется на отдельные проекты, задача которых – решить какую-то проблему пользователя. Работа бьется на три фазы, близкие к тому же ShapeUp: Think (исследуем проблему), Explore (исследуем область решений), Build (коммитимся на одном решении, разрабатываем и выпускаем его).

🌟Бонус для тех, кто дочитал: govno.works

Учимся финансовой грамотности

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

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

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

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

Короче говоря, подписывайтесь на RationalAnswer. Вот посты, с которых можете начать:

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

Практикуем second-order thinking

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

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

👉"А что потом?". Думая о каком-то действии, задавайте себе этот вопрос несколько раз, пока не построите дерево возможных последствий ваших решений.
👉"10-10-10". Думайте о последствиях своих решений в трех временных горизонтах – 10 минут, 10 месяцев, 10 лет. Это поможет не фокусироваться на самых очевидных краткосрочных вещах.

Что ведет к размыванию ответственности

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

Вот список поведений, которые ведут к тому, что ответственность размывается:

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

Непопулярные мнения про организацию команд

👉Не создавайте нано-команды из 2-3 человек. Вы создаете дополнительную менеджерскую нагрузку, редко когда получаете достаточно пользы, а потом сталкиваетесь с тем, что решить проблему и смерджить несколько команд, не задев эго их лидов и уронив их мотивацию на пол, очень сложно.
👉Не проводите хакатоны. Дефолтный результат любого закатона – куча сырых прототипов, про которые все забудут уже на следующий день. Видимость деятельности большая, а значимых результатов нет. Если вы ждете инноваций от команд, то лучше попробуйте интегрировать возможность экспериментировать с новыми идеями в их повседневную работу.
👉Не выделяйте 20% времени на техдолг. Это очень не структурный подход, который легко может привести к тому, что команда будет заниматься не приоритетными вещами. Вместо этого работайте с техдолгом как с обычными продуктовыми задачами, добавляя их в тот же бэклог, и пропуская через сквозную приоритизацию.
👉Не защищайте время инженеров. Многие тимлиды относятся к рабочим часам программистов как к самому ценному ресурсу, оптимизируя все вокруг них – продакты должны приносить детально описанные спецификации, а тестировщики работать в изоляции и не беспокоить своими вопросами. У такого подхода миллион плохих последствий, включая замедление работы, падение качества продукта и демотивацию тех самых программистов.
👉Цельтесь в здоровый рейт увольнений. Компания, из которой никто не увольняется, и в которую не приходят новые люди, становится очень замкнутой на себя. Людям некуда расти, новых знаний не появляется, формируется пузырь.
👉Избегайте чрезмерной специализации. Наличие очень узких экспертов ведет к появлению бутылочных горлышек и падению бас-фактора.