Иногда я перечитываю старые посты, и иногда мне хочется вставить какое-то дополнение. В одном из первых постов я писал про то как нам удаётся работать при распределённой команде — https://t.me/teamleading/9

За прошедшие с того поста четыре года у меня появились некоторые дополнения:
1. Распределённость эффективна в двух случаях: или все на удалёнке, или распределены не сотрудники, а команды. Иначе говоря, ситуации когда вся команда в одном городе, а один человек на удалёнке/в другом офисе — такое скорее не работает.

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

3. На удалёнке плохо организуются стратсессии и мозговые штурмы. Люди отвлекаются по своим делам, то что очно регламентируется как «без ноутбуков», на удалёнке сложно контролировать.

4. На вынужденной удалёнке выгорают даже самые яростные интроверты. Идеальная схема для них — 2 дня в офисе, 3 из дома. Потому что правильная удалёнка — это не «я тут временно с кухни поработаю», а отдельный кабинет в квартире и активная жизнь вне работы, чем могут похвастаться единицы.

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

Расскажите вы об особенностях вашей работы и лайфхаках. Не важно из офиса или на удалёнке.

Продолжаю рефлексировать прошлые сообщения. Сегодня небольшая заметка про рефлексию в письмах, когда-то я писал что не пишу злые письма вечером — https://t.me/teamleading/12. Это правило универсальное и работает, например, в собеседованиях. Если я хочу поставить кандидату NO HIRE, то я стараюсь не делать этого в тот же день. Я пишу полностью лог собеседования, пишу итого, а на утро перечитываю его и если всё ещё согласен с вердиктом, то оставляю.

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

