Сначала сказал "нет", а потом придумал, почему

Иногда я слышу, как человек отвечает резко "нет, ..", а потом задумывается и начинает формулировать, почему же его собеседник идёт нахрен вместе со своим предложением. 🤔

У разных исследователей и авторов книг по софтам есть общая концепция "быстрого" и "медленного" мышления. "Быстрое" — обезьянка по Дорофееву, Система 1 по Канеману, Лимбический/Рептильный мозг по Маклину.

Так вот. Эта первая реакция "нет" — плод "быстрого" мышления. У нас не было возможности задуматься, почему "нет". Это просто оборона. Или "бей и беги".

Сказав "Нет", мы попали в ловушку. Теперь мы вынуждены придумывать, почему "нет". А дальше вынуждены упарываться до последнего или признавать собственную неправоту (что сложнее).

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

Без этого знания вы можете обнаружить себя в "продавливания" своей идеи или в демотивации от обесценивания.
Обладая этим знанием, вы можете подумать, как помочь собеседнику настроиться на восприятие. Например, проговорить, что вы понимаете его чувства и ситуацию с его стороны. Проговорить его аргументы. "Выложить все карты на стол". Или отступить. Главное, — вы сэкономите свой ресурс.

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

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

А пока будете думать, подумайте, что вы могли бы ответить, начиная с "Да, и ...". Как можно развить идею, которую предлагает собеседник? Показав уважение к его мнению и идее, вы можете рассчитывать на взаимность.

​​Вебинар про Soft Skills

Привет! Сегодня в 19 часов будет мой второй вебинар в совместном курсе от Райфа и Слёрма. Буду рассказывать про Soft Skills. Курс уже близится к завершению и записаться не получится, но вебинары проходят в виде открытой трансляции на ютубе. Поэтому можно посмотреть все вебинары по запросу
Курс "Разработчик, или от Мидла до Сеньора"

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

На горизонтальной оси степень конкретности навыка. Те навыки, у которых есть наблюдаемые проявления, — наиболее конкретные. Например, фасилитация встреч, публичные выступления или навык проведения интервью.

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

На вертикальной оси расположил степень взаимодействия с другими. Навыки "про себя" — те, для проявления которых нужен только сам человек. Допустим, та же рефлексия.

Навыки "про коммуникацию" — понятно, чтобы коммуницировать, нужна вторая сторона. Допустим, разрешение конфликтов, — это про коммуникацию.

На этих квадрантах четко прослеживается степень сложности прокачки навыка:
— Конкретные про себя проще всего;
— Конкретные про коммуникацию чуть сложнее;
— Базовые про коммуникацию уже сложно;
— Базовые про себя — вообще жесть и перевоспитание поведенческих паттернов, которые формировались десятки лет.

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

Свои размышления про soft skills расскажу подробнее сегодня в 19:00 Мск.
Приходите!

Вебинар про Soft Skills

Начнем через 45 минут, трансляция будет туть: https://youtu.be/005M7w83P24

Про зарплату новых и текущих сотрудников

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

Почему так происходит?

1️⃣ — Рынок айти растет, спрос на айтишников превышает предложение. Поэтому срабатывает естественный механизм регулирования цены на товар.
2️⃣ — Компаниям приходится адаптировать свои процессы найма и вилки зп, чтобы продолжить нанимать.
3️⃣ — При этом внутри обычно нет процесса пересмотра зп до рыночной. Бывает индексация, бывают повышения в связи с повышением грейда. Но всегда отталкиваются от текущего уровня зп сотрудника. А рынок мог вырасти быстрее, чем сам сотрудник внутри компании. Этот же сотрудник может выйти на рынок сейчас и получить больше.

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

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

Допустим, текущий сотрудник Вася делает работу в нормальных условиях и получает рыночную зарплату Х рублей. Рядом с ним начинает работать новый коллега Петя, такого же уровня по hard skills, и тоже за Х рублей. Такая вот идельная картина мира, хотя мы с вами знаем, что обычно Петя приходит на 1,5Х.

Одинаковая ли ценность этих двух сотрудников? Конечно, нет. В момент выхода на работу Пети, производительность команды не только не вырастет, а даже упадет раза в 2. Потому что Вася будет тратить время на онбординг.

