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

Сегодня в нашем официальном канале 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-м. Кто любит технологии и готов много учиться. Кому интересно развивать инструменты, а не просто использовать их.

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

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

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

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

Больше пикселей!

Обновился тут до ios26. Весь этот стеклянный дизайн, конечно, полная шляпа. Зато картинка стала намного более четкая, резкая, красочная! Как будто пикселей прибавилось. Аж глаза режет. Тексты стали контрастнее, графика четче. Как они этого добились чисто программно?

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

Why so serious?

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

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

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

Кстати, на встречах 1 на 1, по моему мнению, тоже очень важно не замыкаться на задачах и проблемах, а еще и говорить за жизнь. Мне правда важно знать, что у моих ребят на душе, в голове, в жизни происходит. Через это надо и психоэмоциональное состояние снять, скорректировав под него рабочие вопросики, и хорошие дружеские отношения выстраивать. У меня не выходит относиться к людям как к рабочим единицам, я каждого считаю другом, и мне не все равно. Я лучше не успею обсудить что-то рабочее - оно никуда не убежит - но смогу выслушать человека и тоже с ним чем-то поделиться, вместе поворчать на что-то.

Цените своих коллег, дорожите отношениями, общайтесь свободно. Тогда и работа будет легче работаться.

Новый виток истории

Пару лет назад, когда к нам на рынок повалили всякие зикролисяны, все трубили - воооот, сейчас китайские электрички завоюют рынок, порше больше не нужны. Целевая аудитория немецкого спортивного премиума начала с характерным прищуром засматриваться на такие же прищуренные машины. Я и сам панамеру брал из-под человека, пересевшего с нее на зикр (sic!).

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

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

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

Новая глава

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

В связи с этим был приобретен учебно-тренировочный кадавр в лице BMW 3er E30 1984 года выпуска на трамблерном M20B20 с ле-джетроником. Теперь мы можем по выходным на паркинге с ним ковыряться. Цель - сделать к лету конфетку. Хотя, цель тут - не главное, главное - процесс. Буду рассказывать сыну, как оно устроено, на практике. Будем учиться крутить гайки, чинить, улучшать, разбирать и собирать.

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

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

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

#лёха_строит_бэху

Пирамида потребностей вашего сервиса

Несколько дней назад на одной из встреч коллега Андрей говорил о стратегии своего направления. Одна мысль мне так зашла, что не могу ей не поделиться. В целом, идея не нова, но для кого-то может стать eye-opening.

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

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

Следующий слой - стабильность и масштабируемость. Если система частенько рушится, или вы не знаете как вывезти рост х2 - руки прочь от всяких свистелок и бантиков! Иначе у вас будет стабильно не работающая по пятницам свистелка с бантиком, которая показывает время лишь через раз, и то неправильное.

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

И лишь когда у вас уже все хорошо, можно переходить к более развесистому ML/AI (в том числе в процессах) - в наших часах это будет голосовой аи-помощник и фитнес-трекинг.

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

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