Вредные советы для продактов, ставящих задачи разработке

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

Сабджект: Та фича, про которую я тебе говорил в коридоре
Описание: <отсутствует>
А на самом деле: и как это понимать? Когда ты что кому говорил? "Нет времени объяснять"? А ты уверен, что я тебя правильно услышал и запомнил? А когда я сделаю что-то по-другому, опять я буду виноват?

Сабджект: Новая фича
Описание: <скриншот макета из фигмы>
А на самом деле: А что именно из этого, простите, надо делать? А как оно сейчас выглядит с учетом вариативности экспериментов? Как оно должно работать? Кто это вообще рисовал??

Сабджект: Сделать ручку (endpoint - прим.ред.)
Описание: Нужна ручка, которая принимает id юзера и возвращает жсон со статусом и eta текущего заказа.
А на самом деле: А какую задачу ты решаешь? Можно хоть какой-то контекст и цель? Все же разделение труда придумали не просто так, оставь нам решать, как именно технически решить эту задачу и какой контракт будет у ручки, пожалуйста.

Сабджект: Вырастить GMV на 3%
Описание: Мы отстаем от бюджета 6+6, нужно догнать GMV. Поэтому нужно повысить конверсию с главной в заказ на 2% и средний чек на 6%.
А на самом деле: Спасибо, тут есть какой-то контекст "зачем". Но не хватает "как", а вот это уже, в продуктовом смысле - твоя вотчина.

Сабджект: Писать на трекинге "доставили раньше на Х минут".
Описание: Если заказ завершается раньше промиса, писать об этом на экране трекинга.
А на самом деле: А если раньше на 1 минуту, все равно писать? А если заказ отменился? А считать от прибытия курьера или от передачи заказа? Кто должен продумывать корнер-кейсы, ты или я?

Сабджект: Трансляция на трекинге, чтобы клиент не скучал
Описание: Если курьер опаздывает более, чем на 10 минут, клиент скучает и злится. Чтобы его развлечь, будем показывать на экране трансляцию с фронтальной камеры марсохода Curiosity с задежкой не более 3с - покорение космоса это круто. Срок - до пятницы хард, заказана реклама на ТВ.
А на самом деле: Ммм, а у нас нет sdk для потокового видео, нужно затаскивать. Еще с NASA надо договориться об API. Доступы проковырять. А задержка в 3с немножко невозможна - расстояние до Марса колеблется в диапазоне от 3 до 22 световых минут. Может, стоило обсудить техническую возможность до того, как ставить задачу и прибивать гвоздями сроки?

Сабджект: Пофиксить краш на корзине
Описание: BLOCKER ASAP (проявляется у Ромы!!!)
А на самом деле: По приборам этих крашей было 8. На двух униках. Три - у Ромы, 5 - у нашего qa. Это точно достаточно критичная задача, чтобы отложить ради нее все остальное? Давайте реже следовать методологии RDD (Roma-Driven-Development) и опираться на цифры и риски?

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

Должен ли тимлид писать код?

Я считаю, что да. Хотя частенько слышу иное мнение.

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

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

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

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

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

Как же он успеет и лидить хорошо, и код писать - спросите вы. Если мы говорим о руководителе небольшой (5-7 человек) команды, то руководство ей не должно занимать фулл-тайм. А если занимает - это тоже звоночек. Возможно, лиду приходится с людьми нянчиться, и тогда нужно вложиться в их самостоятельность, укомплектоваться ребятами посильнее, делегировать что-то и высвободить себе время. Если команда большая (10-15 человек), то либо можно кодить поменьше (условно, 10% времени вместо 40), либо попилить команду на две, либо вырастить себе зама.

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

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

Обратная связь

Нет ничего важнее умения работать с обратной связью. Что в случае с сервисом/бизнесом, что с личным фидбеком. Любую обратную связь нужно уметь отработать - вынести из нее уроки, запланировать улучшения, пойти навстречу фидбекодателю. Худшее, что можно сделать - встать в защитную стойку и начать прикрываться оправданиями.

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

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

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

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

Автор колонки уходит в отпуск до сентября, не теряйте.
Но на случай, если вы что-то пропустили, вот дайджест прошлых постов:

Важный дисклеймер (есть в закрепе)

