Не искал работу почти 8 лет. Наслушался от коллег по цеху, как легко и удобно это сейчас делать, поэтому я решил не ждать 2–3 месяца брожения, чтобы написать пост на линке!

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

Последние 2,5 года я занимался управлением продуктом и продуктовой командой в Skillbox. Разбирали, внедряли, собирали, пересобирали. Растили метрики, внедряли новые методики и масштабировали на новые продукты, собирали эффективную структуру управления продуктом.

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

Я умею всё, что связано с:

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

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

Стратегией: делать стратегии(продуктовые, командные, бизнесовые), декомпозировать стратегию до конкретных шагов, контролировать реализацию, лидировать достижение результатов.

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

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

И я готов дальше заниматься тем же, при этом чем-то более выраженным. Есть рекомендации)

Буду рад рекомендации, репостам и так далее. Ну конечно же ссылку на линк — https://www.linkedin.com/in/sergeypopov-56958875/

“Платформа всё сделает за вас”- обещание, которое никто не сдержал

Я тут готовлю доклад на TechLeadConf о том, как возникают и развиваются платформы в разных компаниях.
И созрел вот такой пост.

«Наша внутренняя платформа автоматизирует всё. Разработчик должен просто писать код и не думать ни о чём» - такой манифест написал какой-то РМ в конфлюенс еще в 2020 году и даже презентацию приложил с защиты…

Когда-то это звучало как прогресс.

Инженеры радовались: “наконец-то не надо писать Jenkins-файл”, “можно не париться с логированием”, “просто пиши сервис, остальное магия платформы”.
Но прошло время… и всё стало совсем не так весело.

1.
Новый монолит с лицом YAML'а
Ты не пишешь пайплайн — ты пишешь YAML.
Но YAML странный. Он не валидируется. У него 400 строк. И если ты ошибся с отступом — деплой ушёл в «отпуск» вместе с ответственным за платформу.
Все твои действия теперь обёрнуты в слои абстракций:
- Платформа делает деплой, но непонятно как.
- Платформа ставит алерты, но ты не знаешь, где они.
- Платформа следит за логами, но логи — это логи платформы, а не твои.
Ты уже не разработчик.
Ты шаман, который вызывает духов из CI/CD контура, обновляя pipeline.yaml и гадая по логам: где ты ошибся, о смертный.

2.
Контрибьютить в платформу? Только через обряд посвящения
Ты находишь баг. Например: пайплайн отваливается, если имя ветки начинается с hotfix/.
Ты пытаешься починить.
Но репозиторий платформы закрыт.
Там другой язык. Другая документация. Другие люди.
Чтобы внести изменение - надо собрать три комитета, написать оффер, пройти code-review у совета древних и подписать кровью SLA.
Поэтому ты ничего не правишь.
Ты просто запоминаешь: не называй ветку hotfix/.
3.
Баги, которые не баги (а просто фича не задумывалась).
Ты хочешь, чтобы сервис стартовал с другой версией базы. Или чтобы пайплайн не катился при изменении только .md.
Ты пишешь в канал поддержки.
Тебе отвечают:
“Так не предусмотрено в платформе.”
И ты вдруг понимаешь:
Ты не просто пользователь. Ты подданный.
А платформа — не инструмент. Это феодальная система. Где фичи — милость сверху.

4.
Когда документация — это GPT-галлюцинация
Документация есть. Но не про твою версию.
Ты читаешь и понимаешь:
- половина функций не работает, как описано.
- Вторая половина не описана вовсе.

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

5.
И всё-таки, зачем она вообще?
На бумаге всё круто.
Платформа стандартизирует. Упрощает. Ускоряет.
На деле:
Всё, что выходит за "золотой путь" - боль.
У людей нет контекста, как работает магия.
А когда всё-таки случается инцидент - никто не знает, где копать.

Итог?
Внутренняя платформа — это не silver bullet. Это просто новый вид легаси, только с модным логотипом.
Она экономит время… до тех пор, пока ты идёшь по её дорожке.
Шаг влево- и ты уже маг-отступник, в бою с обёртками, которых никто не контролирует.

