Чёрные полосы — белые полосы

Жизнь — такая штука: иногда ты прыгаешь выше головы. Иногда — даже несколько раз подряд. А потом вдруг останавливаешься и думаешь, может твоё место где-то пониже...

Не будет долгих прелюдий — всё просто: я ищу работу.

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

Что я умею:

— работать руками. Я не забыл фронтенд, хотя свежие фреймворки придётся немного подтянуть.
— руководить технической командой: нанимать, онбордить, ставить цели, достигать их.
— вести проекты как проджект: следить за delivery, трекать задачи, наводить порядок в процессах.
— управлять продуктом, особенно если понимаю его суть. А если не понимаю то сам кастдеваю, ux-ю, достаю аналитику, и потом строю гипотезы. Последние 5 лет я делал продукты в HR, в основном про найм.


Могу делать всё сразу, могу что-то одно. Я легко адаптируюсь и бросаюсь туда где болит.

Я открыт к разным вариантам. И к понижению — тоже. Просто хочу делать дело.

3 месяца CPO

Глупо не написать о том, что случилось. В пятницу, когда я ехал из аэропорта на CodeFest, то познакомился с Русланом и, узнав чем он занимается, вдоволь позадавал вопросов почему мне трудно входить в новую компанию.

Руслан ещё тогда сказал, что это стык разных культур, продуктовой и операционной. Он часто приводит вторую к первой, часто видит дикое сопротивление организаций и очень часто это приводит к большим переменам и уходам. Сказал не сдаваться и do my best.

Итак, я пришёл в HR продукты без команды разработки, без структуры, с максимумом неопределённости. На старте мне дали двух продактов, и очень поверхностные цели, в итоге можно было считать что это — высокая автономия, ожидание рывка и понятный вектор: «Сделать».

Что я сделал:
🔹 Запустил процесс работы над MVP приложения для сотрудников — с идеи до первого релиза (но ещё не MVP)
🔹 Придумал концепцию продукта, презентовать не успел
🔹 Нанял команду разработчиков этого продукта, начал выстраивать процессы
🔹 Ввёл OKR-планирование и ежемесячные статусы на топов
🔹 Проинициировал оргдизайн: роли, зоны ответственности, кластеры
🔹 Фасилитировал синки, ретро, отчёты, продуктовые обсуждения
🔹 Сам писал тикеты, документы, помогал другим менеджерам готовиться к планёркам

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

🛑 В итоге мы с компанией разошлись в ожиданиях от роли CPO. Потому что и де-юре (должность моя называлась ИТ БП), и де-факто компания хотела не того, что обычно делают продакты.

Мой подход — про автономию, быстрый трек, product-first. Ожидания оказались ближе к структуре, отчётности и системному управлению.

Это нормально — иногда вы просто не совпадаете.

Матрица RACI — кто за что отвечает?

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

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

Такие конфликты редко случаются «в вакууме». Обычно это не про конкретный проект, а про размытые зоны ответственности.

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

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

Кто у нас отвечает за согласование с дизайнерами?
А кто идёт разговаривать с маркетингом?
А кто может финально сказать «да»?

И вот тут помогает матрица RACI.
— Responsible — кто делает
— Accountable — кто несёт ответственность и принимает решение,
— Consulted — с кем надо посоветоваться,
— Informed — кого надо держать в курсе.

Особенно важна буква A. Accountable всегда один.

Матрица не обязана быть в табличке. Она может жить просто в договорённости: «если что — по дизайну решает Аня, по маркетингу — Лёша». Всё. Уже легче жить.

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

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

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

Повторю самое важное на мой взгляд. Можно скипнуть буквы RCI, но обязательно нужно договориться кто A, и что он один (на самом деле остальные в этот момент становятся C или I).

И ещё: такие договорённости не вечные. Люди уходят, меняются, вырастают. Поэтому RACI — это не документ. Это привычка раз в какое-то время уточнять роли.

PARIS, RASIQ, RAPID и куча других матриц

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

Но у меня созрел вопрос к вам, а вы когда-нибудь в работе пользовались чем-то отличным от RACI? Если да, то расскажите чем, плиз.

Ресурсы и инструменты для развития тимлида: приоритеты, баланс, «помощь зала» / Наталья Борисенко

Это доклад-рефлексия на тему того как тимлиду развиваться и прокачивать себя.

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