Рабочее, серьезное:
И снова про алгоритмы
Стратегия надежности 1 2 3
Надежность: качество релизов
Про BDUI
Вредные советы для продактов, ставящих задачи разработке
Должен ли тимлид писать код?

Околорабочее, несерьезное:
О дипломированных специалистах
Зирвак как платформа надежности
Доверьте работу профессионалам
Трудности перевода
Командный дух

Про тачки:
Автопуть
Mercedes-Benz Panamera WRX
Trust issues
Обратная связь

В порядке бреда:
О пользе караоке
Бизнес-план
Распределенный бог

Предыдущий дайджест

А если вам нравятся мои тексты, поделитесь ими по-братски с друзьями/коллегами. Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков). Спасибо)

Энциклопедические знания

Раз уж сегодня день знаний, поздравлю вас с ним следующей аллюзией.

Из недавнего разговора с коллегами:
- А от Тунгусского метеорита кто вымер - динозавры или мамонты?
- Можно глянуть в Википедии
- Не, спрошу у чат-гпт

Вот раньше как говорили - "человек с энциклопедическими знаниями". Значит, у него широкий кругозор, много фактов в памяти, человек начитанный и образованный. Логично - читая энциклопедии, можно обогатить свои познания множеством фактов - никогда не знаешь, в какой момент они пригодятся. Я люблю дум-скроллить википедию. Искал одно, а там - ссылка за ссылкой - и вот ты уже упоенно читаешь биографию Черчилля.

А теперь что - "человек с чат-гпт-шными знаниями"? Это значит, вообще без оных? Нет, удобно, конечно - задал конкретный вопрос, получил какой-то ответ (хотя я бы дабл-чекнул). Но это убивает романтику получения знаний. Полученные таким образом сведения менее ценны и быстрее забудутся. Да еще и контекста не будет.

Сила - в знаниях. Читайте энциклопедии.

Архитектурное ревью

Сегодня в нашем официальном канале Yandex for Backend вышел мой пост про архревью.
Как я там и обещал, выкладываю артефакт к одному из пунктов - шаблон-опросник.

Это список из ~30 вопросов, на которые должен ответить автор изменений, чтобы убедиться, что он не забыл подумать про важные аспекты проектирования. Какую задачу решает сервис? Почему нельзя обойтись имеющимися? Альтернативы. Сиквенс-диаграмма взаимодействия. Отказоустойчивость, масштабируемость, точки отказа, фолбеки, план внедрения, хранилище, схема данных, периодики, ожидаемая нагрузка - вот лишь часть аспектов, которые нужно осветить в rfc. Потому что если про что-то из этого не подумать, с большой вероятностью случится "ой".

Если хотите послушать про архревью подробнее, приходите на ArchDays или HighLoad++ этой осенью в Москве - мы там будем про это рассказывать.
На ArchDays мой коллега Рома Юрасов расскажет про выстраивание процессов, историю и развитие архревью в Еде, нашу гильдию архитектуры, технологическую культуру.
На Highload++ я в своем докладе больше сделаю упор на выбор технологий под нагрузку, работу с рисками, автоматизацию процедуры, метрики.
В обоих докладах будет про проблематику, технологическую стратегию, а также - разбор шаблона-опросника.

Надежность: предотвращение инцидентов из-за потенциально известных проблем

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

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

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

Очень важно регулярно проводить разного рода учения. Например, по имитации потери одного из дата-центров. Это поможет в условиях сохранения контроля найти те проблемы, которые нас похоронят в случае реальной потери ДЦ. И речь не только о запасе прочности - само изменение топологии может вызвать "бум" - от автофейловера БД до metastable failure.

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

Зато на гарантии

Один мой друг недавно приобрел себе автомобиль одного из труднопроизносимых китайских брендов. Мотивация простая (и единственно верная) - "нравится". Новый, дилерский, с гарантией! Но вот незадача - за 3 недели владения гарантией пришлось воспользоваться ... 3 раза.

Во-первых, дилер выдал авто с неработающим кондиционером. Была течь фреоновой магистрали. Залили подкрашенный фреон, покатался, течь нашли и устранили. Ура!

Во-вторых, оказалось, что бампер на заводе был собран неправильно. Пересобрали по гарантии - ура!

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