Таким образом, компания платит 2Х за 0,5 работы. То есть, компания инвестирует 1.5Х (зп Пети и половину зп Васи) в Петю в первые месяцы и получает отдачу только через полгода. Думаю, любая компания была бы рада нанять такого Петю, который с первого дня фигачил бы так же, как будто он здесь работает уже полгода. За такого Петю можно было бы даже сразу заплатить 1.5Х.

Оглянитесь. Ваш "Петя через полгода" уже здесь. Это Вася, и он фигачит здесь и сейчас. Я считаю, у Васи есть нехилая добавочная стоимость относительно кандидата с рынка. И это экономически выглядит рационально. Так почему же вы оптимизируете процессы и вилки для найма кандидатов с рынка, но не заботитесь о том, чтобы сохранить экспертов? Возможно, экономически целесообразно оценить Васю чуть выше рынка прямо сейчас?

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

​​Data-driven итоги года

Откопал свой план развития на 2021. Делюсь сокровенным :)
Вообще я должен был его пересмотреть и актуализировать летом. Но летом случилась смена работы и меня завалило. Тем не менее, смотрю сейчас в этот ИПР после долгого перерыва и радуюсь.

Hard Skills
🔧— Получилось прокачать JVM + Spring "на восьмерочку". Оценка вполне объективная, ее дали интервьюеры. Чуть позже я получил офферы на тимлида в Тинькофф и на техлида в Райф.
🔧— С NoSQL чуть похуже, хотя на тех же интервью оценили неплохо. Была задача, где прям погрузился в специфику, начитался статей и наобщался с экспертами, благодаря чему осознанно и аргументированно выбрали Cassandra вместо PgSQL и CockroachDB.

Soft Skills
Тут я объединю в группы, потому что одно тянет за собой другое.
💡— Развитие других, менторство + Эмпатия. Считаю, получилось неплохо качнуть. С несколькими разработчиками составил ИПР и в формате менторства прошли по ним. Эмпатию и активное слушание очень хорошо получилось прокачать, когда помогал команде решать некоторые внутренние конфликтики. 1-1 с каждым раз в неделю по полчаса — польза не только для команды, но и для меня в плане прокачки этого навыка.
💡— Системное мышление, Понимание процессов продуктовой разработки
1. Получилось поучаствовать в трансформации нескольких процессов в QIWI, замечая системные проблемы и аргументируя способы их решения. Аналогично и в Райфе, но пока я больше на этапе сбора информации и понимания других процессов продуктовой разработки.
2. Этот канал. Это офигенный способ отрефлексировать, структурировать свои мысли, прийти к умозаключениям.
💡— Презентационные навыки. Персональный бренд.
Очень сложно оценивать объективно. В этом помогает обратная связь после вебинаров на Слёрме. Кстати, пост с метриками второго вебинара я так и не опубликовал. Обещаю исправиться в ближайшие пару недель.
В общем, я и мечтать не мог о суммарном охвате двух вебинаров в 15к просмотров и 500+ отзывах в гуглоформе.
А еще ведь есть сезон Podlodka HR Crew, который я провел в составе ПК.
А еще было выступление о продуктовой разработке на оффлайновой QIWI Server Party.
А еще мы провели онлайн OpenSpace митап на базе этого канала!
А еще несколько внутренних митапов в QIWI и Райфе.
А еще я провел для внешней компании обучение инженерным практикам на стыке JVM-бэка и PgSQL (хозяйке на заметку :)

💎Про этот канал
Я завел его осознанно, с целью прокачать системное мышление, понимание продуктовой разработки, презентационные навыки (текстовую коммуникацию) и персональный бренд.
Первые посты начал прописывать ровно год назад. Создал канал, наполнил 10 постами. Попросил обратную связь у авторов больших каналов. Переписал 10 постов, и начал привлекать аудиторию. Первой сотней были коллеги из QIWI. Спасибо, вы навсегда в моем сердечке :) А еще спасибо всем, кто давал обратную связь на посты перед публикацией и всем коллабам! На картинке к посту метрики канала, и они значительно выше моих ожиданий год назад.
План по аудитории я перевыполнил на 40%. Платное привлечение довольно хреново работает, особенно на маленьком канале. С помощью рекламы у меня получилось привлечь около 300 подписчиков, и последнюю рекламу я давал 23 марта. На отметке 500 подписчиков я перестал давать рекламу. Дальше — органический рост и взаимопосты с другими каналами. Самый большой эффект дали вебинары на Слёрме. +400 подписчиков, это считай треть всей аудитории. Надо бы подготовить подборку зашедших постов про продуктовую разработку.

