Про заметки.

Где вы храните заметки?

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

Потом я познакомился с Notion, и это, конечно, был своего рода прорыв. Записная книжка контактов, вопросы для собеседований, личный и семейный бюджет, документы больничных анализов — всё-всё можно было круто организовать в Notion. Знаю, что многие компании его используют как аналог Jira/Confluence, тк его функциональность действительно может их заменить. Но, к сожалению, лично меня Notion заблокировал, когда началась история с санкциями и Cancel Culture.

Если интересно погрузиться в этот дивный мир, то вот сравнения сервисов между собой.
- Универсальность против конкретики. Какой сервис заметок и баз знаний подойдет именно вам?
- ТОП-15 лучших приложений для заметок
- Лучшие приложения для заметок на 2024 год

А что сейчас? Сейчас я многие заметки веду в ТГ в Saved Messages (оно же избранное). Не знаю, почему так получилось, как-то само собой все заметки перетекли туда, особенно это стало актуально, когда ТГ сделал теги у сообщений и поиск по ним в Saved Messages.

Многие рекомендовали попробовать Obsidian, типа он как Notion, но лучше. Да? Стоит?

Детская задачка ...

у дочки в 4-м классе в аттестационной работе по итогам года.

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

Я не решил, chatgpt и deepseek выдают разные и достаточно противоречивые друг от друга результаты.

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

Про разные треугольники.

В 2014 году, когда был бум крафтового пива в Москве, существовал так называемый московский крафтовый треугольник 🍻. Это был барный маршрут между тремя барами, которые тогда были амбасадорами крафтовой культуры в Москве. Бары еще существуют, поэтому маршрут все еще актуален.

Сейчас, спустя 11 лет, на Аравийском полуострове тоже есть свой треугольник, только в сфере красоты 💅🏻! Мы (ЗЯ) официально открыли свои офлайн-магазины в трех самых крупных странах полуострова: Катар, Эмираты, Саудовская Аравия. Вы можете придти своими ножками в любой из магазинов в Доха/Джидда/Дубай или сделать онлайн заказ через МП и сайты goldapple в этих странах.

Осень-зима-весна 24/25 были не самыми простыми для нашей команды, спасибо всем, кто принимал непосредственное участие, вы все молодцы 🤝🚀🔥

Про цвета в календаре.

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

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

Вырезка из моего протокола

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

Рекомендую покрасить свой календарь, потом пройти тест и сравнить то, что получится. Интересно в рамках саморефлексии и самоанализа.

Про кодогенерацию

Я очень люблю кодогенерацию. Первый раз я с ней столкнулся где-то в 2020 году, когда, еще будучи разработчиком, увидел, как из OpenAPI спеки получился полностью готовый к работе HTTP-клиент сервиса на Go. Уже в Магните ОМНИ мне удалось на самом старте заложить в инженерную культуру департамента подход генерации как клиента, так и сервера из OpenAPI и Proto спецификаций для Golang стека, aka spec first подход. Для Python было чуть иначе: там из кода генерировалась спецификация сервера, aka code first подход, но HTTP-клиент сервиса также генерировали из спеки. Вот, кстати, этот инструмент, можете его попробовать для Python стека. Частично обо всем этом я рассказывал в Moscow Python Podcast. Про генерацию кода.

Важно отметить, что генерация кода имеет ценность только в связке с линтерами соответствия кода спеки и спеки кода на уровне соответствующих шагов CI/CD, то есть:
- обновил код руками - красный pipe
- обновил спеку, но не обновил код - красный pipe
- обновил спеку, обновил код, но при этом внес обратно несовместимые изменения в API - красный pipe
- обновил спеку, обновил код, но изменения не соответствую внутренним договоренностям внутри компании типа Snake Case VS Camel Case VS Pascal Case VS Kebab Case - красный pipe
- ...

Но оставался вопрос: кто пишет сами спеки, чтобы потом из них сгенерировать сервер и клиент? При мне в Магните ОМНИ это делали сами бэк-разработчики, тк они проектировали API сервисов, сами договаривались между собой о контрактах и с этим не было проблем. Но, по идее, это могут делать системные аналитики (далее – SA).

Тогда, например, в том же GitLab можно тонко настроить codeowners, чтобы за спеки отвечали SA, а за код – разработчики. Тогда может получиться интересный тандем для совместной работы на уровне MRов. Мы сейчас в ЗЯ стараемся двигаться в этом направлении, надеюсь у нас все получится.

