Притчи СТО

Почему я не люблю ответственность Серьезно, это слово просто невозможно сразу правильно написать. О т в е т с т в е н н о с т ь. Ужас. Всегда теряю какие-то буквы по пути. Ответсвенность. Видели? Написал как обычно. «т» пропустил. Знаю лично людей, которые не могут писать слово analytics. А у вас есть такие проблемные слова?

Подкаст «Рецепт Додо». СТО и CIO Вышел подкаст от Додо, где поучастовал. Поговорили про стабильность системы, найме разработчиков и об умении переводить с языка технического на бизнесовый. Там традиционно про бизнесовость в айти и айтишность в бизнеса. Из интересных тейков: 1. Додо уже не та? Когда это началось и почему это нормально. 2. Почему я за чат, где каждый может без модерации написать, почемму ходит из компании. 3. Байка про то, как пост в блоге Федора положил кассы. Ссылочки на подкаст в разных местах: 📹 Подписывайтесь на наш канал на YouTube 💬 Смотрите наши подкасты в группе Dodo Brands в VK 🎙 Слушайте аудиоверсию подкаста на хостинге mave

Завтра буду на Big Dodo Demo 12 спикеров, 3 блока, 3 часа эфира. Додо Пицца, Дринкит, Техническая платформа. Я с 14:20 Мск в блоке Платформ. Расскажу про Client Platform и Tech Platform. Я там и за LPO и за СТО. Что будет интересного. Блок Клиентская платформа: 1. Про онлайн эквайринг, какой SuccessRate постранам. Как его улучшили за год и за счет чего? 2. Про меню. ТТК, автоимпорт цен, варианты сырья. Удобно для продуктового маркетинга. 3. Про наш CVM движок, какие фичи есть и где работают? 4. Про ОТП и траты на смс. Про антифрод. Про бесшовную авторизацию на мобилке при переключении между странами. Блок Тех платформа: 1. О том, как завезли Додо ИС в 3 зоны доступности. Чтобы переживать отказ датацентра. 2. О том, как поменяли топологию баз для надежности. 3. О том, как сделали passkey. Как в итоге подняли процент использования. 4. О том, как отрестайлили часть бэкофиса. Микрофронты, темная тема, адаптивность под форм факторы, менюшка. И все на 30к MAU бэкофиса. 5. О том, как подняли качество мобилки и о том, как можно зарепортить баг, потряся телефоном. Без воды, с красивыми артефактами и цифрами. Кстати, в эфире мы разыграем несколько клёвых призов, ведь скоро Новый год же скоро! Подключайтесь к нам 24 декабря с 12:00! 📱 На YouTube 📱 В VK Видео

Запрос на комментарии Иногда находит вдохновение и ты четко понимаешь, как что-то должно быт. Описываешь детально план и реализацию, уже можно побежать делать. Потому что все понятно, потому что есть четкий вижен. И кажется, что ничье дополнительное мнение уже не сможет улучшить проработку, разве что затормозить реализацию. Стоит остановить себя, казать свои идеи людям и попросить их покомментить. Это решает сразу несколько вопросов: 1.Мысль отлежится и ты сам можешь потом ее улучшить. Даже если никто ничего дельного не предложит, как минимум ты после изложения и некоторого времени можешь сам что-то допридумать. 2. Команда быстрее и лучше так поймет твои идеи. Одно дело придти с уже готовым планом и просто поставить их перед фактом. А другое познакомить их заранее, дать возможность повлиять на это. Так адопшн изменений пойдет лучше. 3. Критика и предложения. Это должно было быть первым и единственным пунктом, но нет, это третий пункт. Комментарии могут быть хорошим предложением(но это все очевидно как раз). Тут самое интересное, что стоит вылавливать скорее не конкретные идеи, а проблемные зоны твоего решения. Не брать готовые советы просто так. Известный американский актер и сценарист Билл Хэйдер(SNL) говорил: послушай проблему и предложения, но возьми только проблему. Запрос на комментирование не обязательно сильно задержит в решении(можно и за пару часов все сделать), но уж точно сделает ваше решение лучше. Да, пост навеян инцидентом с отключением комментов в канале. Уже пытаюсь починить.

