Что будет, если из программиста сделать менеджера? Получится Engineering Manager — такой может и код написать, и Кафку починить, и из едва знакомых людей сделать крепкую команду.

Меня зовут Олег Федоткин и я Engineering Manager. В своем бложике я буду писать про:
- Менеджмент технической команды: как сделать так, чтобы ваши команды делали работу в срок и были счастливы.
- Архитектура (микро)сервисов: как не построить распределенный монолит и не скатиться в Big Ball of Mud.
- Инфраструктура: как победить кубер, зачем вам нужен service mesh и как развернуть 11 кластеров Postgres и выжить.

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

Будет интересно :)

#longread #management #process #it
Что такое принцип Пока-Йоке и почему он вам нужен [6 минут]

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

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

Тойота и принцип нулевых ошибок
Японцы из Тойоты еще в 60-ых годах очень хотели сделать свои автомобили качественнее и надежнее. Им нужно было побеждать США в борьбе за авторынок, а высокая надежность могла бы стать ценным преимуществом. Но на заводах Тойоты все еще работали живые люди, которые были обречены совершать ошибки. Чтобы обойти американцев, нужно было придумать что-то новое.

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

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

Как я использую Пока-Йоке в ИТ
Парни из истории в начале статьи про Пока-Йоке не знали и стремились не совершать ошибок, вместо того чтобы построить систему, которая не даст их совершить. Самый базовый пример: написать авто-тесты, но Пока-Йоке в ИТ применяется гораздо шире:
- Паттерн Circuit Breaker. У одного из наших партнеров висли сервера через день. Серваки отвечали не 400, не 500, а просто висли и отключались по таймауту. Трафика между нашими системами шло много (больше 1000 rps), так что зависание ТАКОГО количества тредов в таймауте приводило к деградации части системы. Тогда мы завезли Circuit Breaker, который теперь выключает все коннекты до партнера как тольк он виснет.
- Проверка обратной совместимости контрактов. Наши сервисы несколько раз падали из-за того, что один сервис обновил свой контракт и сломал второй сервис, который не может работать с новым контрактом. Мы встроили в наш CI/CD проверки, которые не дадут запушить контракты со сломанной обратной совместимостью. Программист может ошибиться, а наш CI/CD не может.
- Метрики и алерты из коробки. Все знают, что надо писать метрики и алерты на каждый сервис. А вот пишут — не все. У себя в компании я внедрил базовые метрики и алерты в каждый сервис, так что если кто-то выжрал весь CPU или течет по памяти, я про это узнаю.

Это только то, что влезло в пост :) На самом деле примеров гораздо больше.

tl;dr
Не пытайтесь не делать ошибок вообще. Создайте систему, которая не даст совершить ошибку вашим разработчикам. Если не получается, сделайте эту ошибку видимой. Например, напишите громкий алерт.

Ссылки
- [RU][Книга] Дао Тойота — если интересно, как Тойота стала такой крутой и вынесла весь автопром
- [RU] Подробная статья про Пока-Йоке
- [RU] Про паттерн Circuit Breaker
- [RU] Моя статья на Хабре об ошибках в разработке микросервисов

В дополнение к посту выше расскажу вам о гениальном применении Пока-Йоке. Правда, не в ИТ.

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

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

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

#management #retention
Почему люди увольняются и как их удержать

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

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

- Нехватка обратной связи — я видел команды, в которых люди ни разу не получали фидбек от руководителя, хорошо они делают свою работу или плохо.
- Недостаток обучения — сюда входит и обучение внутри компании, и покупка курсов извне, и обучение у коллег.
- Негатив на рабочем месте — слишком много конфликтов и/или подковерной борьбы, неравная оплата труда.
- Отсутствие доверия — излишний контроль убивает интерес к работе.
- Излишний стресс — если человек каждый день тушит пожары, он может пойти искать место поспокойнее.
- Слишком сложные задачи — иногда челленджа становится слишком много.
- Нет удовлетворения от работы — помните притчу про камни и храм? Это оно.
- Рабочее окружение — вот тут интересно. В английском "work environment" может значит и печеньки на рабочем месте, и правила поведения на рабочем месте. Вот подробности.
- Семейные проблемы — у меня есть пример, когда человека все устраивало, но они всей семьей переехали в другую страну.
- Низкая зарплата — да, из-за нее тоже уходят. Но не только из-за нее.
- Размер команды — люди в больших командах создают менее прочные горизонтальные связи, что плохо сказывается на социальном взаимодействии. Представьте: если вы общаетесь с коллегой раз в месяц, вряд ли вам будет так же комфортно, как если бы общались с ним каждый день.
- Из-за руководителя — не сработались, не сошлись характерами. Вспоминаю свою любимую поговорку: люди приходят в компанию, а уходят от менеджеров.