Итог и пожелания

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

Желаю осознанности в 2022. Прокачать то, что хочется прокачать. Составить план развития, включить в него и Hard Skills и Soft Skills. Идти по этому плану, актуализировать и корректировать его (а не как я), и в следующем декабре оглянуться на год назад, посмотреть на свой план, и сказать себе: "Да, оно того стоило".

Cassandra vs. PostgreSQL

Я люблю PostgreSQL и всем рассказываю о том, какая это универсальная СУБД с инструментами и расширениями на все случаи жизни. И когда встает вопрос хранения, в первую очередь всегда думаю о PgSQL.

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

Расскажу про один из таких кейсов в формате "Условие" - "Сравнение двух СУБД".

1️⃣ Условие – Одна табличка без связей и логики. Одна запись на один платёж. Платежей – миллионы в сутки. При этом реляционная модель и транзакционность не нужны.

Внутреннее устройство реляционных СУБД здесь будет скорее мешать. Движок MVCC ничем не пригодится и скорее создаст проблемы. Миллионы записей в сутки очень быстро приведут к деградации на одной таблице, нужно делить данные между таблицами. В PgSQL администрировать партиционирование или шардирование нужно самим, и это еще одна механика, за которой нужно следить.

Вы не подумайте, что в Cassandra можно хранить только одну таблицу) Просто такой кейс. Ограничение Cassandra – отсутсвтие JOINов. Поэтому приветствуется денормализация данных, чтобы доставать всё из одной таблицы. Подробнее о проектировании структуры хранения в Cassandra: https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_rdbms.html
А такой объем данных – не много, и из коробки есть обязательное шардирование между нодами, которое называется там партиционированием).

2️⃣ Условие – Нужны самые быстрые вставка и чтение, которые только возможны. При этом данные – критичные и могут повлиять на конверсию платёжной формы. Читай, платежи ходить не будут, если потеряется.

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

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

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

3️⃣ Условие – Читать будем только по первичному ключу.
Это ограничение Cassandra, и в этом кейсе мы по нему проходим. Вообще очень важно понимать ограничения, мне в этом помогла статья коллеги на хабре: https://habr.com/ru/company/qiwi/blog/486800/

4️⃣ Условие – Повторное чтение данных не нужно. То есть данные одноразовые. А старые данные будут мешать и со временем приведут к деградации системы. Надо их как-то чистить.

DELETE в PgSQL – не лучшая идея, хотя и возможная. Типа, чистить сразу после прочтения. Но фактически это лишняя нагрузка на запись и необходимость последующего vacuum (сборки мусора). Поэтому мы решали бы эту задачу с помощью партиционирования и дропа старых партиций.

А в Cassandra есть встроенная механика TTL (Time To Live) записей. Можно прямо при вставке указать, типа INSERT ... USING TTL 1800. Есть свои нюансы у этой механики, но подкупает факт, что она предусмотрена из коробки.

Итог

Выбрали Cassandra, потому что она автоматом решает проблемы, которые нужно было бы решать руками на PgSQL.
Признаюсь, я хотел попробовать Cassandra, и это было в моем ИПР. Но я не тащил её в первую попавшуюся задачу, а дождался подходящей, поисследовал вопрос, пообщался с экспертами, выписал аргументы за и против, презентовал команде и мы все вместе приняли это решение.

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

Подборка постов про процессы и артефакты продуктовой разработки

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

📜Откуда появляются задачи — Проработка бэклога
Как понять, что задача проработана — Definition Of Ready (for Sprint)

📜Что значит ”Задача сделана” — Когда заканчивается работа разработчика
Как всем одинаково это понять — Чеклист Definition Of Done

📜Ревью спринта, отличие от демо

📜Три лайфхака к ретроспективе

📜Почему техдолг называют долгом и как это объяснить бизнесу.
2 поста про техдолг — Технический долг — как кредит
2 поста, как поступательно бороться с техдолгом — Как совмещать бизнесовые фичи и развитие инженерки с разгребанием техдолга