А есть ли мораль?
Не строй платформу, если не готов её поддерживать как продукт. А лучше - не ври, что она “всё сделает за тебя”.

А вот тут можно поделиться своим опытом🤪

@badtechproject

Примеры ИИшки в бизнесе от Гугла

Гугл дропнули ультимативный гайд по использованию ИИ в бизнесе!

Пхах, я не удержался 😁

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

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

👉🏼Пока не начали читать результаты других, напомню, что мы с вами собираем свои кейсы по ссылке.

🚗 Mercedes-Benz: Голосовой помощник MBUX
Внедрение генеративного ИИ в систему MBUX позволило обеспечить более естественное и интуитивное взаимодействие с автомобилем, улучшая пользовательский опыт. (Mercedes-Benz USA Media)

🚘 General Motors (OnStar): Виртуальный помощник
Виртуальный помощник OnStar, использующий ИИ, обрабатывает более 1 миллиона запросов клиентов в месяц в США и Канаде, разгружая операторов для более сложных задач. (GM Investor)

🍕 Papa John's: Оптимизация заказов с ИИ
Сотрудничество с Google Cloud позволило Papa John's увеличить частоту заказов, повысить их стоимость, снизить затраты на обслуживание клиентов и улучшить удовлетворенность клиентов благодаря чат-боту на базе ИИ. (Papa John's International, Inc.)

🍔 Wendy's: FreshAI в drive-thru
Внедрение FreshAI в drive-thru ускорило обслуживание на 22 секунды по сравнению с местным средним показателем и достигло 99% точности заказов. (People.com, The US Sun)

🏦 Citi: Автоматизация код-ревью с ИИ
В первом квартале 2025 года Citi провел около 220 000 автоматизированных код-ревью с помощью инструмента на базе генеративного ИИ, увеличив производительность разработки. (Bank Automation News)

🏦 Deutsche Bank: Снижение ложных срабатываний
Внедрение ИИ позволило снизить количество ложных срабатываний при выявлении мошенничества на 60%, повысив эффективность и точность системы. (Toolify)

🏦 Intesa Sanpaolo: Цифровой помощник Ellis
Цифровой помощник Ellis, основанный на ИИ, улучшил взаимодействие с клиентами, предоставляя быстрые и точные ответы, что повысило удовлетворенность клиентов. (Qorusglobal)

🎨 Shutterstock: Генерация изображений с ИИ
Инструмент генерации изображений на базе ИИ позволяет пользователям создавать уникальные визуальные материалы по текстовому описанию, ускоряя процесс создания контента.

А как у вас там дела с этим?

❤️ - мы с ИИ лучшие друзья. «Всовываю» его всюду
🔥 - мы горим, какой ИИ
💊 - пока проблемы с естественным интеллектом. До 27 года лечим его, потом внедряем ИИ

@badtechproject

Аааааааа, Наташка так и описывает мою работу 😁

Че, у вас также?

💯 - конечно, брат
❤️ - чисто, для поддержки

#пятничноеневпятницу

@badtechproject

Началось!

Очередной тех.дир пишет: менеджеры не должны шарить в технике!

1.
Боится, что его поймают на завышеных оценках
2.
На том, что команда вместо оптимизации пилит очередной микросевис.
3.
Святая вера, что писать код - самый-самый уникальный навык в мире.

Менеджер, должен шарить в технике и вот почему:
1.
Написание кода - не более 25% времени от разработки.
2.
Разработка - это не про код. Это про его поддержку, процессы, когда все рухнуло и т.п. И, поверьте, невозможно строить процессы, если ты нифига не понимаешь.
3.
А что за управление родмапом и рисками, если менеджер даже не понимает, в чем суть задачи?
4.
По вашему дирижер не умеет отличать инструменты? Должен ли он уметь играть на всех инструментах и быть лучшим музынкантом? Нет! Но он должен разбираться в музыке!
5.
Задача менеджера - направлять команду к результату. А когда ты не понимаешь, кто и что делает, максимум - выполнение KPI, чисто, если повезет
6.
Ты изобретаешь велосипеды из Excel
Не зная, что у вас в компании уже есть CI/CD, ты запускаешь ручную проверку в Notion.
Зачем? Ну потому что "нужно контролировать".
И создаешь ещё больше ручной работы для тех, кто и так завален багами.
7.
Ты начинаешь мешать. Активно.
У тебя есть время — потому что ты не разбираешься в технике.
А значит, ты ходишь по митингам, предлагаешь "улучшения процессов", делаешь презентации.
И вместо пользы — шум.

