Про руководство разработкой и продуктом | Олег Мохов
3.48K subscribers
168 photos
3 videos
2 files
183 links
Привет, я Олег. Software engineering manager в Контуре, в прошлом руководитель отдела в бигтехе. Пишу про свой опыт управления продуктом и разработкой.

Для связи: @olegmokhov
Download Telegram
Вау! 3 тысячи, спасибо каждому кто читает этот канал, пишет в комментарии и репостит. Так как здесь много новых людей, то настало время сделать навигационный пост, чтобы не пропустить самое интересное.
15👍9❤‍🔥6🥰1
Привет, меня зовут Олег.

Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level).

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

Мой манифест работе — понедельник начинается в субботу.

Подходы к управлению
Ситуационное лидерство
Всегда действовать в интересах команды
Минимальный жизнеспособный сотрудник и правила работы со мной
— Про одну из ролей продактов и закон Йеркеса-Додсона
— Про нагрузку на команду и формулу Кингмана

Командные встречи и 1х1
Как часть нужно общаться командой?
Как давать корректирующий фидбек (Алгоритм Хорстмана)
Метод 5П для встреч один на один
Метод ORID
Обратные ретроспективы

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

Про найм и увольнения
Факторы сениорности
Как нанимать лучших
— Почему я люблю вопрос «Какое у тебя хобби» и почему он про выгорание.
Как увольнять, сохраняя достоинство
Что делать если вас уволили?
Про то почему волки — читеры
Сломан ли найм и как его начать чинить

Про Performance Review
— Как давать фидбек друг на друга. В трёх частях: первая, вторая и третья.
Как калибровать людей
— Зачем калибровать людей. Часть один и два.
— Про слепые калибровки

А также просто мысли о разном.
Как я начал читать и мой рейтинг книг, прочитанных в 2024 году.
— Про икигай и смысл жизни
Как я научился Power Nap'ам.

А ещё я делаю обзоры на книги и доклады. Их можно найти по тегам — #книгобзор@teamleading и #докладобзор@teamleading.
130👍18👏4🥰1🙏1🕊1
Про руководство разработкой и продуктом | Олег Мохов pinned «Привет, меня зовут Олег. Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level). Здесь я пишу свои мысли на разные темы. Вот некоторые важные посты, разбитые на тематики. Мой манифест…»
Полезняхи про встречи и оплату за рубежом

Никита Дубко недавно написал про одну галочку в Zoom, которая может сэкономить минуты, а я вам сегодня расскажу про своё недавнее открытие.

«Кстати, а кто Action Items у нас записывает?» — знакомо? Если у вас есть такая же проблема как у меня, а именно вы активно вовлекаетесь во встречу, а после не помните что обсуждали и до чего договорились, то у меня есть для вас решение.

Сервис Bluedot. О нём мне рассказал Лёша Симоненко — он первым начал приносить созвоны со спикерами на встречи ПК FrontendConf. И я офигел от того, насколько там крутая расшифровка и суммаризация. И вдвойне клёво, что он легко встраивается в Google Meet. Как и в любой другой созвон в браузере.

Специально для этого поста мы с Лёшей записали пробный созвон, в котором обсуждаем прошедший Saint TeamLead Conf. Признаёмся, были всего на нескольких докладах, но даже несмотря на это, Bluedot выделил один AI:
Олег:
• Пересмотреть доклад «Когнитивные ловушки Тимлида, инструкция по выживанию» от 27 июня.


Удивительно, как даже в постановочной встрече можно получить полезное напоминание.

Параллельно Зар Захаров рассказал мне про Pyypl — способ платить за Bluedot (и Netflix, и ChatGPT) без всяких банковских сложностей и выездов за границу.

В общем делюсь с вами рефералками на Bluedot и Pyypl.

Оба сервиса проверены — можно пользоваться.
1🔥126👍3👏1😁1
Сколько часов в неделю нужно работать?

Эту неделю я хочу посвятить книге «Идеальный программист» Роберта Мартина. Что я сам понимаю в разработке — у меня всего-то 20 лет коммерческого опыта. Поэтому давайте попробуем довериться человеку с 55-летним стажем. Ниже — цитата из книги (с моими пометками курсивом):

