Product Map – карта всего, что надо знать продактам

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

Из хороших альтернатив могу еще посоветовать вот эту карту от автора Product Architecture Framework.

Что отличает хорошие решения от плохих

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

👉Вся суть принятия решений в том, чтобы выбрать путь с наибольшей вероятностью успеха, основываясь на доступной в данный момент информации.
👉Качество решений нельзя оценивать, смотря на их результат. Не всегда цель может быть сформулирована заранее, и сравнить ожидания с реальностью не выходит. А оценивать результат в вакууме довольно бессмысленно.
👉В таких условиях имеет смысл оптимизировать то, что находится под контролем – процесс принятия решения и предварительный анализ.

Помимо этих тезисов большая часть статьи как раз про советы по повышению качества процесса и анализа.

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

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

Успевайте присоединиться к обучению: https://karpov.courses/systemdesign

Кстати, по промокоду LEAD15GR для вас действует скидка 5% до 20 сентября.

Реклама. ООО "Карпов Курсы". Erid: LjN8KNvey

SRE принципы для CI/CD пайплайна

Хороший подход к определению ожиданий к стабильности CI/CD пайплайна с использованием хорошо известных SRE практик:

⭐️Service Level Objectives (SLOs): какой уровень стабильности гарантирован.
📊Service Level Indicators (SLIs): как именно трекается уровень стабильности.
🧳Error Budgets: как долго пайплайн может не отвечать требованиям SLO.

Пример:

⭐️SLO: Каждый коммит должен быть протестирован в течение 5 минут после пуша.
📊SLI: Общее время прогона билда.
🧳Error budget: 40 билдов, время прогона которых заняло больше 5 минут, на протяжении 4 недель.

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

Пол и потолок в перфомансе

У баскетбольных аналитиков есть модель описания перфоманса игроков, основанная на их граничных показателях:

👉High floor, high ceiling: Самые лучшие игроки, которые показывают отличный результат и в хорошие дни, и в плохие.
👉High floor, low ceiling: надежные игроки с предсказуемо средним перфомансом.
👉Low floor, high ceiling: ненадежные игроки с проблесками гениальности. Могут сыграть как отвратительно плохо, так и слишком хорошо.

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

Что уменьшает продуктивность разработчиков

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

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

Бреслав и Ложечкин про делегирование

Новый выпуск моего любимого (хоть я и немного аффилированное лицо) подкаста про тимлидство! Андрей Бреслав, Александр Ложечкин и приглашенный гость Мария Аникина обсуждают все про делегирование: зачем оно нужно, кому и что можно делегировать, и что делать, если делегировать не получается.

Кстати, вышла уже половина первого сезона. Если вам нравится подкаст, будет очень круто, если вы расскажете о нем у себя в рабочем чате или посоветуете друзьям! Ну и, конечно, подписывайтесь на ребят в телеге: @breslavandlozhechkin.

Как менеджеры могут влиять на мотивацию

Никак. Мотивация – это внутренняя сила человека, которая формируется в течение всей его жизни. Поменять то, что драйвит человека, практически невозможная задача. "Замотивировать" его – тоже. Вместо этого менеджер может:

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

Podlodka Product Crew про экономику и монетизацию

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

📆Дата: 18–22 сентября
👉Регистрация

Реклама. ИП Толстая Елена Петровна ИНН:507503278104, erid:LjN8KKWii

Холивары о собеседованиях

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

Так вот, расскажите в комментариях, а как все-таки правильно нанимать людей!

Подход к онбордингу джунов

Когда New Relic выросли до 60 команд, они решили активнее нанимать джунов. Вот как у них выглядел онбординг:

1️⃣ Первые две недели джун работает со специально подготовленным проектом, на котором он знакомится с инфрой, процессами разработки и командными практиками.
2️⃣ Каждому джуну назначается ментор.
3️⃣ Следующим этапом джун проходит ротацию между несколькими настоящими командами. В каждой из них он находится несколько недель и работает над настоящими задачами.
4️⃣ Джуна активно подключают к общению с разными коллегами, чтобы он набрал побольше информации о том, как работает компания.
5️⃣ После нескольких ротаций, джун привязывается к команде на постоянной основе.

Фишинговые письма для проверки поведения людей

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

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

Реклама. Рекламодатель: ООО «ВК ЦИФРОВЫЕ ТЕХНОЛОГИИ». ИНН 7714415613. Erid: 2VtzqvHAgGg

🧬 Вебинар-дискуссия «Безопасность на уровне кода: как эту задачу помогает решать облако». Продолжение серии мероприятий от VK Cloud и «Лаборатории Касперского»

⏰ Когда: 21 сентября, 17:00
📍 Регистрация

Участники первого вебинара из серии «Безопасная разработка в облаке» обсуждали ИТ-ландшафт с фокусом на безопасность и специфику рынка РФ после 2022 года.

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

В программе:
🔸 наиболее распространенные угрозы для приложений и какие из них актуальны, например OWASP;
🔸 принципы безопасной разработки и подходы к архитектуре;
🔸 инструменты обеспечения безопасности на уровне кода: SDLC, SAST, DAST и другие;
🔸 что влияет на безопасность: логирование, мониторинг, трейсинг и OpenTelemetry;
🔸 облачные инструменты обеспечения безопасности кода.

Участники дискуссии:
🔹 Роман Ермаков, продуктовый менеджер, VK Cloud
🔹 Алексей Рыбалко, эксперт по кибербезопасности, «Лаборатория Касперского»
🔹 Илья Сидельников, начальник отдела автоматизированного анализа безопасности, VK

Вебинар будет полезен разработчикам и тимлидам команд разработки, DevOps и DevSecOps, руководителям и специалистам по ИБ, техническим и ИТ-директорам.

Зарегистрироваться

Фидбэком не решить проблему недостатка скиллов

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

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

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

Как вести смоллтолки

Если вас, как и меня, ставит в тупик вопрос "How are you?", заданный в начале созвона, или, еще хуже, вы не понимаете, насколько детально нужно описывать погоду за окном, чтобы сойти за своего, это идеальный пост для обучения культуре смоллтолков.

Ключевые идеи:

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

Do your one job first

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

Пипл-менеджмент сложных инженеров

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

Смерть от тысячи микросервисов

В подавляющем большинстве случаев микросервисы принесут вам намного больше проблем в долгосроке, чем пользы в краткосроке. Думаю, вы уже и сами видите, что хайп на микросервисы довольно сильно упал, и некоторые компании, которые смогли его пережить и не загнуться от счетов от AWS, уже пытаются собрать свои монолиты по кусочкам обратно. Самые смешные примеры – это, конечно, Uber, которые были евангелистами микросервисов много лет, и Amazon Prime, хотя казалось бы.

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