Клуб технических менеджеров Один из интереснейших опытов при запуске роли Инжиниринг менеджера для меня был - клуб технических менеджеров. Ситуация. Новая роль, новые требования, часто в новой роли новые люди, которые первый раз в ней. Саму роль только определяем и важно очертить границы, причем в широком плане. Но уже надо в этой роли пробовать работать. Поэтому важно поделиться опытом друг с другом, понять, что ты не один и у других схожие проблемы. В таком случае вместо внешнего точечного обучения, лучше делать на старте механику типа менторского клуба. В роли менторов выступал я и Хэд оф Инжиниринг, с которым мы это запускали(Серега, было топ!). Какова механика Клуба: - Участвует 7-10 человек. - Собираемся на 1,5 часа, раз в 2 недели. - Участники выгружают свои кейсы. Кейсы выгружаются заранее или прямо на старте. Дается немного времени в начале на выгрузку текстом и на ознакомление с чужими. За встречу успеваем пройти 2 кейса. - Идет голосование, участники клуба выбирает тему на обсудить. Топ2 темы попадают в разбор. - Автор зачитывает свою тему и обращается с запросом к клубу. Дальше по очереди все высказываются. Запрос это важно в данном случае - что хочет автор? Понять, что можно было сделать не так, получить альтернативные варианты, найти решение проблемы. На разборе кейсов по очереди участники высказываются. Просто по порядку. Можно несколько раз одному выступить. И тут самое интересное. Происходит магия обсуждения. У участников появляются дополнения к своим мыслям или к мыслям других участников. Часто по себе замечал, что сначала была одна идея и одно решение, а потом после нескольких выступлений уже другая по комментарию на чей-то комментарий. Всплывают из головы разные примеры и неожиданные отсылки. Такое колесо разгона проблемы. Какие темы обсуждали: про людей, про процессы, про орг структуру, про то, как быть лидером, про технические темы(скорост, качество, надежность). Все, что болит. Клуб был для хэдов и ЕМов, потом был отдельных 2 сезона для лидеров в Додо. Хэды тоже прокачивались и тоже обменивались опытом. Был ли у вас опыт и что вообще думаете про такой формат обучения?

Статья про SLO Ура, вышла статья про систему SLO в Додо. SLO - это система контроля и улучшения reliability сервисов. Причем, она работает у нас по всем сервисам, по 2м кластерам и включает как success rate, так и latency эндпойнтов. Это уже не первая итерация системы. Начинали с простого отслеживания девяток по сервисам(на скрине), а теперь можно детально по сервисам смотреть. Мощно и точно. Сам захожу пару раз в неделю поглядываю на дашборды - сразу можно понять, что происходит и где мы. Доп эффект - можно легко графики вставлять в дайджесты и цели годовые ставить.

Обратная связь через одного Один техлид мне высказал в личной беседе на отвлеченные темы фидбек на своего инжиниринг менеджмера(ЕМа). Вот прям сказал с примерами и фактурой, что ЕМ по его мнению директивный и что нарушал договоренности и вообще звоночки уже слишком явные. Паша разберись. Вопрос к вам, давайте подумаем. Что делать? Как использовать эту информацию? Наверное хочется сразу пойти к нехорошему ЕМу и высказать ему, что “мне тут про тебя сказали вот это и то”. Но в таком подходе есть проблемы. Ты убираешь ответсвенность за дачу ОС с техлида. Ему же что-то не понравилось, а разбираешься как бы ты за него. Не лидерская позицию. Вторая проблема - ты пользуешься непроверенной информацией, переданной тебе в беседе. Всех нюансов не передать другому, быстро все упрется в «а я это вижу иначе». Поэтому я действую по такому алгоритму. Сначала надо направить техлида выдать прямую ОС своему лидеру, в данном случае ЕМу. Путь выскажет на 1-1, можно текстом. Соответсвенно, на этом этапе проблема может уже решиться. Далее берем паузу и наблюдаем. Если изменения после ОС не будет, может набраться новая пачка фидбека, и может даже будет пару несколько встреч ЕМ-техлид. И если они без результата, то тут уже можно подключаться. Встретиться на троих. Это уже следующий шаг, после прямой ос. А вот если уже ОС выдавалась. на троих общались, а результата нет - тогда уже можно и напрямую выдавать ОС от тебя к ЕМу. И в таком случае появляется еще один пойнт в обратной связи - ты не слушаешь обратную связь. Причем и от сотрудника и от меня. К этому этапу уже в ситуации можно достаточно разобраться. Вернемся в начало - а можно ли при первом звоночке уже как-то использовать информацию? В прямом виде нет, но конечно твой лидерский контекст это увеличивает. Наверное, если несколько человек выдали примерно одну ОС на одного другого - это уже повод сразу переходить к встрече на троих. Вопрос к аудитории - стоит ли все-таки использовать ос на другого человека или явно ему передавать? Какой ваш алгоритм в такой ситуации и может есть улучшение в моем подходе?

