Про лидеров в IT: как находить, нанимать и развивать внутри компании

Отойдем немного от текстового формата к аудио. Пока этот канал простаивал, я в конце 2022 ходил в подкаст к Паше Притчину СТО Dodo Engineering. Отлично поговорили про то, как руководителю находить и развивать толковых ребят.

Пост не рекламный) Но я сам периодически слушаю других гостей на этом подкасте про жизнь СТО, так что держите.

https://ctotalks.mave.digital/ep-14

Инцидент-менеджмент

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

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

https://www.youtube.com/watch?v=P0Abc1VyOeI
Эволюция инцидент-менеджмента от одного дежурного до сложной системы дежурств, состоящей из команды SRE и нескольких команд разработки.

https://www.youtube.com/watch?v=M5-s0Citu8U
Обоснование необходимости классификации событий по категориям - инцидент, ЗНО, ЗНИ; а также классификации инцидентов по важности: Disaster, High, Warning. А также рассказ про Zabbix

https://www.youtube.com/watch?v=fPNs8svOXiE
выступление от 2017 по инцидент-менеджменту в Badoo.

https://www.youtube.com/watch?v=GcMnBZBmpFk
Причины замедления расследования инцидентов, и как их устранить.

https://www.youtube.com/watch?v=6J1D1DJTHck
как построить процесс управления инцидентами с нуля, снизить риски и улучшить свой RTO

Как изменить мир?

Пост не рекламный) Вчера вечером смотрел интервью Гоши Соловьева - кофаундера Skyeng.
https://www.youtube.com/watch?v=Uyv0kRWe9jg

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

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

Веселый вечерок

Как вам ребята вечерок?) Интересно потом почитать публичный постмортем данного инцидента. Если конечно выложат в публичное поле.

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

Если кто-то не в курсе о чем речь https://t.iss.one/mintsifry/2114

Будущее персонализации

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

- он дообучил нейронку, которая на основании его предыдущих выборов, свайпала понравившихся девушек в тиндере;
- с теми, у кого возникал матч, он на основании своих предпочтений подключил chatGPT, который общался с этими девушками и приглашал их на свидание (без участия человека);
- дальше с отобранными девушками таким способом он шел на свидание;
- и внимание(!!!) женился на девушке, которая была подобрана таким способом.

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

https://t.iss.one/lentachold/69100

Вакансия лида продуктовой аналитики

Ищу себе в Skyeng Team Lead Product Analytics \ Head продуктовой аналитики 🔥

В зоне ответственности хэда будут два направления:
-продуктовая аналитика привлечения (A/B воронок, сегментации, исследования);
-продуктовая аналитика нашей образовательной платформы (академический опыт, опыт взаимодействия с платформой и тд).

Чем предстоит заниматься:
▪️Управлять командой (8 человек);
▪️Организовывать и подводить итоги AB-тестов;
▪️Реализовывать и курировать проекты;
▪️Выявлять проблемы, выстраивать модели, собирать и контролировать метрики;
▪️Искать и выявлять зависимости для формирования гипотез об улучшениях бизнес-процессов и финансовых показателей компании;
▪️Поддерживать, развивать системы сбора и анализа данных;
▪️Консультировать и помогать бизнесу, развивать аналитическую культуру, взаимодействовать с командами разработки.


Из плюшек:
🔹работать удаленно из любой точки мира. А если захочется познакомиться лично, то двери большого и уютного офиса в Москве всегда открыты!
🔹учиться за наш счёт;
🔹пользоваться нашими внутренними сервисами: ассистенты возьмут на себя рутинные простые задачи, а контент-продакшн сделает текст, видео или дизайн по твоему заказу;
🔹ну и крутотецкого руководителя в придачу (прямой руководитель не я).

Откликаться можно напрямую нашему рекрутеру Maria Dolgusheva тг: @mariadolgusheva

Коэффициент личности 1.2x и 0.8x

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

И недавно мне закинули видео, которое гораздо более структурно описывает таких людей https://www.youtube.com/watch?v=6hO37hmrJfE

Как вы себя оцениваете - вы 0.8, 1.0 или 1.2?