📜 Как понять, кто есть кто в команде — StarMap — карта компетенций команды

📜 Как мы составляли StarMap, Definition of Ready, Definition of Done — фреймворк встречи

Про взаимодействие разработчиков внутри команды

Каждое утро наша команда собирается и каждый рассказывает, что делал вчера и что будет делать сегодня. Один разработчик провел эксперимент: на дейли он говорил не связанные по смыслу вещи. Из 10 человек заметили двое. Возникает резонный вопрос: если друг друга никто не слушает, зачем это нужно?

...

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

Потом пришло понимание, что совместная работа не особо нужна, если в спринте 10 разных задач, не объединенных общей целью. Зачем на дейли вникать в работу коллеги, если у самого и так голова от своей задачи пухнет? Да и помочь вроде бы особо не можешь: погружаться в контекст дольше. Какой тогда смысл от дейли? Вот и получается, что все говорят в формате отчетности, что вчера делали и что сегодня будут. А кому эта отчетность нужна — непонятно. Вроде бы и так все взрослые люди и потребности в контроле нет.

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

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

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

...

Мой идеал дейли — когда все и так знают, кто чего делает, а на дейли приходят, чтобы задать друг другу простой вопрос:
"Мы успеваем по цели спринта?"

Продукт vs проект, и в чем разница для разработчика.

Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.

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

В продуктовом подходе сначала быстро делают бытовку и в ней сразу начинают жить. Потом, если оказывается что жить здесь можно, бытовку начинают перестраивать. В новой версии учитывают специфику местности. Например, добавляют теплоизоляцию и отопление. И так итерациями улучшают, делая более подходящим под изменяющиеся условия. Если рядом построили дом с вечеринками, можно добавить нашему дому шумоизоляции в новой версии.

Что это значит для разработчика?

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

В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.

Поэтому в продукте так важно «правило бойскаута»:
«оставь место стоянки чище, чем оно было до твоего прихода». Чистка не обязательно должна быть глобальной, достаточно почистить хотя бы небольшой кусок кода, режущий глаз.
© Роберт Мартин

Разработчик — больше чем профессиональный кодер

Я программист и я ненавижу встречи — с такой установкой я довольно долго жил. Десять черных квадратиков собрались, побухтели и разошлись. Встречи без четкой агенды, без плана, без цели, без итогов, без визуализации и без камер. Ууу аж трясёт!

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

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

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

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

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

Поэтому в следующий раз, когда будете бугуртить, что встреча долгая и бестолковая, задайте себе вопрос: а что вы как профессионал сделали, чтобы она прошла продуктивно?

​​Привет!

Ребята из Слёрма позвали меня провести вебинар на курсе про Soft Skills. Тема — "О чем спросить работодателя прежде чем принять оффер".

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

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

Курс платный, но для вас я договорился 🙂 Промокод Nikita22softskills, действует для первых 10 человек. (upd. проходки разобрали, чуть позже сделаю розыгрыш еще пачки)

Промокод действует на тариф Ладно, давай попробуем! — это вебинары + практические занятия. Его нужно будет ввести при регистрации на странице https://slurm.io/soft-skills

Смены работы пост

Авито. В эту компанию я пытался попасть еще в 2015 году, как мидл php разработчик. Тогда не потянул интервью: не вспомнил сигнатуры встроенных методов. Впрочем, и сейчас не вспомнил бы. Хорошо, что не спросили 🙂

Тогда интервью на 100% зависело от интервьюера и разные кандидаты получали разный опыт. Сейчас Авито стремится выровнять опыт всех кандидатов и выстраивает стандартный пайплайн.

Для разработчиков этот пайплайн следующий:
— Платформа (Go, PHP, JS, Python)
— Алгоритмы
— Проектирование
— Финал с руководителем

У меня вместо платформы было менеджерское интервью. Спрашивали про опыт управления командой, развитие, процессы и всякое мемеджерское.

С каждым из интервьюеров мы болтали после интервью еще минут 30, а то и час. Все были открыты и рассказывали интересные штуки про компанию.

И вот я вышел в первый день и увидел сам то, о чем слышал и читал.