Подсвечиваем риски Часто бывает нужно быстро объяснить начинающему лидеру, что значит это самое “лидерство”. Обычно рассказывают общими словами: про проактивность, вовлеченность и ответственность, но это долго и не конкретно. Поэтому я разработал простую схему вокруг реакции на вызов. Когда лидер сталкивается с какой-то проблемой(задачей, запросом, новой темой), то какова его реакцию, что он делает? Предлагаю такую модель зрелости по решению лидером проблем: уровень 0. молчим или бухтим. уровень 1. подсвечиваем риски. уровень 2. подсвечиваем риски + предлагаем решения уровень 3. подсвечиваем риски + предлагаем решения + обеспечиваем исполнителя решения(иногда можно взять самому) уровень 4. подсвечиваем риски + предлагаем решения + обеспечиваем исполнителя решения + доводим решение до результата уровень 5. подсвечиваем риски + предлагаем решения + обеспечиваем исполнителя решения + доводим решение до результата + всем кругом рассказываем про результат. Можно пойти и дальше, лестница бесконечна. Итого, только лишь подсвечивание рисков - это не лидерская позиция. И чем ты больше делаешь активных действий вокруг проблемы(от аналитики до стратегического осознания результата) - тем бы как бы, ну больше лидер.

Создаем потенциал, реализовываем потенциал Вот вы сделали мега технический проект. Скажем, переделали механику приема заказа. Теперь можно вокруг приема заказа делать бизнес-транзакцию, в которой реально зашить разные проверки. Если одно из условий не выполнено, то все элементы получают сигнал об отмене и изменение целиком не принимается. Крутая вещь. В приеме заказа, например, есть шаг оплаты, и если начнем что-то пошло не так, то может произойти казус - заказ не создастся, а деньги спишутся(обратная ситуация, конечно исключена полностью). Что явно негатив для гостя. И поэтому хорошим решением было бы иметь возможность все сразу откатить или все сразу принять. Создать такую механику саму по себе - это создать потенциал. А вот сделать в ней на приложении пиццы, ту самую отмену платежа - это уже реализовать потенциал. Сама по себе механика бизнес транзакции, т.е. по потенциал не несет за собой никакой бизнес пользы. Да, она открывается возможно, да - это крутое техническое решение. Но пользу для бизнеса несет только реализация потенциала. Концепция с потенциалом хорошо ложится на проблему управления портефелем продуктов. Иметь в портфеле продукты такие, которые пока просто создают потенциал необходимо. Но если такой проект вышел, то надо прикладывать максимум усилий, чтобы этот потенциал реализовался. В ту же механику транзакции на прием заказа можно еще встроить проверку на применение промо акций или холдирование продуктов, чтобы в ситуации последнего круасана в кофейне мы не продавали его дважды. Так что потенциал необходимо постоянно создавать, честно транслировать, что мы пока просто его создаем, а потом реализовывать по максимуму механику в непосредственной пользе бизнесу.

Лидер-решала взял вопросик на карандаш и всех подпушил Или насколько нормально, что лидер лично закрывает какие-то вопросики, пиная всех вокруг, когда дело не движется? Произошла ситуация. В какой-то момент доступ одной пиццерии к Додо ИС заблокировали на уровне нашего антиддос провайдера. Такое интгда бывает: перекрутили правила, случайно айпи в бан попал, ну всякое возможно. Протокол стандартный - в наш саппорт и оттуда через саппорт уже провайдера разблок. От этого и правила улучшаются, чтобы фолс срабатываний не было.И вот конкретно одна заявка одной точки висит дольше обычного. Вам пишут мимо саппорта, условно в личку, чтобы вы разобрались. А вы и разбираетесь. Нашли тред, где проблема решается, написали вопросик «что там и да как, давайте дескать решать», все задвигались и стали решать. А теперь суть вопроса - а это ок вообще? Ведь если бы в личку не написали, то и не решили бы штатно проблему(или решили сильно медленнее). И вообще есть процесс, а ты как бы в него залез. Вдруг там была в этот момент проблема важнее и заместо нее бросились решать твою. И команда может видеть, что ты все решаешь, а им не надо ничего решать самим. Придут - подстрахуют. А можно посмотреть иначе. До этого 99 таких кейсов решили успешно и в срок. А вот один не успели. И доля ошибок по нарушению сла на ответ допустимая. А ты как ответственный лидер своим сверх усилием эту долю снизил еще. И выдал не просто вау сервис, а супер вау кастомные личный сервис. Погрузился в проблему, почувствовал боль клиента. Ну и просто помог человеку решить проблему, ведь если он написал тебе - ему это действительно важно сейчас. Были в таких сиутациях, может наблюдали со стороны, как поступать лидеру?