Мораль: если хотите удержать человека, помните про еще 11 (!) факторов помимо зарплаты, которые нужно прокачать. Займитесь обратной связью, убедитесь в его росте, проверьте задачи сотрудника, поинтересуйтесь как у него дела в нерабочее время. Не зарплатой единой удерживаем.

Ссылка на исследованиe

#management #structure
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.

Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:

- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.

Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.

Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.

Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.

Внизу — диаграмма для визуала.

#management #strategy

Что такое стратегия
В этом посте начнем говорить о стратегиях. Я недавно услышал о фразу "у человека нет стратегического видения". Когда я спросил, что автор фразы имеет в виду, я услышал нечто вроде: "Ну, он не думает наперед". Так вот, думать наперед — это не стратегическое видение и уж тем более не стратегия.

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

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

- Диагноз — подробное описание сути проблемы, ее последствий, обстоятельств и ограничений. Ваше суждение о фактах, которые у вас на руках. Хороший диагноз упрощает плеяду фактов до простой формулировки, которая указывает на самые важные аспекты.
- Установки — правила, по которым вы собираетесь играть в рамках стратегии.
- Действия — набор четких, связанных и достижимых задач. Сформулированных, например, по SMART.

Давайте разберемся на примере. Я делаю PaaS (Platform as a Service) — продукт от программистов для программистов. Год назад я понял, что платформу воспринимают как запрещающий орган, который всем мешает жить. Это шло вразрез с моим видением платформы, но как это исправить?

Можно было бы откинуться крутыми фразами типа: "мы берем курс на клиента" или "наша цель — наши разработчики". Кто-то посчитал бы это стратегическим видением, но я вижу, что это — попытка мыслить позитивно и игнорировать настоящую проблему. Я составил стратегию по фреймворку Румельта.

Диагноз: разработка воспринимает платформу не как помощника, а как оппонента (и это в лучшем случае!).
Установки:
- Платформа — продукт для разработчика и она должна делать разработчикам приятно.
- Каждый клиент платформы должен иметь возможность внести свое предложение по улучшению или изменению платформы.
- Оценка платформы нашими разработчиками важнее нашей собственной.
Действия:
- Провести NPS опрос в течение недели.
- Создать механику Wishlist'а, куда любой разработчик может прийти с предложением по изменению или улучшению в течение спринта.
- Создать еженедельный созвон, где лиды платформы будут проходиться по вишлисту и статусу задач в нем в течение спринта.
- Поставить созвоны с рандомными разработчиками и собрать их боль в течение месяца.
- Провести еще один NPS через квартал.

Мы сделали все действия и NPS опрос показал +30% прироста. Механика вишлиста и еженедельных созвонов по вишлисту осталась с нами и по сей день. Это — стратегия и ее применение. Попробуйте составить подобную для своих задач и посмотрите, насколько сильно в гору пойдут дела.

Привет! Меня давно не было на связи, но я приготовил для вас нечто уникальное: серию мини-статей про стиль управления руководителей прошлого. Я уверен, что у Черчилля, Наполеона, Цезаря и Хидэеси есть, чему поучиться. Первая серия будет посвящена Тойотоми Хидэеси — крестьянину, который стал правителем всей Японии и объединил ее под своей властью после столетних войн. Ни до, ни после никому не удалось подняться из крестьян в правители всей страны.

Тойотоми родился в 1536 году в семье обычного крестьянина-солдата. В Японии тех времен крестьяне часто выступали в роли солдат: страна воевала часто, а держать большую профессиональную армию было дорого. Максимум, на который мог рассчитывать Хидэеси — это стать прислугой какого-нибудь знатного человека. Это и случилось: Хидэеси занял должность носителя тапочек у Оды Нобунаги.

Носитель тапочек — это не преувеличение. Будущий правитель всей Японии начинал с того, что носил тапочки не самого знатного самурая. Что нужно было сделать, чтобы хотя бы начать движение по карьерной лестнице? Сейчас расскажу :)

Посты будут выходить раз в день; комменты открыты. Дайте знать, если такое вам заходит.