— Ко мне подходили ребята из соседних команд. Знакомились, рассказывали, чем они могут помочь, и на что стоит обратить внимание
— Если встреча по зуму, то все включают камеру. Черный квадратик — скорее исключение
— Developer Experience. В первый же день я посмотрел на логи и метрики компонентов в зоне ответственности нашей команды. А там на графиках миллионы запросов в минуту. Вот это нагрузка! Platform as a Service это вообще отдельная песня. Рай для продуктового разработчика.

За прошедшие 4 недели я успел:
— Познакомиться с командой и соседями
— Перетряхнуть годовой роадмап проекта вместе с командой. Такой экспресс-онбординг
— Презентовать этот роадмап СТО
— Составить план на квартал
— Подгототовиться к перформанс-ревью и калибровкам. Сейчас защищаю премии и промо своим ребятам.

Я уже писал про performance review. Тогда мы прикручивали этот процесс в QIWI, с оглядкой на Авито. Сейчас я попал в первоисточник 🙂 Очень хочу написать апдейт к тому посту. И вообще появилось стопицот тем для постов. Stay tuned!

Performance Review изнутри

Апдейт поста годичной давности про Performance Review
Там всё актуально, но вот я побывал внутри этого процесса и хочу рассказать, что меня удивило.

После написания селф-ревью и сбора фидбека от коллег, начинается общекомпанейский процесс калибровок.

Раньше я видел ситуации, когда два инженера нанесли схожую пользу, при этом одному из них дали повышение, а другому — ничего

Калибровки нужны, чтобы избежать таких ситуаций.

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

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

На деле было не так.

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

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

— А еще бывает, что у тимлида не растут инженеры. Не потому, что инженеры фиговые, а потому, что тимлид не обращает внимания на их достижения. Я понял, что калибровка — в том числе способ обратить внимания тимлида на успехи инженеров.

Таким образом, калибровки выравнивают опыт инженеров по всей компании.

Обратная сторона медали — временной оверхед калибровок. Процесс полезный, но дорогой. Впрочем, всё ради Developer Experience.

Попозже расскажу еще о процессах в Авито, построенных ради Developer Experience и Time To Market. Например, у каждой команды есть оценка уровня зрелости процессов — Team Maturity Model (TMM). А еще есть оценка уровня совершенства тех. компонентов — Service Excellence Score. Прямо сейчас считаем нашу оценку по TMM, чтобы найти слабые места и придумать, как улучшить.

​​Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение?

Вопрос из комментов к прошлому посту про калибровки.

Есть встречный вопрос: какие от тебя ожидания сейчас?
Если не знаешь, как узнать?
Простой ответ на все вопросы — поговорить с руководителем.
Рост всегда зависит от руководителя. Даже если есть формализованное описание, как достичь следующего грейда, — всё равно решение о промо зависит от понимания руководителем твоих достижений. А если этого формализованного описания нет, — тем более.

Хочу написать пару слов о том самом формализованном описании грейдов.

У Авито есть публичный Playbook: ссылка на github, его как раз недавно актуализировали

Представим инженера Петю. Петя Е4 и хочет идти на Е5 к следующему Performance Review. Для этого Пете нужно показать, что он уже делает то, что ожидается от Е5.

Петя заполняет таблицу таблицу соответствия текущей и следующей компетенции, по ней строится график windrose — лепестковая диаграмма, которую иногда называют колесом баланса.

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

Тимлид и инженер вместе смотрят, в какую сторону смещено колесо баланса, и решают, что нужно подтянуть. Наш герой уже достаточно экспертный для Е5, но он пока не очень делится этой экспертизой. У него есть сложности с коммуникацией, а еще он не всегда думает о ценности для бизнеса. Вот эти навыки и будем подтягивать за полгода

В сокращенном варианте план развития Пети может состоять из трёх пунктов:

Обучение себя и других — не только онбордить, но и полноценно менторить младшего инженера Васю. В качестве теории Пете стоит пройти курс по наставничеству. Далее он может нарисовать с Васей Windrose и построить его план развития. Проводить регулярные синки, помогать расти. Может быть, научить проводить интервью. Еще можно начать участвовать в комьюнити, сделать несколько докладов за полгода.

Коммуникация — Начать осознанно фасилитировать обсуждения. Для этого можно прочитать книгу "Руководство фасилитатора" и практиковаться, практиковаться, практиковаться.