Channel photo updated

Всегда ли стоит фокусироваться на запасных вариантах? Допустим ситуация: вам надо закрыть сложную вакансию, найти лидера на крупный юнит. У вас есть кандидат, которого вы хотите. И даже есть наметки, что что-то может получиться. Но шансы, конечно не 100 процентные. Вопрос - как распределить усилия по хантингу этого одного самого лучшего и проработке запасных вариантов? Часто я формулирую свою позицию так: лучше вложить все силы в базовый вариант А, выложиться там на полную, полностью сфокусироваться на нем, а в варианты Б,В и тд особо не вкладываться. Тогда мы максимизируем достижение самого главного, нужного нам сценария, не распыляем силы. Конечно, это не значит, что не надо иметь никаких мыслей или примерных проработок запасной стратегии. Надо, но все остальные варианты в сумме не должны занимать более 10% сил, а главный вариант должен отнимать все 90% внимания. В моем примере с хантингом, например, лучше сделать лишний контакт с кандидатом, пообщаться с ним, познакомить его с другими людьми в компании или его будущими коллегами, показать ему внутренние драфт материалы, вовлечь в консалт с нами. Вариаций масса и каждое действие повышает шансы на успех. Т.е. по варианту А выгодно дойти до очень глубоких тонких действий, когда как по альтернативам иметь лишь общие наметки.

Хак, как учесть ошибки восприятия Оптические иллюзии(см фото) работают интересно. Даже понимая, что перед тобой иллюзия, твой мозг все равно упорно показывает тебе искаженную картинку. Как вы понимаете на фото красные линии одинаковые. Но даже зная эту особенность, все равно можно учитывать это в своих выводах. И на вопрос - какой предмет больше, уверена ответить, что они одинаковы. Ввести поправку. Тоже самое и с когнитивными искажениями. Например, есть такое искажение как фундаментальная ошибка атрибуции. Это когнитивное искажение, при котором люди склонны приписывать поведение других людей их личностным качествам, недооценивая влияние ситуационных факторов. Зная это, можно также учесть это в своих решениях. Когда я замечаю, что кто-то не справляется, ошибается, я в первую очередь предполагаю, что проблема не в самом человеке, а в обстоятельствах вокруг него. Может стоит посмотреть на систему в целом, на внешние факторы. Может и правда были форс мажоры? Или я как лидер где-то не выдал нужного контекста и не сделал свою работу(как внешний фактор по отношению к человеку). И уже в последнюю очередь допускать проблему в персоналии. Это же работает и в отношении себя. Когда что-то не получилось у тебя, задумайся - а что ты сделал не так, может дело в тебе? Поставить факторы внешних обстоятельств в отношении себя на последнее(а не первое как интуитивно хочется) место. Ведь если мы имеем знание об искажении, мы этим знанием можем воспользоваться, хоть нам и хочется сделать иначе.

