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

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

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

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

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

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

На глазок как методика оценки сроков

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

Чтобы такой подход сработал, важно соблюдать несколько правил:

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

Авито ищет сразу трёх тимлидов в разные команды. Ныряйте вниз за подробностями.

➡️ Тимлид разработки в команду маркетплейса
➡️ Тимлид разработки в команду «Запчасти и аксессуары»
➡️ Тимлид разработки в команду Data Quality

ЗП обсуждается с кандидатами лично, но вот что предлагают прямо сейчас:
• Талантливая команда и возможность реализовать свои идеи в проекте с многомиллионной аудиторией;
• Мощное железо, дополнительные мониторы и всё, что нужно для комфортной работы;
• Прозрачная система премий;
• Личный бюджет на обучение, который можно тратить на книги, курсы и конференции;
• ДМС со стоматологией с первого дня;
• Замечательный офис в двух минутах от «Белорусской»: панорамный вид на центр города, места для уединённой работы и зоны отдыха.

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

Вакансия Team lead на Go от Ozon Tech

Команда rFBS Ozon Tech развивает формат взаимодействия Ozon с продавцами, при котором они сами хранят, формируют и доставляют заказы. А Ozon работает как витрина с десятками миллионов лояльных клиентов. Компания хочет порадовать пользователей новыми фичами уже в этом сезоне распродаж.

Чтобы достичь амбициозных целей, Ozon формирует новые команды. Сейчас они в поисках тимлида с опытом разработки на Go.

Их проект — это:
— Работа в одной из самых быстрорастущих вертикалей Ozon,
— Высокие нагрузки до 300k rps,
— Архитектурные вызовы в контексте масштабируемости сервисов,
— Быстрый time-to-market,
— Возможность работать из офисов России и Казахстана / удалённо / гибридно.

Стек: Golang, PostgreSQL, Kafka, gRPC.

Узнать подробности о проекте, вакансии, бенефитах и откликнуться можно на этом лендинге.