Ориентация на бизнес — Начать интересоваться фидбеком пользователей: читать результаты пользовательских исследований и обсуждать с командой и PO выводы.

Рост от Е4 к Е5 — фактически рост от мидла к сеньору. Это уже в большой степени про Soft Skills и склад ума. Когда Петя на автомате будет делать выше перечисленное, он качественно перейдёт на новый уровень. И тогда он справедливо получит промоушен. А помогут ему в этом простые шаги и идеи, которые подкинет составленный Windrose.

Будь как Петя, составь индивидуальный план развития 🙂

Windrose template для собственного развития

В комментах к прошлому посту просили эксельку, в которой можно построить розу ветров, чтобы определить вектор развития. Я сначала думал, что Авитошная никому особо не пригодится, потому что везде свои матрицы компетенций. А вот фиг. За прошедшие 2 недели на hl++ и на tlconf общался с ребятами из разных компаний и узнал что 5 человек использовали Авитошные матрицы как референс. Значит, можно поделиться as is.

В общем, держите: Avito Windrose Template
Согласовать внутри это было легко. Особенно, с учетом того, что сами компетенции есть в публичном playbook на гитхабе.
Документ read-only, чтоб случайно не попортили.
Можно скопировать себе и заполнить, построить windrose и определить вектор развития 😉

Upd 07.04.2024: Пост актуален, прошлый гуглодок пал, обновил ссылку на новый. Привет из будущего 🙂

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

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

Даже если процессы отлажены и описаны, всегда можно что-то улучшить. Вопрос, что именно и как можно сделать лучше. Иногда мы находимся в зоне неосознанной некомпетентности по процессным вопросам, и не понимаем, что именно стоит улучшать и как именно.

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

А может быть не так очевидно. Например, у нас потихоньку выгорает один из разработчиков из-за непонимания собственного вклада, но это никак не проявляется. Это можно выяснить на 1-1, а можно и проморгать. Решением могло бы быть внедрение короткого healthcheck-опросника перед ретроспективой. Мы третий спринт проводим такой опросник и за его результатами интересно наблюдать в динамике. Когда наберется хотя бы 5 результатов, поделюсь.

Уровень зрелости процессов в разных командах разный. И улучшения могут быть разные.

Team Maturity Model — модель зрелости команды, инструмент для осознания текущего уровня зрелости, понимания векторов развития и конкретных шагов по улучшению процессов.
Сейчас в Авито это реализовано как убер-экселька, в которой перечислены разные области командных процессов: InfoSec, QA, FE, BE, Perf., Delivery, Discovery, Analytics, Design.

Прошлый пост с Авитошной экселькой Windrose Template пошарили 54 раза (нифига себе).
Поэтому вот еще одна убер-экселька: Модель зрелости Авито в гугл-документе.
Как ею пользоваться — читайте в статье на хабре: Модель зрелости: как оценивать и растить инженерные команды🙂

Привет, есть две офигенные новости!


1️⃣ — Я тут вписался в программный комитет Podlodka Teamlead Crew: Change Management.

Это будет неделя качественных докладов про управление изменениями в команде. Поговорим о том, как понять, что изменения нужны и какие именно. Как их внедрять, работать с сопротивлениями и возражениями. Будут реальные инструменты и фреймворки. А еще будет сессия разбора фейлов. Приходите!)
Стартует 27 июня. Билеты тут: https://podlodka.io/tlcrew. Для своих есть промокод product_developer.


2️⃣ — В преддверии сезона мы делаем открытую бесплатную сессию — публичное собеседование на роль тимлида.
23 июня в 19:00.

Интервьюер — мой коллега, Женя Рейх из Авито.
Technical Cluster Lead, менеджер менеджеров тимлидов, Bar Raiser в собеседованиях тимлидов в Авито. Когда я собеседовался в Авито, эта секция мне понравилась больше всего. И я хочу показать миру, насколько круто собеседуют тимлидов в Авито 🙂

Кандидат — мой бывший коллега по Райфу и Слёрму, Лёша Ломаев.
Техлид трёх команд в Райффайзене. Человек, репортящий напрямую СТО. Адепт гибких методологий в продуктовой разработке.
Что примечательно — Лёша собеседовал меня в Райффайзен 🙂