Вводный курс про солюшен-архитекторов

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

Внимание - для открытия из РФ нужен VPN (medium.com не открывается из 🇷🇺).

— https://medium.com/@nvashanin/the-path-to-becoming-a-software-architect-de53f1cb310a вводная статья с описанием как стать солюшен архитектором;

— https://medium.com/@nvashanin/stakeholders-in-software-architecture-6d18f36250f9 ответ почему stakeholder management является ключевым навыком для солюшен архитекторов;

— https://medium.com/@nvashanin/types-of-software-architects-aa03e359d192 чем отличается системный архитектор от солюшена и ентерпрайз;

— https://medium.com/@nvashanin/quality-attributes-in-software-architecture-3844ea482732 что такое нефункциональные требования и какие они бывают?

— https://medium.com/@nvashanin/books-in-software-architecture-6ad974e524ce для любителей чтения - список книг по архитектуре;

— https://medium.com/@nvashanin/system-design-cheat-sheet-762810f95fb6 короткий гайд для прохождения system design interview или для проектирования системы.

Роад мэп развития солюшен архитектора

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

В результате родился вот такой репозиторий https://github.com/NikAshanin/Solution-Architect-Road-Map и вот такая майнд мапа. Пользуйтесь на здоровье!

#степаненко

Всем привет! Меня зовут Костя Степаненко, и это гостевой пост в канале моего друга и бывшего коллеги.

Сегодня я СЕО Кошелька — приложения для хранения скидочных карт, мы входим в группу Тинькофф. До этого я был кофаундером сервиса Самокат.

Хочу поделиться своими и послушать ваши варианты, как вы ставите амбициозные цели на команду. Например, если вам надо вырасти в 3-5 раза за год по выручке.

Я здесь выделяю несколько ключевых моментов

1. Набирайте команду, которая не пугается фразы «надо вырасти в 5 раз за год» — у сотрудника должна включаться инициатива, как этого достичь, а не страх. Это хорошая проверка на этапе собеседования

2. Объясните, как достигать цель, которую вы ставите, и почему вы считаете, что её можно достичь. Здесь подойдут сравнения с прошлым опытом команды (прошлый год), показателями рынка или декомпозиция роста в 5 раз на 4 роста в 1,5 раза

3. Цель не должна зависеть от одного запуска, партнёра, события — чтобы команда могла больше влиять на результат и больше в него верить. То есть вы должны показать, что всё зависит от нас (насколько это возможно)

4. Надо понимать, зачем мы это делаем, что мы от этого получим. Здесь может быть много вариантов от независимости от инвестора до диверсификации бизнеса для повышения устойчивости. Бонусов обычно мало :)

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

CRM-системы

CRMка в Skyeng является одной из жизненно важных систем, которая пронизывает все бизнесовые процессы. И среди разработчиков частенько бытует мнение о скушности работы над CRM. Мы внутри проводим несколько исследований как следать работу CRM более комфортной и ребята предложили мне послушать подкаст про CRM https://share.transistor.fm/s/04e514e8.

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

Проблема рынка продактов в том, что они научились миллион инструментов использовать, но часто не понимают зачем и в какой момент

Именно такой комментарий мне прислал мой товарищ Дима, когда я отправил ему видео про продактов и продуктовую аналитику, которое вчера досмотрел https://www.youtube.com/watch?v=v1S4ikiFAxA