И самый кек. Я, как известный душнила, проинструктировал друга, что нужно проверять во время приемки (15 пунктов контроля), включая толщину лако-красочного покрытия. Известны случаи, когда авто при логистике повреждали, покоцанную деталь красили, и выдавали новый авто со вторичным окрасом. Одолжил ему свой толщиномер. Друг вернулся в замешательстве - вся машина покрашена нормально (120-150 мкм), а одно крыло - под 300! Налицо вторичный окрас. Пошел он с продавцом по парковке смотреть другие экземпляры. И вы не поверите - у всех машин этой модели переднее левое крыло бьется в 300 микрон. Это вообще как? Науке сие пока неизвестно. Китайские нано-технологии, не иначе.

Мораль. Гарантия - хорошо. Повод ей воспользоваться - уже не очень хорошо. Китайский автопром - совсем плохо.

55.973146, 37.414863: Как починить "перебрасывание" геопозиции в iOS без регистрации и смс

Жители крупных городов России в последнее время частенько страдают от "перебрасывания" геопозиции в различных приложениях. Например, в Шереметьево. Это сильно мешает - навигатор бессилен, погоду ты видишь в Химках, даже еду заказать сложнее.

Сегодня я вам на примере iOS расскажу, как сделать так, чтобы ваша геопозиция отображалась абсолютно корректно. Для этого даже не потребуется jailbreak и сторонние приложения.

Достаточно лишь
.
.
.
поехать в Шереметьево. (фьюить-ха!)

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

Надежность: реагирование

Продолжаем разбор стратегии надежности .
Ранее уже писал про
повышение надежности релизов и про
предотвращение инцидентов из-за потенциально известных проблем.

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

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

А не надо так. Привычное игнорирование некритичных алертов приводит к слепоте - вы не отличите крит от не-крита. Уже горящий алерт ярче не загорится, если системе станет реально хуже. Замьюченный - тем более. Вы летите без приборов и узнаете об инциденте из газет. Поэтому нужно держать высокий alerts uptime (доля времени, когда не горит ни один алерт, должна приближаться к желаемому аптайму системы в целом - 99.??). А еще полезно визуализировать это в виде полотна с плитками, где каждый не-зеленый кусочек должен вас искренне триггерить. Некритичные алерты нужно перенаправить куда-то в отдельный диагностический канал, а реально критичные - настроить так, чтобы их невозможно было не заметить.

Аналогия из автомобильного мира - лампочка check-engine (она же джеки-чан, она же мясорубка). Не понимаю людей, которые ездят с ней годами. Даже если зажглась она из-за ерунды, вы пропустите индикацию реально важной поломки. А заклеивают чек только перекупы. Я же на некоторых авто каждое утро начинал с подключения обд-сканера (elm) и сброса некритичных ошибок.

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

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

Здоровья вашим сервисам, а если что-то все же бомбанет - не проморгайте. И не слепните.

Игра с ненулевой суммой

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

Простой пример: вам предлагают подбросить монетку. Орел - вам дают 2000 рублей. Решка - у вас забирают 1000. Вроде бы, статистически, надо играть. Но перспектива расстаться с тысячей рублей как-то не радует, и вы, скорее всего, откажетесь. Дело в неприятии потерь - мы склонны интуитивно увеличивать вес потерь относительно выгоды.

Однако, если предложить вам 20 раз подряд сыграть в эту игру, вы наверняка согласитесь. Потому что вероятность остаться в минусе сокращается до морально-приемлемых ~13%, что перекрывается средним ожидаемым выигрышем в 10 000 рублей. Хотя броски монетки независимы, и каждая итерация игры осталась та же. Но вы расширили рамки и оперируете рисками в более широких рамках.

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

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

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

Не нужно обдумывать каждое решение как единственное - расширяйте рамки и оперируйте портфелем в целом и на дистанции.

(Не является инвестиционной рекомендацией. Автор не поощряет азартные игры. Мотивационный питч, направленный на построение аналогий с принятием профессиональных или бытовых решений. Инспирировано книгой Даниэля Канемана.)

Буткемп, или как не толкаться локтями при найме

Предположим, есть 5 смежных команд. И в каждой есть вакансия C++-разработчика (или ios/android/web/qa - не суть, лишь бы одинаковые). Команды в целом схожи, просто за разные части системы отвечают. А значит, требования к кандидатам у них тоже плюс-минус одинаковые - стек, опыт, профиль.

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

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

