Платформы не умеют делать демо

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

Вот список типичных отговорок:

«У нас слишком низкоуровневая работа, там нечего показывать».
«Мы ещё не готовы, у нас рефакторинг фреймворка внутри пайплайна».
«Мы делаем задел на будущее, вот через квартал…»

Что скрывается за этими фразами?
«Мы не умеем показывать, чем мы тут занимаемся и не умеем объяснять бизнес-ценность».

Почему это важно?
1.
Выбор без обратной связи = трата времени.
Платформенные команды часто «строят на опережение». Без демо это превращается в «строим в темноте». Через 3 месяца оказывается, что это никому не надо.
2.
Прозрачность — это тоже Developer Experience.
Если продуктовая команда не понимает, чем занимается платформа — начинается недоверие, «они там что-то копают», приоритизация летит в мусорку.

Ааааааа, это ваще огромная отдельная тема!

Че делать-то???

Как приучить к демо (и не убить мотивацию):
1.
Показывать не фичи, а прогресс.
Демо — это не «запуск релиза», это «что мы делали, что решали, к чему пришли».
Даже скрин логов с коротким объяснением — это демо.
2.
Делать демо для своих.
Пусть сначала это будут свои — внутри платформы, без внешних команд. Главное — войти в ритм. Без оценки. Без пафоса. Просто ритуал.
3.
Завести шаблон демо.
Что мы планировали?
Что получилось?
Что поняли?
Что мешало?
Что дальше?
4.
Демо - это не презентация в PowerPoint.
Это может быть запись скринкаста, консолька с логами, объяснение архитектурного решения на Miro. Инструмент не важен. Важно делиться.

Какой итог?

Научитесь показывать промежуточные результаты — и получите:
- Быстрее обратную связь
- Повышение доверия к платформе
- Меньше боли на релизе
- И, возможно, даже благодарность от продуктовых команд (да-да, бывает).

@badtechproject

«Лингво Хакинг» Елена Кочева

Че по книге и почему мне зашло:

0. Прямо на обложке про подход 80 на 20. Хочешь мне что-то продать, помести этот тезис на обложку 😁

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

2. Чтобы (1) звучал не так явно автор вводит много разных психологических портретов разных «изучателей английского».

3. Прикольно, что сама книга, крутит изучение Английского вокруг проектного/продуктового подхода:
- есть роли/типы пользователей
- есть разные цели
- у всех будут свои вехи
- описаны трудозатраты на разные этапы
- описаны риски перепрыгивания через этапы

4. Книга - во многом про некий набор стандартных психологических приемов для саморазвития, которые применимы к любой сфере.

5. Там еще и домашка есть😱

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

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

🔥 — Если уже прочитал и зашло
❤️ — В список must-read
💅 — Если не зашло

P.S. Прикольно, когда авторы присылают тебе книги на ревью)

@badtechproject

Друзья, сегодня важнейший день для нашей страны и для всего мира!
Сложно переоценить его значение!

С праздником вас!

На фото мой прадед
Арюткин Александр Яковлевич.

Воинское звание:
батал. комиссар|майор

Место службы
37 осбр; ПолитУ ТуркВО|37 осбр СЗФ|204 сд 43 А
Дата призыва: Июль 1941

Медаль «За боевые заслуги»|Орден Отечественной войны II степени|Медаль «За оборону Москвы»|Медаль «За победу над Германией в Великой Отечественной войне 1941–1945 гг.»|Орден Красной Звезды

Парадокс Расемона

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

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

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

Представьте: одно преступление, один труп, четыре свидетеля. Самурай, его жена, бандит и случайный прохожий. У каждого — своя версия произошедшего. У каждого — свои мотивы. И все версии — противоречат друг другу.
Эта сцена — из фильма Акиры Куросавы «Расемон» (1950). Именно она дала название парадоксу Расемона: феномену, при котором разные люди по-разному интерпретируют одну и ту же ситуацию.

А почему так происходит?

1.
Когнитивные искажения: короче, как я уже говорил, мы с вами совершенно не объективны.

2.
Мы обожаем тешить наше эго:

Люди часто «подкрашивают» воспоминания, чтобы выйти из ситуации не виноватыми, а даже героями.