«Вы обязаны (по трудовому договору именно обязаны) своему работодателю некоторым количеством времени и усилий. Для примера возьмём стандартную для США (и для России) 40-часовую рабочую неделю. Эти 40 часов должны быть проведены за решением проблем вашего работодателя, а не ваших личных проблем

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

Наверняка вы подумали: «А как же моя семья? Моя личная жизнь? Я должен пожертвовать всем ради своего работодателя?»

Я не говорю обо всем вашем личном времени. Я говорю о 20 дополнительных часоах в неделю. Если вы будете использовать обеденные перерыв для чтения и прослушивания подкастов и ещё 90 минут в день на изучение нового языка (программирования) — это решит все проблемы.

Давайте немного посчитаем. В неделе 168 часов. 40 достается вашему работодателю, ещё 20 — вашей карьере. Остаётся 108. 56 тратится на сон, на всё остальное остается 62. Возможно, вы не хотите брать на себя подобные обязательства. И это вполне нормально, но тогда не считайте себя профессионалом. Профессионалы не жалеют времени на совершенствование в своей профессии.

[...]

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

Может показаться, что мой путь ведет к «выгоранию» на работе. Напротив, он помогает избежать этой печальной участи. Вероятно вы стали разработчиком из-за своего энтузиазма к программированию, а ваше желание стать профессионалом обусловлено этим энтузиазмом. За эти 20 часов вы будете заниматься тем, что подкрепит ваш энтузиазм. Эти 20 часов должны быть интересными!»

©
Роберт Мартин «Идеальный программист», издательство Питер

Мне очень нравится мысль о том что саморазвитие — это работа на себя и свою карьеру. Сложно написать лучше чем сделал это Роберт. Но всё же хочется чуть поспорить с категоричностью: «если не тратишь 20 часов на себя — ты не профессионал».

Эта фраза немного задевает. Что же получается — если я не работаю дополнительно 20 часов, то всё, баста? Нет. Я всё ещё специалист. Junior, Middle, иногда даже Senior. Просто без системного саморазвития я перестаю расти. А рост — это то, что отличает профессионала от просто опытного исполнителя.

Отдельно хочется отметить мысль «обязаны посвящать 40 часов работодателю». Возникает вопрос: «А что если я делаю работу быстрее?» В такие моменты я искренне восхищаюсь и при этом удивляюсь: если есть время — почему бы не сделать ещё лучше? Попробовать порефакторить, применить новые знания, поэкспериментировать. Мы ведь часто жалуемся, что у нас «нет времени на улучшения». А тут оно есть — и сам бог велел им воспользоваться.
14🔥158🤔6😁3💯3❤‍🔥2
Учиться — значит быть самоучкой?

Продолжаю разбирать «Идеального программиста» Роберта Мартина. Сегодняшняя тема это рост профессионала за счёт среды, в которую он себя помещает.

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


Мы часто воспринимаем развитие как нечто индивидуальное. «Хочу вырасти — пойду на курс». «Надо подтянуть алгоритмы — буду ботать литкод». «Хочу стать senior'ом — буду по вечерам делать pet-проект». Всё это правильно. Но...

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

Парадокс в том, что это некомфортно. Но именно это работает.

✳️ Саморазвитие ≠ изоляция

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

Они боятся выглядеть глупыми. И, например, признать, что не знают, что такое «каппа в Kafka» или не до конца поняли async/await. И в итоге человек годами читает статьи — но боится задать вопрос в общем чате. Боится попросить объяснить.

А потом оказывается, что он застрял в развитии. Он умный, опытный, но не растёт. Потому что варится в собственном соку.

🛠 Вот что я сам считаю наиболее мощными способами коллаборативного развития:

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

Для больших Merge Request'ов мы даже практиковали очное ревью. Когда два человека садятся рядом (или созваниваются) и один рассказывает что бы улучшил в коде другого. Эффективнее почти любого асинхронного ревью.

— Писать постмортемы, RFC, ADR, C4 и документацию самостоятельно — они требуют формулировать мысли. А значит — самому её осознавать.

— Архитектурные ревью — даже просто послушать обсуждение чужих решений уже полезно. А уж получить мощную критику (а на архи преимущественно только она) на свой код от гуру разработки — бесценно.

— Спрашивать «а почему вы сделали так?» у авторов кода — даже если MR уже вмержен. Это помогает не только понять решение, но и тренирует навык продуктового мышления.