Далее приводятся 5 инструментов роста руководителя:
— конференции
— люди (эксперты/менторы/менти)
— книги, исследования, статьи
— курсы
— подкасты.

В целом на этом можно сказать всё тема доклада раскрыта 😃, но далее идёт рефлексия на тему как и с чем лучше работать.

Ограниченные ресурсы — это реальность, поэтому любые каналы, курсы и книги стоит фильтровать. Наташа предлагает формулу:
много источников + строгий фильтр = качественные знания.

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

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

В докладе также упоминается модель Gain – Grind – Grow:
— Gain — выделение времени на получение знаний
— Grind — практика и применение
— Grow — превращаем навыки в достижения целей (подробнее например здесь)

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

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

Все обзоры по тегу #докладобзор@teamleading

Глобальный Undo

Один из самых странно решённых и невероятно долгоживущих сценариев на мобильных устройствах — это Undo, а точнее его отсутствие.

На десктопах всё давно просто и понятно: Ctrl+Z работает почти везде. А на мобилках? Когда только появился iPhone, Стив Джобс придумал, что для отмены действия можно… потрясти телефон. Да-да. Потрясти. Телефон. В ответ появится модалка: «Отменить ввод текста?». Но, как можно догадаться, это (потрясти + подтвердить) не прижилось. В смысле оно работает, но проще переписать. Да и работает только в текстовых полях. На этом всё и закончилось.

На первый взгляд, вроде и проблемы-то нет. Даже исследования говорят, что пользователи редко вспоминают про Undo на мобильных интерфейсах (например, вот статья из ACM Digital Library). Но только до тех пор, пока сам не промажешь пальцем — и не потеряешь точку невозврата.

Продакты, внимание! Дарю вам фичу.

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

Добавить Undo — это может быть пара строчек. А пользователь сэкономит время, и (что намного важнее) нервы.

Один из главных признаков, когда вам стоит предусмотреть путь назад: если у вас в интерфейсе есть действие, после которого пользователь может сказать «ой».

FrontendConf — мы почти готовы. А вы?

В прошлом году я вошел в программный комитет FrontendConf, и когда в ноябре я пришёл на первый созвон ПК, то подумал: «Зачем так рано? Впереди же почти год». А потом кааааак понял...

Осенью прошлого года я был на FrontendConf. Это стало возможно благодаря Никите Дубко (на фото и кстати, у него теперь есть канал, где он делится опытом перехода в продакт-менеджмент). Я просто ходил, смотрел, а потом половину вечера рассказывал одному из членов ПК, что бы я сделал иначе. Так я оказался в программном комитете.

С тех пор — больше полугода еженедельных созвонов. Интервью с претендентами, обсуждения внутри ПК, просмотры чужих интервью. Споры, обсуждения, критика, Глеб Михеев 😃. И вот вчера мы зафиналили спикеров.

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

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

От себя внесу небольшую лепту для моих читателей, вот вам промик на небольшую скидку в 5% — fc25_teamleading.

И надеюсь увидеться на FrontendConf 2025.

К сожалению, сейчас мы не готовы пригласить вас на следующий этап.

Это фраза, которая будто создана, чтобы раздражать.

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

Во-первых, давайте уже перестанем говорить:

«С твоим опытом ты легко найдёшь работу!»

Нет, не легко. Это миф.

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

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

Но вот по данным Time / LinkedIn Economic Graph, в 2023 году медиана закрытия вакансий была 44 дня. Не ну это было давно и не у нас, а у нас что? А в России показатели закрытия вакансий тоже растут. А значит мы снова вернулись к тому, что найм — это рынок работодателя.

Сеньорам, руководителям, C-level’ам объективно сложнее искать работу. Таких позиций меньше, ожидания размытые, критерии успеха меняются от компании к компании. Да и чаще тебя ищут, чем ты находишь.

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

«Спасибо за интерес, но мы пока не готовы двигаться дальше…»

И в ХХ эта аналитика на виду: просмотр в 16:10 — отказ в 16:10. Отказали быстрее минуты, получается

Я не прошу развёрнутый фидбек на полстраницы. Хочется просто одного предложения:
– Где не совпали?
– Что показалось слабым?
– Почему решили не звать?

Чтобы не совсем уехать кукухой я спрашиваю у ChatGPT — что не так? Он не уходит в глухую оборону, не прячется за HR-бренд и может помочь понять, где можно подкрутить. Почему компании не могут сделать так же? Где пресловутая AI-трансформация рекрутмента?