Олег Якубенков (тот самый, что был в команде Masquerade при продаже Facebook, и тот, что сделал https://gopractice.ru/course/pm/ - крайне рекомендую, проходил еще в 2018 году) хоть и выглядит на этом видео как будто сейчас умрет (это комментарий под видео), но тем не менее рассказывает супер простым языком про продукт и базовые вещи про продуктовую аналитику.

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

Ищу гостя в подкаст "Тимлид позвонит"

Внутри Skyeng решили воскресить подкаст "Тимлид позвонит" 📞 Выпусков не было 4 года, поэтому хотим не уронить планку и сделать бомбу.

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

Sora

Тем, кто как и я пропустили последнюю презентацию Open AI, крайне рекомендую посмотреть новую gpt для генерации видео https://www.youtube.com/watch?v=HK6y8DAPN_0

Жду этого релиза даже больше чем было с gpt4.

Апдейт по подкасту

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

Решили остановиться на Павле Ахметчанове из Тинькоффского T-meter и позвать его.

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

Кладезь информации по тому как прогнозировать время выполнения задач https://habr.com/ru/companies/tinkoff/articles/782012/, честно, более информативной статьи по теме я не видел.

Вот несколько вопросов, на которые вам поможет найти ответ статья:
- Какой вопрос лучше для оценки - закрытый "можно ли эту задачу сделать к сроку Х?" или открытый "к какому сроку можно сделать задачу?"
- Есть ли в реальности корреляция между сторипоинтами и часами? И можно ли перегнать сторипоинты в часы? (самое любимое для всех менеджеров)
- Что означает "длинный хвост" на графике сторипоинтов команды (если у вас есть небольшое количество задач по 21, 34 и 55+ сторипоинтов);

И подкаст https://lida-taimova.mave.digital/ep-2, уже для более базового уровня понимания, который поможет с ответами на вопросы:
- Оценка сроков против оценки объемов - что лучше?
- Почему оценка часто вытекает в "что делать"?
- Получение оценки - это ответственность менеджера или команды?
- Какой метод оценки внедрять в новой команде?

Что такое хорошо и что такое плохо

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

Меня всегда заставляют задуматься такие простые интерпретации сложных вопросов. И вечером после того, как сессия закончилась, я полез искать, как эта мысль могла звучать в оригинале, ведь явно всё придумано уже до нас.

И оказывается, этот подход называется аргументом скользкого склона в философии. И применяется вплоть до дискуссий про одобрение/отмену эвтаназии.

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

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

Про поддержку своих

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

И в Skyeng я уже скидывал наш youtube канал, на который подписался и теперь регулярно смотрю сам. А теперь Skysmart стал информациионным партнёром документального цикла-расследования «1/8 Земли: Визионеры России». Этот фильм — о том, а чего крутого сделали и добились люди в нашей стране.

Первая серия https://www.youtube.com/watch?v=F5Ys4LKPfdU рассказывает про сельское хозяйство. К примеру, вес животных уже можно измерять через computer vision в реальном времени. Я хочу себе такие весы домой!)

Как называть продуктовые команды разработки

Когда я был разработчиком и приходилось погружаться в старый код, то всегда восхищался фантазии людей, как можно назвать переменную или метод. int yyyyy = 0 вообще кайф или метод func vybratPosledniiRaz() еще круче.

И так как карьера у многих не стоит на месте, то ребята с богатой фантазией идут управлять командами разработки.

Встречайте! Мой топ советов как стоить называть команды разработки. Не стесняйтесь использовать у себя, это ценнейший опыт, который я собирал десяток лет. Все совпадения случайны.

1) Используйте только номера для названий команд. Упрощайте! Назовите все свои команды номерами: Команда 1, Команда 2, Команда 3. Юнит 1, Юнит 2, Юнит 3. "А сходи узнать статус задачи в команде 5 в Юнит 3 - что может быть проще для новичка"?

2) Используйте аббревиатуры и акронимы. Чем больше аббревиатур, тем лучше. Неважно, если никто не может вспомнить, что они означают. В конце концов, расшифровывать их — это отличный способ потратить время и можно его даже затрекать в jira, чтобы все видели насколько вы заняты! Команда ППС - это команда платформенно-продуктовая статистика или команда пистолета-пулемета Стечкина? Еще круче только с английскими акронимами. Команда FC - это fintech services или finance services или finance support? Да какая разница, всем же весело на встрече!

3) Используйте внутренние шутки и сленг. Назовите свои команды исключительно внутренними шутками, которые понятны только участникам команды. "Последователи Мавроди" - команда, которая отвечает за маркетинг, или "Защитники базы" - команда devsecops. Сразу же понятно людям со стороны, что вы делаете в команде.

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

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

Эти примеры подчёркивают важность использования понятных названий для продуктовых команд. У меня лично от этих фантазий горит иногда.