Про демократуру.

Около 5-6 лет назад, когда я решил, что хочу двигаться в сторону CTO, я начал искать литературу, способную приблизить меня к этой цели. Не помню точно, как это произошло, но я нашёл подборку книг - Список книг для тимлидов и CTO. Данный список остается актуальным и по сей день, и я считаю, что многие из упомянутых в нём книг обязательны к прочтению для любого руководителя.

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

Сейчас я читаю (на самом деле слушаю) одну из его следующих книг — Управление изменениями без потрясений и конфликтов. Книга частично повторяет то, что было в "Идеальном руководителе", да и в целом в книгах Адизеса очень много повторений и воды, но это не суть. В данной книге меня зацепил термин "демократура". По Адизесу, демократура — стиль управления, в котором сочетается демократия в принятии решений и диктатура в их осуществлении.

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

О техрадаре

Впервые я столкнулся с термином «техрадар», когда в 2019 году проходил интервью в Lamoda на тимлида. Я хорошо помню тот момент, так как техрадар в Lamoda был распечатан в виде баннера и висел то ли на стене в одной из переговорок, то ли стоял на флипчарте где-то в офисе. Правда, в тот момент я не совсем понял, какую роль он играет и какую ценность несет для компании.

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

К чему я это? У нас в ЗЯ теперь тоже есть свой техрадар!

Про CAPI.

Закончил слушать эту книгу и хочу поделиться одной мыслью. В ней говорится о CAPI. По методологии Адизеса, CAPI (coalesced authority, power and influence) – это объединение полномочий, власти и влияния.

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

Полномочия. Эта функция принадлежит тем, кто имеет право принимать решения и может сказать изменению "да" или "нет". Например, как тимлид, вы принимаете решение о том, как реализовать ту или иную фичу с точки зрения архитектуры, сроков и распределения ресурсов. Вы имеете полномочия сказать: "Да, фича будет сделана так", или "Нет, фича будет сделана не так".

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

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

Если лень читать всю книгу, то вот хорошая выжимка в виде статьи.

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

Почему стоит чаще катить изменения в PROD.

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

Представьте: ваша фича зарождается высоко-высоко в горах, как ручей из талого снега. Океан — это PROD. По пути к океану ручью предстоит преодолеть массу препятствий. Задача — не сразу превращаться в полноводную реку, а сначала проложить безопасный, понятный маршрут до океана, те сначала — найти путь, потом — наращивать поток.

Что это значит на практике? Не стоит пытаться оформить фичу одним гигантским MR на 10k строк и выкатить всё разом, так вы упрётесь в кучу блокеров:
- не настроен CI/CD для нового сервиса,
- нужен отдельный инстанс БД, а задачи ещё нет,
- не согласована сетевая связность с ИБ,
- внезапно нет нужного железа в проде,
- зависимость от релизов других команд,
- и так далее.

Надо наоборот: пропустить в прод первый маленький ручей — минимальный, но самостоятельный MR, который открывает путь. Затем наращивайте поток — серией небольших, частых MR’ов. Так вы:
- выявляете инфраструктурные и процессные проблемы заранее,
- снижаете риски и стоимость отката,
- ускоряете обратную связь от PROD-среды,
- упрощаете код-ревью и стабилизацию.

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

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

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

Стань индусом.

Когда-то на меня сильно произвела впечатление книга «45 татуировок менеджера», и вот я наконец-то добрался до в каком-то виде продолжения — «45 татуировок личности».

Я не буду тут приводить список любимых татуировок или составлять какой-то ТОП, пост не об этом. Пост конкретно об одной татуировке, которая называется «Стань индусом». Короткий пересказ, о чем она, вы можете найти тут.

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

Когда его кто-то или что-то разозлило, он писал куда-то к себе в заметки ответ на данное событие/сообщение его автору, но не отправлял, а давал «отлежаться» час-два или день — в зависимости от потребности в ответе. Спустя это время он возвращался, перечитывал, что он написал, и либо удивлялся тому, как плохо, грубо (неполиткорректно) он написал, и переделывал, либо отправлял, тк все было ок.

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

Вчера посетил конференцию avito.tech.conf for leads & managers.