🔥 - я знаю техничку, а техничка знает меня
❤️ - пис, пацаны, только не устраивацте разработки в очередном подкасте
🫡 - не, ну тех.дир прав, конечно. Менеджера менеджерское, инженерам инженерское

@badtechproject

Блин, это на столько хорошо дополняет пост и готовящийся доклад, что сегодня будет чуть сложное «пятничное»😁

1.
Если вы в платформе не думаете про «пользовательские сценарии», вида «выкатить приложение», «восстановить автоматически сервис, если он пятисотит», а мыслите формами вида:
- «создать каталог микросервисов сервисов»
- «развернуть контейнер» и т.п.

То вы, строите именно такой продукт, как в классическом ролике…

Долго, дорого,

радуйтесь, что вам на гульфик рукав не пришили

, ну и классика

к пуговицам претензии есть.

А «контейнер» и, правда, развернулся, только по пути потерялся мониторинг, настройки рейт-лимитеров и прочее…
И тогда, уж лучше бы он не разворачивался.

Поверьте, вам нужен работающий e2e сценарий, работающий в формате wow.
Вот этого жду ваши пользователи.

#пятничное

@badtechproject

«А что, а вдруг!»

Народ, у меня тут идет ремонт во всю и, вдруг, кто-то может подогнать хорошую скидку на технику ASKO?

С меня бутылка отличного вина😉

Если что писать сюда @badtechproject_contakt

Measuring Developer Experience With a Longitudinal Survey

Так-с, как и обещал в пятницу, делаю обзорчик.

Короче, Google снова выкатил вайтпейпер — статью-исследование на базе своих инженерных практик.
На этот раз про измерение Developer Experience.

Что такое Developer Experience?
Как мы помним, DevEx — это, конечно же, про печеньки, сырки и массажные кресла. Ну и зарплату! 🤑
На самом деле — нет.
DevEx — это про:
кайфовые инструменты, с которыми приятно работать;
процессы, которые помогают, а не мешают;
и то самое счастье разработчика, которое мы все ищем, но никак не найдем.

Что делает Google?
У них уникальный кейс: опросы по DevEx они ведут уже более 6 лет. Не просто «отправили анкету», а строят настоящую исследовательскую платформу.

Ключевые идеи из статьи:
1. Оценивайте сценарий, а не инструмент
Разработчик не мыслит: «поднять под».
Он мыслит: «выкатить сборку», «откатить фичу», «найти баг».
Хороший DevEx-опрос спрашивает не «нравится ли тебе Jenkins», а «насколько удобно тебе деплоить хотфикс».

2. Считайте NPS по сценариям
Идея крутая: применяй NPS (оценка 0–10, насколько порекомендуешь) к конкретным инженерным процессам.
Анализируй, где friction. Улучшай. Измеряй снова.

3. Опрос - это часть DevEx-продукта
Опрос - это не ради галочки. Это:
способ тестировать гипотезы;
метод влияния на культуру;
механизм игры в долгую.

4. Нет wow-эффекта → не проводите следующий опрос
Провели опрос - обязательно покажите, что изменилось:
- демо там проведит,
- пост в блоге напишите,
- внутреннюю рассылку намутите.

Вот вы проходили опрос. Мы внесли такие-то изменения. Вот, как стало лучше.

Без этого люди решат, что потратили время впустую.

5. Пульс-опросы раз в квартал
Google бьёт инженеров на 3 когорты и проводит опросы раз в квартал.
Хороший темп, если у вас 500+ инженеров. Почему бы и нет?

6. Команда: инженер + исследователь
Один - поддерживает инфраструктуру, второй - отвечает за вопросы и анализ.

У меня пока такого нет. Есть проджект, который держит опрос. Но под такой рост — модель классная.