Найм ведет какой-то один НМ (достаточно опытный и взрослый) при содействии лидеров соответствующих компетенций (о том, что это за зверь - расскажу отдельно). Мы предлагаем кандидату просто прийти в Еду, и за первые пару месяцев поработать по паре недель в нескольких командах (3-4, команды в графике ротируются для равномерности получения буткемперов). За это время новичок точно сможет понять, в какой команде ему больше понравилось. А команды смогут понять, где у кандидата лучше пошел процесс. Где больше фит.

В итоге, смотрим, какие команды "зашли" буткемперу. В каких командах "зашел" буткемпер. Пересекаем множества - там он и останется. Иногда для этого даже не обязательно проходить все 4 команды - по согласованию можно остановить перебор раньше (но хотя бы 2 команды точно нужно пройти).

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

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

Можете сделать так же у себя. А можете попробовать у нас - https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)

Лидеры компетенций

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

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

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

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

Что же именно делают лидеры компетенций?
- работают с подопечными 1 на 1 и помогают им расти и развиваться профессионально
- участвуют в найме и оценке сотрудников на перформанс-ревью
- ставят и ведут техноцели, распределяют их на подопечных, развивают архитектуру, внедряют новое
- реализуют принципы technical excellence в своей зоне ответственности
- обеспечивают обмен знаниями по платформе и продукту
и многое другое.

Для пущей структурности и организованности есть также некоторая иерархия - существуют шеф-лиды компетенций (chief competence lead, CSL), по одному на каждую функцию. Они консолидируют экспертизу и ведут комплексные, сквозные проекты. Координируют лидеров компетенций разных частей компании. Формируют повестку и направляют стратегию технологического развития своей функции. В общем, главные по своим областям.

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

big tech night

Кстати, сегодня конфа big tech night. Программа довольно интересная.

Там и онлайн будет https://bigtechnight.ru/online/ - если не попали на оффлайн. Если еще не решили, чем занять вечер пятницы - вариант.

Кто будет в Красной Розе - при желании можем увидеться, я буду там нетворкаться где-то в районе стенда Городских Сервисов Яндекса.

Надежность: импакт

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

В предыдущих сериях:
- повышение надежности релизов
- предотвращение инцидентов из-за потенциально известных проблем
- реагирование

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

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

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

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

Ну и, наконец, упомяну всевозможные "тыквы" - режимы продуктовой или технической деградации, которые активируются в случае проблем, и позволяют сохранить хотя бы какую-то работоспособность (или даже видимость работоспособности) сервиса. Грубо говоря, если в выдаче Еды будут не все сотни/тысячи ресторанов, которые штатно могут привезти вам покушать, а хотя бы 50 более-менее высоко-ранжируемых, почти никто ничего не заметит. А половина аудитории останется сыта и довольна, если хотя бы показать мак и тануки. Какие именно режимы деградации реализовать, зависит исключительно от вашей фантазии (и одобрения от продукта и бизнеса). Но чаще всего лучше работать как-то, чем никак.

Вывод - купируйтесь и деградируйте. Хотя странно звучит, забейте.

Найм зумеров в эпоху вайб-кодинга

Разгоняли тут с Женей Кадомец про трудности найма в наше неспокойное время перегретого рынка, необоснованных зарплатных ожиданий и злоупотребления ИИшкой.
(https://t.me/jeny_ka - подпишитесь! Там про рекрутмент, карьеру, тренды и котиков)
Женя была рекрутером моей команды уже почти 10 лет назад (страшно подумать), а сейчас она руководит рекрутментом в Финтехе Яндекса.

Решили тут с ней посмотреть с разных сторон на один вопрос.
Я - со стороны нанимающего менеджера, Женя - со стороны рекрутмента.
Моя точка зрения, конечно, важнее ;) Ей-то надо лишь найти человека, а мне с ним еще годами работать.

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

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

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

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

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

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

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

Все, что нужно знать о поиске через чатгпт

Подбирали с коллегой вариант для командообразующего выезда на природу.
Он, по привычке, доверился чатгпт. А я не перепроверил.
Дабл-чекайте все за ллмками! А то они бог знает куда вас заведут.