— Менторство (в обе стороны) — объясняя, сам начинаешь лучше понимать.

— Парное программирование, mob-программирование, shadowing и прочие практики учиться у других в интерактивном формате (Про это будет отдельный пост).

— Ну и банальные small talk'и в офисе — именно поэтому я рекомендую хотя бы пару раз в неделю собираться всей команде в офисе, если есть такая возможность.

Я намеренно не стал здесь писать про ChatGPT и прочие AI-тулы. Да, ИИ-инструменты помогают. Но у них пока есть один минус — они не придут к тебе сами. Если ты не знаешь, чего не знаешь — то ты не задашь нужный промпт.

📊 И немного статистики

В исследовании от DORA (Accelerate State of DevOps), одной из ключевых практик высокоэффективных команд названы collaborative review practices — обсуждение архитектуры и процессов, не только кода.

В Stack Overflow Developer Survey 2024 «спросить у коллеги» второй по популярности способ поиска ответов на технические вопросы.

📌 К чему всё это?

Если вкладывать 20 часов в неделю в развитие (как предлагает Мартин) — то это не обязательно должен быть solopreneur-режим, когда ты тихо ночами проходишь курсы по Rust или в метро ботаешь «Грокаем алгоритмы». Иногда полезнее — обсудить код с мидлом из соседней команды. Или попросить дизайнера рассказать, как они думают про UX. Или предложить следующую задачку закодить парно.
1💯17👍8🔥7❤‍🔥21
Самая честная лекция про построение карьеры / Леся Набока и Люда Шведова

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

Это, конечно, разрыв. Настоящее пошаговое руководство по работе над собой для продактов, которым уже... ну, в общем, вы поняли. С Лесей я, волей случая, знаком лично, и могу сказать — она и в жизни говорит так же напролом, как в этом докладе. Без реверансов, без лукавства, по делу. И это кайф: все тезисы в докладе — ровно такие. С Людой, к сожалению и надеюсь пока, не знаком.

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

Ошибка 1 — Карьера с тобой случается
Лет 5 назад такое точно было, но в последние годы я уже чуть лучше понимаю куда хочу и что нужно делать.

Ошибка 2 — У тебя нет советника по карьере
И нет до сих пор :(
Уже есть! :)

Ошибка 3 — Ссышь и самозванствуешь
О, дааа.

Ошибка 4 — Ждешь, что работа будет только по любви
Вот здесь я все же считаю, что выбирать надо работу, в которой хотя бы граммулечка любви присутствует

👎 Ошибка 5 — Ты уверен, что ты продакт
Никогда не был уверен

👎 Ошибка 6 — Ты уверен, что ты хороший продакт
Тоже нет, причем если посмотреть на критерии хорошего продакта в докладе, то у меня 100% мэтч и даже после этого не считаю себя хорошим продактом. И да, мне не стыдно теперь признаться, что я слабо умею в юнит-экономику.

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

Ошибка 8 — Ты плохо упакован
Йеп

/👎 Ошибка 9 — Не умеешь искать возможности
Вот тут я всегда действовал сам и искал сам, но чего я не делаю — не ищу возможности рядом. Очень сильно замыкаюсь внутри своего домена.

👎 Ошибка 10 — Не строишь нетворк
Очень строю, даже этим постом :)

👎 Ошибка 11 — Ведешься на золото
Точно нет

👎 Ошибка 12 — Не знаешь свое профессиональное либидо
Я хорошо знаю в чём я силен и в чём нет. Причем я это всегда проговариваю на собеседованиях, чтобы не было ложных ожиданий.

👎 Ошибка 13 — Ты убегаешь из отношений
Точно нет, всегда честно говорю о том чего хочу и как, прежде чем начать движение на сторону (да и было-то такое пару раз всего)

👎 Ошибка 14 — Продаешься без мыслей о дальнейшей капитализации
Скорее наоборот очень даже думаю

👎 Ошибка 15 — Сидишь в болоте
Никогда не любил болото и максимально избегал его

При этом я много раз видел, как хорошие ребята топтались на месте, потому что раз за разом совершали какую-то из ошибок. Они не могли её победить (и часто даже не осознавали), а я формализовать.