Мысли в формате тезисов на основе прослушанных докладов и нетворкинга со случайными участниками конфы.
- Все пытаются как-то где-то внедрять AI для автоматизации и ускорения разработки, не у всех получается, не все довольны результатами, но все так или иначе пытаются что-то придумывать и двигаются в этом направлении.
- Многие, с кем я общался, соглашаются с тем, что средний уровень разработчика падает. Моя гипотеза тут — это то, что в IT за последние 10 лет пришло много новых кадров не после профильных вузов, а после курсов. Где — вжух — и через полгода ты уже джун, но базовой базы страданий через пот и кровь какого-либо высшего учебного заведения нет. Плохо это или хорошо — каждый решает для себя сам.
- Тренд работать на двух и более работах, к моему глубокому сожалению, растет. Откуда и почему — лично для меня загадка, но такая проблема есть, и работодатель со стороны ТК тут не защищен.
- Практически у всех компаний, кроме тех, кто занимается каким-либо импортозамещением, проблемы с бюджетами в этом году. Прогноз на 2026 — неутешительный. Иными словами, затягиваем пояса. Эх, видимо, покупку Porsche придется снова отложить =)

Запись трансляции тут.

Про Бурдж-Халифа.

В ЗЯ, кроме заказов и подарочных карт, есть боксы и косметички. Что это такое? Это подборка разного рода товаров, тематически собранных в красивый комплект с определённой тематикой с учётом текущих трендов, времени года, праздников и т. д. и т. п. Анонсы продаж боксов и косметичек публикуются в соответствующих каналах @GoldApple_BOX и @flacon_mag. Подписывайтесь.

К чему я это? Поскольку предложения по данным товарам всегда ограничены и их раскупают в течение 5-ти минут, то это порождает колоссальный рост нагрузки на наши сервисы в момент публикации новости о начале их продаж. Для понимания: RPS на каталог/корзину может подскочить в моменте одной минуты в 2–3 раза, а количество заказов может подскочить до 10 раз.

Причём тут Бурдж-Халифа? Потому что на метрике заказов это выглядит именно так.

Про плагины для Mattermost.

Мы в ЗЯ весной этого года начали переводить наше корп-общение из ТГ в Mattermost среди IT. Это был сложный путь длиною в полгода. Не могу сказать, что всё прошло гладно и что сейчас всё работает идеально, но направление точно было выбрано правильно.

Для Mattermost, кроме банальных плагинов типа gitlab/jira/playbook, есть куча всего. В данном посте хочу поделиться моим ТОПом необычных плагинов. Порядок случайный:
- badges - Значки — они же ачивки, они же лычки. Это способ публично похвалить и/или поблагодарить кого-то за проделанную работу с отображением артефакта в его карточке сотрудника. Добавляет немного геймификации в рабочий процесс.
- jitsi - Интеграция с Jitsi. В идеале — развернуть собственный сервер, тк публичные находятся далеко за океаном. По качеству и функциональности Jitsi уступает Zoom и GMeet, но при этом остаётся одним из лучших и самых открытых решений на рынке.
- wrangler - Переносить треды между каналами, мержить треды в один, форвардить треды из приватных каналов в публичные — это всё об этом. Must Have. Пользуюсь постоянно.
- todo - Быстрые и простые TODO-шки на посты с периодическими напоминаниями, как альтернатива встроенному Remind.
- agents - Возможность использовать как публичных AI-агентов, так и внутренних, развернутых в вашей инфры, внутри Mattermost. Мой основной кейс использования — это когда меня призывают в тред длиной в 100+ сообщений, я прошу агента суммировать всё, что было до этого в обсуждении, короткой выжимкой.

Очень хочется попробовать exchange-calendar плагин, но его установка и конфигурация это какой-то ад.

Про AI.

В четверг был на конференции Yandex: Team Lead Go. В целом это было больше про нетворкинг, но был и один доклад о применении AI в мобильной разработке в Yandex Go. Со слов докладчика, у них уже сейчас используются AI‑агенты, которые парсят макеты в Figma и на их основе генерируют экраны мобильного приложения из коробки. Разработчик все еще нужен, чтобы провести ревью этого кода и самостоятельно добавить анимации. Со стороны это все выглядит невероятно.

Этой осенью на всех конференциях звучали доклады про AI. Автокомплит, рефакторинг, генерация тестов, code review, поиск уязвимостей, обнаружение неоптимального кода вроде n+1 - все это уже воспринимается как норма, а не как фантастика из будущего. При этом утверждается, что это все в помощь разработчику, чтобы быть эффективнее и быстрее перформить. Так ли это? Не знаю. Как будто тут есть доля лукавства. Точно понятно, что страдают джуны, которые сейчас никому не нужны, а senior-инженеры как были, так и остаются востребованы.