Недавняя история про девушку, которая искала работу, не получала откликов, а потом сделала явно фейковое резюме с кучей баззвордов, разбавленных явным юмором (VoldemortDB кстати существует, но экспертность в React AI, Mia Khalifa и C++ в первых же строках намекают) и сразу же получила кучу откликов — наделала шума. (Если вы не понимаете о чём речь, то вам сюда — https://www.reddit.com/r/recruitinghell/comments/qhg5jo/this_resume_got_me_an_interview/hie66ew/?context=3).

Многие почему-то сделали вывод о деградации в среде HR. Вот мол тупые рекрутеры не разбираются в тех кого нанимают. Удивительный вывод на мой взгляд. Но если вы его разделяете, то вспомните в следующий раз(или подумайте как будете) о том как вы выбираете подрядчика для ремонта. По красивым глазам? По строчкам «умею ремантирават стералки»? Скорее всего это будут подробное описание услуг, рейтинг и отзывы. Тем сложнее рекрутерам, т.к у них нет рейтинга и отзывов. И если jQuery слово знакомое, то вот пример трех CMS: mango, panda и wagtail. Ха, я вас только что обманул, реальная CMS'ка тут только одна.

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

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

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

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

Рекрутмент — не самая высокооплачиваемая профессия. Допустим есть рекрутер, которого можно научить базовым технологиям и который им научится; при каких вводных он должен остаться рекрутером, а не пойти на стажировку (например) фронтендером? Сейчас, увы для рекрутмента, рынок устроен так, что даже стажеры-разработчики получают неплохо. Особенно в Москве, где рынок перегрет донельзя и стажерам без опыта уже готовы платить шестизначные суммы

Платить рекрутеру больше (чем стажеру)? А за что? Бажащий рекрутер в целом справляется со своей задачей и находит 98 хороших резюме, на два плохих. Платить в три раза больше рекрутеру чтобы было 99 из 100? Кажется овчинка не стоит выделки.

Нанимать только сильных и опытных рекрутеров? И тут главное открытие (моё лично, например). Найти хорошего рекрутера сложнее чем нанять сильного разработчика. 🙁

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

Это не значит что это не проблема, конечно проблема, но как её решить пока не понятно.

Этот канал мёртв или жив?

Последний год я регулярно задавался этим вопросом — стоит ли повесить в этом канале плашку «Архив» и разом ответить на вопрос: будет ли продолжение?

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

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

Ну а в конце к вам традиционный вопрос: на какие темы хочется посты? Какие кейсы хотите рассмотреть?

Work-life balance руководителя

Качественное руководство и work-life balance несовместимы. Перефразирую другими словами: если хочешь стать руководителем, забудь про work-life balance. Я часто сталкивался с тем, что многие люди не понимают этого. Давайте посмотрим, почему так происходит.

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

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

И все-таки многие к возрасту зрелой карьеры (условно к 30 годам) учатся этот баланс соблюдать. У кого-то рождаются дети, и они уже не могут посвящать работе 14 часов в день, у кого-то появляются регулярные активности — это их тоже дисциплинирует. А кому-то просто надоедает перерабатывать, и они находят время и силы, чтобы отложить работу на завтра.

Но вот незадача. Когда становишься руководителем, то переработки, к сожалению, не избежны. Здесь я вспоминаю Максима Батырева и его «45 татуировок менеджера». Руководитель остается руководителем всегда: и на работе, и на корпоративе, и в других контекстах. Ты не можешь сбросить свои руководительские бразды, если вы все пошли, допустим, в бар — ты все равно несешь ответственность за всех. Хороший руководитель руководит 24/7.

Приведу еще один понятный пример. Представим, что я директор магазина. И в этом магазине произошел форс-мажор, например его обокрали на внушительную сумму в несколько миллионов рублей. А в это время у меня начинается вторая неделя отпуска. Ну и что, я должен сказать: «Извините, у меня вторая неделя отпуска, вот вернусь и поговорим» ?! Воры не будут выбирать, когда воровать. Если они запланировали своё деяние на 2 часа ночи в мой отпуск, то в 2:30 я, как директор магазина уже буду на ногах и начну предпринимать какие-то действия.

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

Я против *****

Ощущение, что прошло не 4 дня, а как минимум месяц. Время замедлилось, а каждый час хочется открыть соцсети и прочитать там: «Да мы пошутили, всё это сон». И проснуться, но нет, это не сон, это ужасная реальность.

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

Важно сейчас не оставаться в одиночестве. И нам, руководителям, иногда нужно инициировать беседы на «просто поболтать» со своими сотрудниками. Говорить о чём угодно. Кого-то в такси вспомнили по имени, кто-то увидел весеннюю капель и послушал пение птиц, кто-то съездил покатался на досках (сноуборд), кто-то просто приятно посидел с родителями.

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

Берегите себя!

Возвращаемся. Попытка №3

Жизнь не стоит на месте. Она в любом случае продолжается. Руководство и информация всё так же остаются ценным багажом,а опыт, которым можно поделиться, накапливается и его надо сгружать. Я возвращаюсь.

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

Сейчас я читаю «Как пасти котов». Ставьте 🔥️️️️️️ если уже читали. И вот уже на предисловии вылавливаю несколько важных и полезных мыслей для руководителей.
— Мне совершенно не хотелось менять своё отношение к коллегам, но без этого контролировать их поведения я не мог
Тут автор пишет, что став руководителем уже не получится сохранять отношения со смежниками на том же уровне

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

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

И это только предисловие.

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

Кстати, источником вдохновения про то чтобы вернуться писать хотя бы про книги и опыт для меня является блог Саши Поломодова, где он рассказывает о прочитанных книгах. Крайне рекомендую — https://t.me/book_cube

Деградация фронтенда (и только ли его?)

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

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

Фигма потрясающий инструмент, сэкономивший нам кучу времени. Особенно приятно с ней работать тем кто ещё помнит вымеривание расстояний в фотошопе. Но взамен мы получили фронтенд, где UI и композиция — это копипаст стилей из фигмы. Т.е мы получили верстальщиков, которые не умеют в пиксель-перфект.

Это пример и я буду рад если вы поделитесь ещё примерами, в том числе и не из фронтенда. А для фронтендеров (и их лидов) у меня есть замечательная и недавно переизданная книга, как хотя бы вернуться в русло «думать над интерфейсами», а не просто делать задачи — https://www.ozon.ru/product/razrabotka-interfeysov-patterny-proektirovaniya-3-e-izd-tidvell-dzhenifer-bryuer-charli-692909865

Крайне рекомендую её прочитать всем.

p.s. Ну и конечно же ещё напомню прекрасный сайт — https://cantunsee.space/

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

Кто такой Константин Константинопольский?

Да, забавно получилось. Писал про UX, а получилось как будто бы про Pixel Perfect.

Речь про фигму была примером. Другой пример, которой сейчас я вообще редко вижу — это проверка контейнеров на вместимость. Раньше мы везде в качестве имени пользователя ставили Константина Константинопольского и таким образом проверяли что даже самое длинное ФИ поместится в контейнер. Сейчас же частенько вижу Иванов Ивановых, ну а в лучшем случае Римских-Корсаковых, конечно же Иванов 🙂

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

Ну ок, давайте приведу пример не из фронтенда. Допустим мы проектируем таблицу в БД для хранения пользовательской информации. Бэкендер берёт и для поля телефон задаёт тип CHAR(10). А потом (внезапно) оказывается, что пользоваться этим можно только там где телефоны имеют длину 10, а если (вдруг) найдется страна где это не так, то ничего не выйдет. Но что ещё веселее, верстальщик скорее всего тоже поставит input’у параметр size=10. Главное что всё по ТЗ.

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

И вот что с этой проблемой можно сделать?

Отличия между культурами

На ютьюбе в канале Дмитрия Грица вышло интервью ex-руководителя Яндекс.Технологий Андрея Стыскина.

В настоящее время Андрей работает руководителем в Амазоне и живет в ЛА. В интервью Андрей рассказывает про отличия культур и подходов к работе и менеджменту в зарубежной компании. Мне было интересно, рекомендую.

https://youtu.be/TptFWr6V8Rg?si=asciCEmurbKl0Ce7

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

Как срывать сроки

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

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

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

Если вы сорвали настоящий дедлайн, надо сначала сказать: «Мы договаривались, что сегодня я покажу то-то и то-то в таком-то объёме, в том числе... (перечислить всё, что вы обещали). К сожалению, я сделал не всё: не успел сделать то-то и то-то». Все извинения, уточнения и, главное, предложения должны звучать уже после этого. Доверие начинается с того, что клиент хотя бы видит, что вы понимаете, что создали проблему.

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

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

Каким бы ни было ваше предложение, нужно убедиться, что клиенту оно подходит. «К завтрашнему дню уже точно будет» — это предложение, но оно звучит, как будто вы сами назначили себе новый дедлайн, не спросив мнение клиента. Мало кому такое понравится. Более нормальный вариант: «Чтобы доделать оставшееся, я бы хотел договориться взять ещё два дня». Тут клиент может либо согласиться, либо возразить, и тогда вы сможете думать дальше.

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

Читая книгу «Карьера Software Engineering Manager», набрёл на интересную мысль.

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

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

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

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

Тонкость додумывания мысли автора в том, чтобы эти 4-х часовые блоки на «поработать» сделать ежедневными и едиными на команду. Как думаете, сработает? А ещё интересно как вы решаете эту проблему в своих командах?

36

В 2014 году мы во второй раз делали конференцию FrontTalks. Конференция у нас была тогда почти никому не известная, докладчиков было не густо и нужно было придумать что-то. И как-то в разговоре с Вадимом Макишвили мы начали обсуждать идею что было бы круто в конце сделать доклад про жизнь. Как-то так появился знаменитый доклад Вадима «36», а идея завершающим докладом делать доклад про жизнь стала фишкой конференции.

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

Но это же канал о руководстве и работе? Причем тут фишки? Так вот я считаю что наличие фишек важно и в работе, и вообще в том что ты делаешь. Не важно что это будет: стендапы по четвергам в рубашках, единороги на аватарках или вишенки когда приходит новый человек. Вот эти мелкие традиции они делают команду сплочённее, сильнее и командой. Про силу традиций писал Эд Кэтмэлл в книге про Pixar. И мы все понимаем какой Pixar был тогда.

А если у вас будет время на выходных, то вот все завершающие доклады с FrontTalks:
2014: Вадим Макишвили «36» — https://www.youtube.com/watch?v=FxljIvLxUqQ
2016: Гриша “бобук” Бакунов «Можно ли программировать без интернета» — https://www.youtube.com/watch?v=z3DVIXKieBA
2017: Андрей Себрант «Мозги надо переключать» — https://youtu.be/aVdF_em3usw
2018: Артём Горбунов «10 принципов Артёма Горбунова» — https://youtu.be/ZMeWeU1Y6PI

p.s. Кстати, почему я написал этот пост именно сегодня? Просто мне стукнуло 36. Когда я 10 лет назад восхищенно слушал Вадима, я думал что время о котором он рассказывает ещё так далеко…

Привет, простите что в выходные.

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

Расскажите какие фишки есть в ваших командах?

Метод 5П для встреч 1х1

Книга «Карьера Software Engineering Manager», оказалась кладезью простых мудростей на каждый день, поэтому продолжу ими делиться.

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

В книге предлагается простой фреймворк 4П, помогающий провести диалог 1х1 и не забыть что-то важное:
1. Прогресс
2. Проблемы
3. Планы
4. Персонал (в оригинале People, т.е люди)

Вот 4 столпа на которых автор предлагает строить встречи 1х1, сам же себе противореча, ведь тут снова только про работу.

Я предлагаю добавить к этому списку 5-ю П — персональное. Т.е после всего рабочего, можно пообсуждать не рабочее, там и про погоду, и общее самочувствие, и про жизнь в целом.

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