Делитесь (если готовы) какие ошибки совершали вы? Так же рекомендую каналы Леси и Люды.

Все мои обзоры докладов по тегу #докладобзор@teamleading.
16👍6🔥4💯3🤯1
Три истории читерства

Я преподаю в ВУЗе. Делаю это больше 10 лет и недавно в одном молодёжном канале мне припомнили историю, что я когда-то не принял домашку у студента, потому что в задании на перевёрстку Яндекс.Почты он использовал переменные huyandex и govnopochta. Я назвал это неуважением к авторам курса, но не исключил студента, а просто отказался принимать конкретно ту задачу, даже на один балл.

Так вот, это воспоминание напомнило мне несколько историй читерства, о которых я хочу рассказать.

Лет 10 назад на одном из наших первых потоков по фронтенду, когда мы (команда из 8 человек) принимали задачи вручную без автопроверок и у нас не было антиплагиата один студент решил списать наивно, то есть просто заменив названия переменных. Рассчет был на то, что раз у кого он списывает был другой ментор, то это не вскроется. Был один нюанс — студент забыл скопировать часть кода. В буквальном смысле выглядело это так: он вызывал функцию, которой не существует. Так и спалился.


Несколько лет спустя меня позвали в комиссию по приёму дипломных работ. Обычно я там для того чтобы провалидировать пару-тройку работ по вебу, но так как остальное время ничего не делать скучно, то я слушал все работы. И вот выходит один парень и рассказывает про распознавание маркеров дополненной реальности с помощью обычной веб-камеры. Маркер это, например, листочек с черным квадратом на нём. Он буквально рассказывает следующее: «Я делаю снимок с камеры, а потом перевожу в ч/б. Пришлось долго подбирать коэффициенты чтобы картинки в ч/б было достаточно для распознавания маркера». После выступления я задаю вопрос: а как вы подбирали эти коэффициенты? На что получаю странный ответ: просто подбирал.

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


В этом году на экзамене по JS многие студенты активно пользовались GPT при решении практики, из-за этого мне активно пришлось давать дополнительные задания, которые GPT не всегда уже мог обработать. И вот один студент бьётся и не может решить задачу. Я несколько раз прошу его не пользоваться LLM и включить голову, но не получается, студент говорит мне что не пользуется. В конце концов, я сам ввожу в GPT то что вводит студент, и GPT выдаёт мне ровно его решение, которое не верное. Я это показываю студенту и приглашаю на пересдачу.

Справедливости ради, студент сдал на пересдаче сам, а потом ещё и извинился за тот раз.


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

Возвращаясь к истории в начале: а вы бы как поступили? Ну и рассказывайте ваши истории, если такие есть.
👍29
Попахивает вселенским совиным заговором, у волков появился конкурент 😄 (ну а если вы пропустили)
😁19❤‍🔥1😱1
Как ищется работа в 2025?

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

Я был в поиске 35 дней. При этом официально безработным 27 дней.

Я откликался на разных площадках, суммарно около 70 откликов.

Вот такие итоги, не считая офферов (проценты для удобства я округлял)
1. Отказы — 85%.

К отказам я отношу всё что в том или ином виде завершает общение со стороны работадателя. Чуть точнее в цифрах:
— 43% прислали сухой автоматизированный отказ
— 20% никак не отвечают, то есть спустя месяц я либо до сих пор значусь в системе «на рассмотрении», либо вакансия тихо отправляется в архив. Этим грешит и бигтех.
— 8% отвечают что закрыли вакансию или что есть финалисты. Иногда при этом вакансию продолжают держать как активную.
— 6% отказали после скрининга или технички.
— 6% — это на мой взгляд самые странные, они отвечают дополнительными вопросами (например спрашивают ожидаемый доход, или готов ли я ездит в офис каждый день) и пропадают после моего ответа.


2. Холд или пропали после первых собеседований — 12%

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


3. Я сам отказался после скрининга — 3%

Бывает что в процессе общения я сам понимаю что не готов продолжать и говорю что не буду.


Мне отказывали автоматически на вакансиях где был 100% мэтч и по резюме и по описанию. Самый смешной отказ был когда автоматически мне отказали, а параллельно рекрутер написала в личку со словами что нашла моё резюме и оно выглядит очень интересным.


Выводы которые можно сделать.