В процессе интервью Женя будет рассказывать зрителям, зачем он задает такие вопросы. А Лёша даст свои комментарии, пошел бы он работать в компанию, где от кандидатов требуют такое.

Ссылка на трансляцию https://youtu.be/hMdcLG2xPHI
Стартуем 23 июня в 19:00

Разрабы vs. Тестеры

Вот мы делаем продукт. Все понимают: «Надо делать качественно».
Прикол в том, что это в этой фразе слово «качественно» — абстрактное понятие, которое каждый понимает по-своему.

Нипанятна. От меня вот фичу требуют, пойду лучше её запилю.

Ок, давайте наймём отдел QA. Пусть обеспечивают это самое качество. Им виднее, что это такое. На вход им дадим результат работы отдела разработки.

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

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

А программистам введем такой же KPI, только в обратную сторону. Чем больше багов, тем меньше премия.

И да начнётся битва, в которой не будет победителей! 😄

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

=============================

Agile Shift Left Testing

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

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

Agile Shift Left Testing даёт максимально раннее обнаружение багов. В одном спринте нашли баги новой фичи, починили и покатили в релиз. Таким образом сокращаем Time To Market при сохранении качества.

Концепт звучит просто: QA — часть кроссфункциональной команды, и участвует на всех этапах жизненного цикла фичи, начиная с проработки задачи.

На деле всё чуть сложнее. Сходу упираемся в то, что в кроссфункциональной команде не помещаются несколько QA. Плюс, платформ дофига: 2 мобильных, десктоп и мобильный веб, а еще бэкенды. Один QA не вытащит это всё тестить руками или покрывать тестами.

Получается, надо вовлекать разработчиков.

QA инженер с точки зрения Agile Testing — главный стекхолдер качества внутри команды, который знает ответ на вопрос «что такое качество?».

При этом основная задача QA — не тестить всё самому, а:
1️⃣ — Менторить разработчиков в написании тест-кейсов
2️⃣ — Показывать своим примером, как нужно писать e2e тесты
3️⃣ — Следить, чтобы пирамида выглядела как пирамида

В наших командах разработчики уже сейчас пишут тест-кейсы на этапе декомпозиции фичи, а часть слоев тестов зафиксированы в Definition of Done. И пишут их не только QA, а все инженеры.

KPI при этом отстутствуют. Но есть квартальные планы, которые нужно разработать с заданным в DoD уровнем качества. А еще есть Zero Bug Policy. Это когда мы либо фиксим баг в ближайшее время, либо осознанно говорим, что не будем его исправлять.

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

Кажется, Agile Testing — это ответ. А какой был ваш вопрос? 🙂

Подробнее можно почитать в стате на хабре:
https://habr.com/ru/company/avito/blog/458940/

Ищу Mobile QA к себе в команду

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

Кстати, наш iOS разработчик — один из олдов этого канала. Есть возможность составить ему хорошую компанию, ну и со мной поработать 🙂

Мы тут делаем Авито Паспорт. Это тектонический сдвиг в том, как Авито работает с аутентификацией и профилями пользователей.

У нас есть сильный QA с опытом в бэке и вебе.
А вот в мобилки мы не умеем.
Ищем человека, который научит.

От кандидата ждём:
— Желание и умение прорабатывать фичи на ранних этапах
— Опыт в тестировании мобилок, которым готов делиться
— Kotlin / Java и (или) Swift
— Желание делиться знаниями. Все фичи сам не протестишь 🙂

Про задачи, условия, плюшки и рефералку подробно расскажу в лс: @nikita_development

Почитать вакансию на карьерном сайте: https://www.avito.ru/company/job/qa_pssprt

Бесплатный курс iOS QA Automation

Раз мы тут заговорили о роли QA в Авито, то вот отличный пример — QA инженер из соседней команды обучает автоматизации тестирования под iOS.

Борис делится экспертизой:
— Пишет статьи на хабре;
— Ведёт канал в телеге iOS Automation Testing;
— Выложил в открытый доступ свой курс iOS Automation. Этот курс создан для того, чтобы Manual QA поняли, как писать ui-тесты на iOS.

Во-первых, рекомендую подписаться на канал.
Во-вторых, с радостью рассмотрим опытных ручных тестировщиков, которые прошли курс Бориса 🙂

https://www.tg-me.com/ios_automation_testing/189