Время MVP прошло?

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

У меня нет на руках исследований или статистики, есть сугубо личное субъективное мнение. Рынок и мы сами, как пользователи цифровых продуктов, сильно изменились. Мы стали гораздо более требовательны к:
- визуальному качеству и целостности дизайна
- скорости и стабильности работы
- отсутствию навязчивой рекламы и "шумных" паттернов
- понятным онбордингам и прозрачной монетизации

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

В ЗЯ мы практически никогда не запускаем на клиентов MVP, в основном это всегда MLP, и это сложно. MLP тянет за собой более долгий discovery, а затем еще более долгий delivery-процесс. Хороший пример - новая программа лояльности.

Про интервью управленческого опыта.

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

Общая структура интервью
- Формат: 5 секций, 70 минут суммарно, общая продолжительность интервью 90 минут
- Секции:
1) 🧑🏻👩 Управление людьми и командами - примерно 30 минут
2) 🔄 Управление процессами - примерно 10 минут
3) 🎯 Целеполагание - примерно 10 минут
4) 🔀 Внедрение изменений - примерно 10 минут
5) 🤑 Бизнес-экспертиза - примерно 10 минут

🧑🏻👩 Секция 1: Управление людьми и командами
Цель: понять подход к мотивации, развитию, найму/увольнению и дизайну команды.
Вопросы:
- Как ты работаешь с сотрудниками на регулярной основе? Какие практики используешь для поддержания мотивации?
- Как ты развиваешь людей и команду? Как оцениваешь прогресс и сравниваешь результаты между сотрудниками?
- Как принимаешь решения о найме? Кого и в каких ролях нанимал? Как и в каких случаях принимал решения об увольнении?
- Как проектируешь структуру команды и планируешь её рост/изменения?
Кейс-вопрос:
- Приведи конкретный пример: рост сотрудника, найм или увольнение. Какую роль ты в этом играл, как принимал решения, какой был результат?

🔄 Секция 2: Управление процессами
Цель: оценить подход к метрикам процессов, приоритетам качества и скорости, изменениям критичных процессов.
Вопросы:
- Как ты оцениваешь работу своей команды? Какие критерии и метрики используешь?
- Где твой приоритет в типичных дилеммах: качество vs скорость? Как принимаешь компромиссные решения?
- Есть ли у тебя опыт изменений критичных процессов? Как ты это делал?
- Что для тебя важнее — процесс или результат, и почему?
Кейс-вопрос:
- Приведи пример процесса, который тебе нравится или не нравится.

🎯 Секция 3: Целеполагание
Цель: понять горизонты планирования, метод постановки целей и механизм их достижения.
Вопросы:
- На какой горизонт ты планируешь и почему? Как выбираешь уровень детализации?
- Как ты ставишь цели себе и команде? Как обеспечиваешь достижение?
- Ты ожидаешь цели сверху или формируешь их самостоятельно?
- Как выстраиваешь операционный процесс под выбранные цели?
- Как переводишь абстрактные цели в измеримые планы и метрики?
Кейс-вопрос:
- Приведи пример конкретной цели и расскажи, как ты её достигал: план, трекинг, корректировки, результат.

🔀 Секция 4: Внедрение изменений
Цель: оценить подход к “приятным” и “болезненным” изменениям, управлению сопротивлением.
Вопросы:
- Как ты внедряешь изменения, которые команда воспринимает позитивно?
- Как ты внедряешь болезненные, но необходимые изменения? Как снижаешь сопротивление и риски?
Кейс-вопрос:
- Приведи пример неприятных для команды изменений, которые ты внедрял: контекст, план, коммуникации, результат. Если такого опыта не было — как бы ты подошёл к подобной ситуации?

🤑 Секция 5: Бизнес-экспертиза
Цель: понять, как кандидат видит вклад команды в бизнес, работает с метриками и влияет на них.
Вопросы:
- Как ты понимаешь роль и вклад своей команды в контексте бизнеса компании?
- Какие ключевые метрики у твоей команды? Как ты влияешь на них и на бизнес-результат?
Кейс-вопрос:
- Приведи пример конкретной бизнес-метрики и объясни, как твои действия повлияли на неё: гипотеза, действия, измерение эффекта.

По итогам каждой секции ставится 🟢,🟡 или 🔴 флаг. На основе количества флагов по цветам принимается решение о найме.