1. Рассчитывать исключительно на отклики не стоит. Это лотерея. С вами всё нормально, просто отказывают 8 из 10.

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

3. Не бойтесь активно писать что вы ищете работу. Мой честный пост полугодовой давности до сих пор приводит ко мне интересные контакты.


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

А куда я пошёл расскажу в следующих постах.
👍36🔥1611😁2🤔1🙏1🐳1
Новости FrontendConf

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

Вообще, программа конференции полностью утверждена, но есть одно но...
Нам нужна ваша помощь с выбором докладов в Главный зал! 🤍 💙

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

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

🔥 В благодарность за участие в голосовании вас ждут ссылки на наш архив из 467+ видео и промокод на покупку билета. Но не забывайте всё ещё и про мой промокод — fc25_teamleading, он кстати действует и при оплате от организации. 😊

📝 Проголосовать можно здесь до 31 июля.
7🔥1
Как правильно проектировать UX?

Есть одна книга, которую я рекомендую всем своим студентам на курсе по фронтенду в ИТМО. Перечитывая эту книгу в очередной раз я подумал, что ЦА этой книги гораздо шире и она в том числе подойдёт и продактам, и аналитикам, и конечно дизайнерам. Это книга «Разработка интерфейсов. Паттерны проектирования» авторства Дженифер Тидвелл, Чарли Брюэра и Эйнн Валенсии.

На мой взгляд, одна из причин, по которой книга незаслуженно обделена вниманием — это неудачный перевод названия "Designing Interfaces: Patterns for Effective Interaction Design". Я бы перевёл название так «Дизайн интерфейсов. Паттерны эффективного UX-дизайна». Это тот случай, когда продакт гуляя по книжному даже не возьмёт книгу в руки, потому что подумает что книга про разработку, а слово паттерны только усиливает ощущение того что книга для программистов. Из названия на русском не понятно что книга, на самом деле, про дизайн и UX.

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

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

Про то что иногда нужно упрощать интерфейсы, а не усложнять. Тут я вспомнил доклад с прошлого FrontendConf про дизайн интерфейсов на заводе.

Когда выделение красным или зеленым цветом указывает на важное различие, не забудьте также изменить форму элемента или добавить текст. Это связано с тем, что некоторые люди не различают эти цвета. По статистике, 10% мужчин и около 1% женщины страдают дальтонизмом в той или иной форме.

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

Это значит, что в интерфейсе должен быть доступен множественный выбор: щёлкая на элементах при нажатой клавише Shift, устанавливая флажки или захватывая несколько элементов при зажатой левой кнопке мыши.

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


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

Другие обзоры книг по тегу #книгобзор@teamleading
12👍5🔥4
Пятый третий элемент причинно-следственных связей

Прочитал статью Макса Дорофеева про «третий элемент» — один из мыслительных инструментов Голдратта. Он помогает делать причинно-следственные связи не просто красивыми, а работающими.

Когда мы строим гипотезы вида «для того чтобы A → мы делаем B», важно не скатиться в тавтологию. Голдратт предлагает добавить третий элемент — факт, который с одной стороны связывает A и B, а с другой не относится ни к А, ни к В.
Для того, чтобы быстрее чинить систему мы должны разработать документацию, потому что большинство сбоев - типовые, а служба технической поддержки (ответственная за их устранение) не имеет доступа к коду, чтобы самостоятельно во всем разбираться.


А вот без третьего элемента:
Нам нужна документация, потому что она помогает чинить баги быстрее


Давайте не из примеров Макса
Чтобы разработка могла «бежать быстрее» нужно замерять и снижать показатель Time to market, потому что это вскрывает узкие места текущего процесса и запускает цикл улучшений.


И без.
Чтобы разработка могла «бежать быстрее» нужно снижать Time to market.


То есть всё, на самом деле просто: нужно каждый раз спрашивать себя классическим вопросом менеджера — чтобы что? Если ответа нет (или он звучит как повторение уже озвученного) — нужно искать и докапываться, например принципом «5 почему». Без третьего элемента решения хоть и звучат логично, но на практике рассыпаются — потому что не все в команде понимают и принимают, почему мы это делаем.

© изображения к посту — Gaumont и Columbia Pictures
🔥86👍3😢1
ТОС — Теория ограничений систем Голдратта