Куда пропал? Сижу как продакт лид в юните Ордеринг платформе. Отчеты на непонятные вопросы 1. Как связан оказался с этим? Изначально я лишь курировал от си левела юнит Ордеринг платформа. Но вот расстался с лидером и автоматически стал врио продакт лида. Считаю правильным в таких сиутациях самому приходить и заниматься операционкой. Не нравится как работает лидер? Иди и покажи сам как надо. 2. Что за юниты, продакт лиды и остальные слова? Пара слов о структуре айти в Додо. Есть разрабоческие команды. Обычно они небольшие, 4-6 чел, включая продакта. Могут быть более крупные, команда платежей 11 человек. У команд есть техлид и есть продакт. Продакт управляем бэклогом, техлид занимается тех качеством и отвечает за деливери команды. Команды входят в продукты, за которы еотвечают продакты. Продукты сгруппированы в юниты. Обычно юнит это 4-6 команда(почти всегда =продуктов), около 25-40 человек. Лидирует юнит продакт лид. С ним работает техничесикй лидер юнита, инжиниринг менеджер. 3. А тех платформа как? Там все круто, спасибо ребятам, максимально самостоятельные. 4. А времени писать совсем нет? Ну почти нет. Последний раз такой напряг был год назад во время переездов инфраструктуры. Задачки моего временного присутствия. Помимо операционной работы(отпуска подписывать, найм согласовывать, на ревью выступать со вступительным словом), есть еще много чего стратегического. Стекхолдеры, продуктовый портфель, реорг вокруг платформ, составить ключевые метрики юнита, придумать стратегию по нескольким продуктам. Работа со стекхолдерами. Какие приекты для каких бизнесов делаем, что им надо. Какие регулярные встречи с стекхолдерами, какие ключевые фокусы у них. Например, недавно рынок Узбекистана стал большим фокусом и явно надо чем-то поддержать этот фокус(решили отп в телеграме быстрее там раскатать). Пара базовых процессов для жизни юнита. Например, решил сразу структурировать работу над гипотезами. Отделить флоу дискавери от деливери. Раз в месяц будем устраивать смотр гипотез со стекхолдерами. Это и деллайн по подготовке продактов, и точка актуализации по метрикам и спокойное вдумчивое обсуждение гипотез, без спешки со стартом квартала. На ежемесячном ревью решил сразу добавить дайджест с метриками. Не все вышло собрать, но это стартануло по крайней мере работу над метриками юнита. Такой подход(сначала вытащить метрики на дайджест, а потом они подтянутся) я уже много раз проворачивал. Тут публиковал много про данные по сбоям, они так появлялись. Продуктовый портфель. Чем вообще юнит занимается, какие проекты в работе. Когда закончатся, сколько сил на них идет, какие метрики двигают. Хочется, конечно и классификация сразу ввести, типа энейблер, продукт, стрим. Доля ран и ченж по юниту уже была. А еще надо придумать стратегию по ряду продуктов. Например, по меню, по клиентской безопасности(антифрод). Есть еще работа с продактами и поиск лидера. Пока вот ищем продакт овнера на платежи(вакансия открыта). Но также начал думать про поиск лида на весь юнит. ps. Пока писал пост, уже прошло первая встреча по гипотезам(не очень доволен в итоге) и юнит теперь называется Client Platform. Мораль такая - не пишите посты очень уж долго.

Был на крутом проекте КРОК «Дело в людях», обсуждали Изменения без стресса Пара тейков от меня на эфире: 1. Лучшие сторонники из самых активных хейтеров. Переводите их на свою сторону личными разговорами, разъяснением. Найдите из мотивацию и работайте с ней. 2. Нужны разные каналы доставки коммуникации во время изменений. Разные люди в разные этапы проекта лучше воспринимают разный тип информации. Нужен и q&a с лидеров, и документ с описанием, и презентация и даже можно кружочки в тг писать с апдейтами. 3. Лидеру будет трудно. Надо помнить, что тебя мотивирует и вспоминать про это в трудные моменты. 4. Некоторый уровень стресса нужен. При изменениях стресс не только нормально, но и необходимо. Если его нет вовсе, то и изменений нет. Еще поделился такой техникой как «письмо команде». Часто есть нерешенные проблемы или мысли, которые еще не оформились. Нормально ими поделиться с командой, выразить свои сомнения в чем-то, порассуждать. Такое дает открытость и большую вовлеченность. Ссылка в вк или на ютубе. 📱 YouTube 📱 ВК Видео Из почитать рекомендую Адизеса и Коттера. Нестареющая классика подходов к корпоративным трансформациям.

Change management: как управлять изменениями без стресса Обсудим это завтра на митапе вместе с коллегами из КРОК, K2 Cloud и Lamoda. Поговорим про управление в условиях неопределенности и усталость команды. А еще разберемся, что важнее: фреймворки или собственная интуиция. Давно этой темой увлекаюсь. Участвовал во внедрении SLO, НФТ, по Engineering Manager трансформации последнее время. Поговорим про это. Что обсудим: - Откуда идут изменения? Сверху или снизу? - Почему изменения терпят неудачу, по каким причинам? - Работа людей в условиях изменений 🗓 19 июня // 19:00 (мск) ✏️ Все онлайн, но нужно зарегистрироваться Запись будет, ей тоже поделюсь.