7. Добавляешь вопрос - убирай старый
Желание добавить «вот ещё один важный вопросик» бесконечно. Но если вы дадите 50 пунктов — на 31-м люди будут тыкать в потолок. Ладно, не в потолок, а в среднее значение
Лучше меньше, но с фокусом и частотой. И с действием.

8. Не жди - встраивай обратную связь в продукт
Опрос - это отложенная реакция.
А лучше всего: встраивай оценку прямо в flow. После деплоя, после ревью, после CI-ошибки.
Так ты увидишь реальные данные - в моменте.

DevEx Starter Pack
Если ты только начинаешь и хочешь понять, где болит — вот 10 проверенных вопросов:

1. Насколько тебе удобно настроить окружение, чтобы начать новую задачу?
2. Насколько быстро ты получаешь фидбэк после коммита (CI, ревью, тесты)?
3. Насколько удобно тебе выкатывать фичу в прод в текущем процессе?
4. Если что-то ломается на проде, насколько просто найти и устранить причину?
5. Насколько тебе понятно, кто отвечает за нужный тебе компонент или систему?
6. Насколько удобно тебе получать помощь по внутренним тулзам и системам?
7. Насколько просто тебе разобраться в незнакомом коде?
8. Насколько удобно тебе участвовать в код-ревью (и получать его)?
9. Насколько ты можешь работать в фокусе, без постоянных отвлечений?
10. Насколько ты чувствуешь, что можешь влиять на процессы в команде?

DevEx начинается с вопросов. Главное - задавать их правильно.

Народ, а у вас в компании уделяют внимание DevEx?

💯 - дааа, все по кайф
🔥 - я и есть тот, кто делает DevEx
❤️ - помнишь мы планируем разобраться с естественным интеллектом к 27+? Ну там и к DevEx приступим 😁

@badtechproject

Так-с, народ:
потерялись почти все пункты «Что получаем от чатГПТ» в момент публикации почему-то…

Я их дополнил.

А этот пост должен быть полезным, поэтому ловите лайфхак для крутого промптинга:
Напишите LLM, какую задачу вы хотите решите с помощью промптинга и попросите составить промпт для этого 🤣

Результаты клевые, поверьте.
Я так уже пару месяцев делаю)

@badtechproject

Раз уж у нас с вами сегодня спортивная тематика, ловите 😁
Ну чисто я каждый раз после тренировки 🤣🤣🤣

Когда жена даже не прокомментировала мой памп после тренировки

#пятничноеневпятницу

@badtechproject

Принцип Ставок Энни Дьюк

Где-то месяц назад прочитал книгу и она прямо мега невероятный кайф.

Почему кайф?
Потому что мысли очень схожи с моими, однако выражены интереснее.

1.
Жизнь - это неопределенность. Каждый ваш выбор имеет некую вероятность на успех.
Однако, 100% успех никто не гарантирует.
Выбирая новую работу, вы делаете ставку, на то, что вам там будет лучше. Может ли что-то пойти не так? 100%

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

3.
Вы не можете ничего гарантировать. Вы можете утверждать, что с вероятностью 80% проект будет сдан в срок. Но гарантировать? Точно нет.

4.
Каждое ваше решение - это ставка.
Вы делаете ставку вашими ресурсами:
время, деньги, внимание.

5.
Как и в покере или на бирже, важно не просто «угадать», а оценить:
Какова вероятность успеха?
Какова ценность выигрыша?
Какова стоимость проигрыша?
6.
EV-мышление (ожидаемая ценность)
Даже если исход неудачен, ставка может быть хорошей, если на длинной дистанции она выигрывает. Это принцип, по которому мыслят профессионалы:
"Я проиграл конкретную сделку, но принял правильное решение, потому что EV был положительным."
7.
Дисциплина важнее уверенности
Лучшие игроки не уверены на 100%, но они дисциплинированы в ставках. Они знают, когда не ставить вообще. Это применимо в продуктах, инвестициях, найме, выборе фичи, да хоть в личной жизни.