Вообще, когда в русскоговорящем пространстве заикаются про Голдратта, то у многих в голове всплывает сразу же один человек — это Александра Брызгалова.

С Сашей я познакомился в апреле на ДАМПе и уже через час было ощущение что мы знакомы миллиард лет.

На Сашином сайте куча материалов по теме. Не буду выделять какой-то, а выложу тот, с которого сам начал знакомиться с ТОС от Саши. Это доклад на ДАМПе про то что такое эффективность. А если вы не любите видео, то вот расшифровка доклада.

В прошлом посте я писал про третий элемент причинно-следственной связи. И, пока писал, осознал что вопрос «А в чём цель?», который очень часто задаёт Саша в докладах — это один из способов поиска этого третьего элемента.

А ещё у Саши есть телеграм-канал.
3🔥94👍2🥰1😢1
Мыслетопливо в период испытательного срока

У Макса Дорофеева есть отличный термин — «мыслетопливо». Это такой внутренний ресурс, который мы тратим на размышления, принятие решений, обучение, творчество — на всё, где мозгу приходится работать, а не просто выполнять выученное. Как бензин для машины с ДВС: без него никуда.

Во многом техники Макса — как раз о том, как это мыслетопливо экономить, чтобы быть продуктивнее. Вот, например, пересказ его доклада с РИТ (если не открываются картинки — откройте ссылку в новой вкладке, у Хабра CORS), или подробная статья про джедайский инбкос.

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

▫️ Это нормально.

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

▫️Убрал лишние источники нагрузки

Если активно учить новый язык, заниматься в музыкальной школе, участвовать в квизах... то мыслетопливо тоже быстро заканчивается и тратится не совсем на то что вы бы хотели. В общем, если хочется больше успевать на новой работе, то на время стоит ограничить всё остальное. Даже банальное решение о том, что кушать сегодня можно делегировать либо жене/мужу, либо закупиться на неделю готовой едой типа GrowFood (не реклама).

▫️Снизил фоновую нагрузку

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

▫️Потребляю тактами

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

Здесь мне помогает техника «Помодоро» или просто работа тактами: 25–30 минут концентрации — пауза. Это позволяет усваивать информацию лучше, не перегружаться и восстанавливаться между «заходами». Хотя, признаюсь, что в другое время помодоро я не пользуюсь.

▫️База

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


Такие вот наблюдения. И хотя это нормально — не успевать «всё сразу», когда ты проходишь адаптацию, но можно себе помочь. А вы замечали, как тратите и/или экономите своё мыслетопливо? Что помогает вам оставаться в ресурсе, особенно в периоды неопределённости и новых вызовов? Делитесь в комментариях — обсудим.

© Макс Дорофеев и его видео
Please open Telegram to view this post
VIEW IN TELEGRAM
17👍12💯9
Найм сломан?

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

А я вот не согласен, Серёж. Я считаю что найм сломан.

Найм сломан в той части, где работодатели либо не используют ATS (Applicant Tracking System, в России самые популярные это Хантфлоу и Поток), либо, даже если ATS имеется, выстроили процесс так, что она работает исключительно как записная книжка с функцией «поделиться». Как итог одного и того же кандидата на одну позицию но в разные команды собеседуют как бы с нуля каждый раз. Вершинку этого айсберга рассказывал мне ты, когда тебя приглашали на собеседование с человеком, который тебя уже собеседовал несколько дней назад, но не помнил этого.

Найм сломан в той части, где артефактом собеседования в лучшем случае (могу точно сказать за Яндекс, сам лично прикладывал руку к этому) будет код + комментарии к коду. Это сейчас лучший случай на рынке. Потому что худший — это строчка «встретились, нам не подходит». Целью любого собеседования является не только вердикт, а набор артефактов о человеке и его навыках. Но работодатели их не имеют. То есть завтрашний рекрутер, поднявший моё резюме из базы, начнёт диалог с нуля.

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

Найм не сломан как процесс, найм сломан как система.

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

Я надеюсь что ты, Серёж, сможешь починить это хотя бы в вашей ATS 😉

© Фото из тг канала «Рекрутинг и жизнь»
17💯10🤔6🔥2😁2🤯1🕊1
Как починить найм (ну хотя бы частично)?