Но, честно, хочется, чтобы и компании чуть взрослее относились к процессу.

«Вы нам подходите, но нам кажется, что вы немного overqualified? Вам ок такое?» Или «Сейчас мы общаемся с другими кандидатами, но если вакансия не закроется в ближайшие пару недель, мы вернёмся к вам. Если вы готовы подождать — дайте знать».

Это уважительно.

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

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

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

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

Серёжа умеет раскладывать сложное на простое и писать внятно. Поэтому рекомендую не только борду, но и его Telegram-канал — он пишет полезно и без лишнего шума.

https://t.me/seryozha_typing/365

И ещё давайте посмотрим на найм с другой стороны.

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

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

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

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

Кстати, уже завтра будет Saint TeamLead Conf и я там тоже буду. Подходите знакомиться и обниматься 😊

Идеология одиночек

Макс Ульянов написал пару постов про «волков» — первый, второй. Глеб Михеев подхватил. Не могу не откликнуться и не высказать своё имхо — но сначала лучше прочитать их.

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

Я это видел давно. В универе у нас был курс по сетям Cisco — обязательный и скучный. Преподавание слабое, интереса ноль, но каждую неделю — тест. И всё свелось к гонке шпаргалок. Интернет? Отрубили. Флешки? Запретили. CD-диски, дискеты? Поставили мониторинг экранов. Я дошёл до того, что печатал шифрованные шпоры на бумажках размером с ладонь. Иногда это работало, иногда нет — но в итоге ничему полезному меня этот курс не научил. Потому что никто не объяснил, зачем всё это, и не создал условий для настоящего понимания.

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

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

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

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

И вот тут возвращаемся к «волкам». Если бы они только сливали собесы и выкладывали разборы — это было бы похоже на форму протеста. Не идеальную, но понятную.

Идеология волков звучит так: «Работать нужно только за деньги, а не за спасибо». Это не позиция профессионала — это логика читера. Того, кто делает только то, за что платят прямо сейчас. Как таксист, который ради 50 рублей проезжает на красный. На короткой дистанции это может сработать. Но ни одна команда, ни один продукт на этом далеко не уедет.

Нет ничего страшного, если вы воспользовались IDDQD, чтобы посмотреть как надо было и что же там дальше. Плохо, когда вы живете исключительно на IDDQD. Именно поэтому идеология волков — не про справедливость, а про халяву. Не про улучшение системы, а про то как её обходить. Это читерство и оно всегда вскрывается. Иногда — через месяц. Иногда — через 35 лет. Но вскроется обязательно.

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

Привет, меня зовут Олег.

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

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

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

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

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

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

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

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

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

А ещё я делаю обзоры на книги и доклады. Их можно найти по тегам — #книгобзор@teamleading и #докладобзор@teamleading.

Полезняхи про встречи и оплату за рубежом

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

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

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

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

Олег:
• Пересмотреть доклад «Когнитивные ловушки Тимлида, инструкция по выживанию» от 27 июня.

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

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

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

Оба сервиса проверены — можно пользоваться.

Сколько часов в неделю нужно работать?

Эту неделю я хочу посвятить книге «Идеальный программист» Роберта Мартина. Что я сам понимаю в разработке — у меня всего-то 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 часов работодателю». Возникает вопрос: «А что если я делаю работу быстрее?» В такие моменты я искренне восхищаюсь и при этом удивляюсь: если есть время — почему бы не сделать ещё лучше? Попробовать порефакторить, применить новые знания, поэкспериментировать. Мы ведь часто жалуемся, что у нас «нет времени на улучшения». А тут оно есть — и сам бог велел им воспользоваться.

Учиться — значит быть самоучкой?

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

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

Мы часто воспринимаем развитие как нечто индивидуальное. «Хочу вырасти — пойду на курс». «Надо подтянуть алгоритмы — буду ботать литкод». «Хочу стать 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 — Карьера с тобой случается
Лет 5 назад такое точно было, но в последние годы я уже чуть лучше понимаю куда хочу и что нужно делать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все мои обзоры докладов по тегу #докладобзор@teamleading.

Три истории читерства

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

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

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


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

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


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

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


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

Возвращаясь к истории в начале: а вы бы как поступили? Ну и рассказывайте ваши истории, если такие есть.