Примеры применения:
- Фичи в продукте: «Есть 30% шанс, что эта фича взлетит, но если взлетит — увеличит выручку на 20%. EV — положительная ставка.»
- Хайринг: «Кандидат спорный, но upside высокий. Стоит рискнуть, если стоимость ошибки невысока.»
- Личная жизнь: «Не уверен, стоит ли идти в стартап. Вероятность успеха 20%, но рост X10. Если нет обязательств — ставка разумная.»
Выводы:
"Принцип ставок" — это не про азарт. Это про осознанные, аналитические, прагматичные решения. Про культуру «решений под вероятности», а не «правильных ответов».

Что такое EV (Expected Value) и зачем он тебе?
Спасибо чатГПТ за отличное определение😁
EV (ожидаемая ценность) — это способ оценить, насколько ставка (решение) выгодна в среднем, если повторять её много раз.
Формула:
EV = (вероятность успеха × выигрыш) – (вероятность провала × потери)
Примеры:
Запускаем новую фичу
Вероятность успеха: 30%
Потенциальный рост выручки: +1 млн ₽
Вероятность провала: 70%
Потери (время команды, отвлечение): –200 тыс ₽
EV = (0.3 × 1 000 000) – (0.7 × 200 000) = 300 000 – 140 000 = +160 000 ₽
Даже если «на глаз» кажется рискованным — ставка положительная. На длинной дистанции такие решения приносят прибыль.
Хайринг рискованного кандидата
Шанс, что кандидат выстрелит: 40%
Его вклад: +X10 к команде
Потери при фейле: несколько месяцев времени и ресурсов
Если EV > 0 — ставка стоящая. Даже если проиграешь конкретный раз, решение было правильным.

Главное: EV не говорит, что произойдёт. Он говорит, что имеет смысл делать снова и снова. Это как профессиональный спорт: не угадывать, а делать +EV ставки и жить с результатом.

🔥 - если уже читал и зашло
❤️ - добавил в бэклог
💅 - если читал и не зашло

@badtechproject

Хочешь карьерный совет №1?

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

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

Спасибо моему первому руководителю.

@bactechproject

Хочешь карьерный совет № 2?

Ну вариантов у тебя нет, я тебе его дам

Получил ссылку?
Открывай. Сразу.

Невероятно, как много раз люди писали «ок» и открывали ее перед дедлайном. Выглядело это очень плохо.

И за этот совет спасибо моему первому руководителю.

А поделитесь, плз, вашими советами, народ.

@badtechproject

Карьерный совет №3

Не понял, спроси!

Очевидно?
Как часто мы забываем об очевидных вещах в стрессовых ситуациях.
Я много раз видел, когда очень высокие руководители все вместе на встрече с ТОПами кивали головой, а потом признавались, что они ничего не поняли...

А у тебя было такое, что ты не понял и не спросил?

💯 - всегда так делаю, это мое жизненное кредо
🦄 - всегда спрашиваю, если не понимаю
❤️ - оооох, бывали случаи

P.S. Спасибо за напоминание

@badtechproject

💯- если было такое
🔥 - если ты тот самый родственник

#пятничное

@badtechproject

Хочешь карьерный совет №4?

Не успеваешь — предупреди. Сразу.

Даже если очень стыдно. Даже если ты почти доделал. Даже если надеешься «всё наверстаю ночью».

Знаете, проект - вещь вероятностная.
И чаще всего эта вероятность работает не в нашу сторону:

- билд развалится,

- макет не откроется,

дедлайн подползёт на цыпочках.

Не молчи.
В реальной жизни урон от молчания в 10 раз больше, чем от переноса.

👉🏼А вы как — честно говорите, что не успеваете? Или «лучше потерплю и сдам в 3 ночи»?
Давайте пособираем еще ваши кейсы.

P.S. И да, очевидных советов не бывает. Это единственное в чем я уверен на основе своего опыта.

@badtechproject

Короче, давайте просто и честно перестанем строить из себя героев, скажем друг другу:

1. Погода на улице топ!
2. Я задолбался работать.
3. 2. 1. выбегаем на улицу крикнув: «Я эту вашу работу…» и уходим в выходные!

❤️ - если ты со мной
🔥 - если тебе нужно еще погореть

@badtechproject