Продолжаем вчерашнюю тему, предлагаю обсудить, что же можно сделать уже сейчас.

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

▫️. Прозрачность взаимодействия с кандидатом
То есть вся коммуникация должна идти через ATS.

Все взаимодействия с кандидатом — от переписки и планирования собеседований до офферов и отказов — должны фиксироваться в ATS.

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

Так вы всегда будете видеть кто, где, когда и о чём общался с кандидатом и лишите вашу компанию ситуаций вида «рекрутеры компании Звездочка постоянно написывают, устал уже им отказывать».


▫️. Максимизация сигналов о кандидате.

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

Одно дело, когда кандидат пишет в резюме «Strong ML skills», другое — когда ведущий ML-разработчик компании подтверждает «уверенное владение ML» по итогам интервью. В идеале это должна быть размеченная база.

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

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


▫️. Создание вакансии — это не конкурс промптов для GPT

Типичный пример описания вакансии выглядит так:
Чем предстоит заниматься:

— Анализировать большие объемы данных, выявлять закономерности и генерировать инсайты для бизнеса.

Разрабатывать и внедрять ML-модели: рекомендательные системы, предиктивные алгоритмы, сегментация пользователей.

Проводить A/B-тесты, оценивать эффективность новых решений.

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

Поддерживать и развивать инфраструктуру для работы с данными и моделями.

Этот текст мне сгенерировал GPT и из него ровным счётом ничерта не понятно чем мидл DS Вася отличается от мидл DS Пети.

Так вот, если во втором пункте я писал о том, что цель ATS — собрать максимум сигналов о кандидате, то здесь речь о том, что ATS должна помочь нанимающему менеджеру сформулировать, какие именно сигналы от кандидата действительно нужны. Не по принципу коровы («больше доить и меньше кормить»), а реалистично, исходя из задач. Действительно ли тебе так важно, работал кандидат с RAG или нет, или ты готов подождать, пока он разберётся по ходу дела? Причём ответ здесь должен быть не в формате «nice to have», а именно с пониманием критичности в текущий момент. А если критично — то какой конкретно опыт нужен? Так постепенно и вырисовывается не только профиль кандидата, но и список вопросов для собеседования.

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

Я не стал писать про очевидные вещи вроде маркеров «не писать и не звонить» или «кандидат читерил — в ЧС». Кажется, и так понятно, что в хорошей базе сразу видно, с кем больше не стоит связываться.

Вот три тезиса как починить найм. А какие у вас наблюдения?
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍10🔥8🐳1
Прогрессивный HTML

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

Суммаризация просуммаризировала доклад так:
Олег Мохов, бывший руководитель отдела в Яндексе с 15-летним опытом, представил доклад о прогрессивном HTML на конференции. Основная проблема современного веба - интернет становится медленнее не из-за скорости соединения (медиана 89 мегабит в России), а из-за неоптимизированного кода. Веб-страницы выросли с 500 килобайт в 2010 году до 2,5 мегабайта сегодня. Главная проблема - разрыв между визуальной загрузкой и интерактивностью, когда пользователи видят элементы, но не могут с ними взаимодействовать до загрузки JavaScript. Олег предложил методику прогрессивного HTML - поэтапное использование возможностей браузера, где на каждом этапе загрузки сервис остается функциональным. На конференции запланированы доклады по производительности: Рома в 17:00 про Web Vitals и Андрей завтра про альтернативные подходы разработки.


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

Расскажите как вам, если смотрели? (А может и в зале были?)
👍142
Лидер и племя

Вчера Рунет обсуждал увольнение из Рутьюба — якобы за участие в одном из не самых «белых» сообществ. Волна криков от привычных хайпожоров сменилась более внятными разборами. Один из таких — разбор от Гладкова. Если вы совсем не в теме — начните с поста Глеба Михеева. Дальше разберётесь.

Я тоже выждал. А сегодня хочу посмотреть на ситуацию с позиции лидерства.

Макс Ульянов повёл себя как лидер. Вместо того чтобы отмалчиваться и прятаться за отделом кадров, он сразу обратился к команде. Без купюр. Без пиара. Честно. Так поступают те, кто действительно несёт ответственность.

Да, его пост был резким. Местами — двусмысленным. Не отполированным. Но в этом и сила — он писал для «своих» и по ситуации. По-человечески.