3.
Мы еще и на разное обращаем внимание: эмоции, данные, схемы, таблицы.

Как с этим жить?

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

2.
Разделяй факты и интерпретации. Это не одно и то же.

3.
Учись слушать без защиты. Иначе будешь слушать, чтобы ответить, а не понять.

Парадокс Расемона - это еще одно напоминание нам о том, чтобы мы старались быть объективными. На каждую встречу берите себе стикер с этим напоминаем и старайтесь быть максмимально объективными.

@badtechproject

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

@badtechproject

Начальник меня не слушает

Иногда нам всем кажется, что начальник нас не слушает и не слышит…

Создаётся ощущение, что ты на работе — как фон. Есть, но никто не замечает

Бывало у вас такое?

Ну сознайтесь, уверен за вашу карьеру такое точно могло быть.

Разберем, почему так?

1. Ты невероятно хорош!
Вы хорошо делаете свою работу, идеальный винтик корпоративной машины и он вам доверяет максимально.
Что делать в этой ситуации, чтобы привлечь внимание?

Фиг знает, поднимите вопрос о повышении. Он сразу обратит на вас внимание.

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

3. Жопа горит у твоего начальника
У него сейчас есть другая срочная задача… Пожар, который он тушит.
Помните я недавно пост про доверие выпускал?

Ну вот если доверие есть, то так и скажите: давай встречу подвинем, лучше потом полноценно пообщаемся.

4. Ты параноик
А может это ваш заскок? И он обращает внимание?
Просто вам вот нужно что-то прямо особенное?
Например, чтобы вас по спинке погладили!

Накидать мне можно вот тут

🫡 - если ты идеальный винтик корпоративной машины
🔥 - если жопа в огне и у тебя, и у начальника
💊 - если ты параноик

@badtechproject

Еще только вторник…

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

@badtechproject

System Design от Чжиюн Таня
или как выжить на интервью, не превратившись в кусок тревожного желе

Если вы дочитали Алекса Сюя и такие:
«Ну всё, теперь я точно архитектор Google»,
а потом вам на интервью говорят:
«А теперь спроектируй систему, где миллионы юзеров одновременно жмут лайк на видео» —
и вы снова: «Эээ... ну… может, кэш?»,
то держите вторую дозу системного просвещения — книга Чжиюн Таня "System Design: How to Survive the Interview".

1.
Книга больше говорит о базе и по ощущениям рассчитана на программистов, все-таки.
2.
Мне перевод понравился чуть меньше. Мне не так важно, но знаю, что есть очень чувствительные к этому люди.
3.
Крутые кейсы (включая те, что редко встречаются):
- Push Notification Service
- API Rate Limiter
- Design a Web Crawler
- Система для бронирования билетов (да-да, как в авиакомпаниях)
- И даже… система аутентификации

В кейсах, опять таки, больше деталей.

4.
Перед самими кейсами больше базы алгоритмической

5.
Фреймворк систем-дизайна, который он продвигает:
- Clarify Requirements: разбираем юзкейсы и ограничения
- Define API and Data Flow: как данные гуляют по системе
- Back-of-the-envelope calculations: нагрузки, размеры, TPS
- High-level architecture: компоненты и их взаимодействие
- Bottlenecks and scaling: что сломается и как починить
- Trade-offs discussion: чем пожертвовали ради чего
6.
Мне больше понравился Алекс Сю, так как, по ощущениям, книга больше рассчитана на менеджеров, а это то, что нужно мне)

🔥 — Если уже прочитал и зашло
❤️ — В список must-read
💅 — Если не зашло

@badtechproject

Блин, вы видели погоду???
Сегодня уже три 1:1 на улице провел за прогулкой!

Ну просто кайф же!

Гоу все на улицу!

@badtechproject

Как же я обожаю этот мем!
Невероятно жизненный)

@badtechproject

Ахахахха
Зацените, на People Sense МТС «переосмыслили» идею моего канала😁

@badtechproject

Давайте поможем Сереже. Искать работу дело хлопотное, особенно, если ты после курсов SkillBox😁

Серега был там директором по продукту)

P.S. Серег, я не удержался…

Не искал работу почти 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