И именно это доверие кто-то из «своих» же предал.

Пост слили в сообщество волков. Так торопились опубликовать, что даже имя человека не замазали (сейчас уже замазали, но поисковики всё помнят). А имя — редкое. Как точно подметили в одном из чатов:
Теперь проще имя сменить.

В итоге — получается подставили свои же. 🤦‍♂️

И тут хорошо раскрывается «вожак волков».

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

Ты лидер? Тогда решай по-лидерски.
Хочешь помочь — помоги сам. Ну или хотя бы дай столько же, сколько соберёт комьюнити.

Или всё-таки уволенный не так уж и важен? А важен хайп?

Тогда может, речь не о помощи? А о снятии вины. Если стыдно — пусть страдают все. Племя поделит ответственность, а вожак останется чист.

————————————

А я ещё вчера весь день думал про цугцванг.

Если уволенный — действительно «волк», как его описывают, — то он не пропадёт. Поработает пару месяцев на одной-двух работах вместо трёх. И быстро окажется в новом проекте. Комьюнити паровозиком подтянет.

А если это место было единственным источником дохода?
Если это — всё, что у него было?

Тогда, может, он и не волк. А просто человек.
Которого съели. Свои же. Ну тогда СДД — как писал Акунин.

© фильм «Статский советник» — студия ТриТэ и киноконцерн Мосфильм
137👍6🤔42❤‍🔥1🔥1🤯1🙏1🐳1💯1
Фокус и расфокус

Читаю книгу «Думай как математик». Там описана одна идея, на которой я теперь ловлю себя постоянно.

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

▫️. Сфокусированное мышление — ты целенаправленно думаешь над задачей. Решение упрямо не приходит, но ты продолжаешь пытаться.

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

Мозгу нужен контраст режимов. Без фокуса — не набивается хранилище задачек для решения. Без паузы — нет разгребания зависшей очереди.

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

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

© Альпина
Please open Telegram to view this post
VIEW IN TELEGRAM
15👍10
Спасибо, Артём Антон!
«Я никогда так не е...» © Гудтаймс

Сегодня я хочу поделиться важным и поблагодарить Антона Назарова. И нет, меня не взломали :)

Начну издалека. В 2015–2016 году мы впервые провели годовой курс по фронтенду в УрФУ. Я помню его очень отчётливо — один из месяцев я жил на Power Nap’ах из-за колоссальной нагрузки.

Этот курс делали больше 10 человек из Яндекса. Это был лучший курс, который мы когда-либо провели. Максимальная конверсия в стажировку: каждого второго студента взяли сразу, ещё несколько человек пришли год спустя.

А потом началась оптимизация. Очные лекции заменили онлайн-записями. Вместо менторинга — автопроверка и тесты. Экзамены — с интернетом и ноутбуками. 10–15 часов в неделю на преподавание, менторинг, проверку домашек — это слишком роскошно, когда у тебя есть ещё и основная работа.

Результат соответствующий: конверсия упала до 15%.

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

Антон Назаров пишет об этом. Он — это служба информационной безопасности (ИБ) в найме. Мало кто любит, когда во время (или даже после) запуска сервиса приходят ИБшники и говорят: «У вас тут дырка, надо срочно закрыть». Но это важно: если не закроешь — её найдет злоумышленник и воспользуется ей.

Мы (нанимающие менеджеры в разных ИТ-компаниях) сами сделали кучу дыр в найме.
— Проверяем не знания, а зубрежку экзаменационных билетов.
— Не учим интервьюеров вести живую беседу.
— Не думаем о профиле кандидата и пишем общие вакансии, получаем 500 резюме, отказываем 490, и жалуемся, что нет сильных.
(Хотя можно было просто честно указать: нужен опыт глубокой оптимизации ServiceWorker — и получить 10 релевантных откликов.)

Да много чего ещё успели поломать

Я не поддерживаю методы, которыми пользуются «волки».
Но благодарен Антону, за то что он публично показывает: найм, каким мы его построили, — имеет дыры.

Спасибо тебе за это, Антон.
И рекомендую всем подписываться на канал ОМ
(Но перед этим перечитайте цитату в изображении к посту)
1🔥16🤯64👍4🤔2💯1💔1