Сделать первые шаги к карьере программиста можно через Python. Это востребованный, но простой язык: код компактный и похож на английский текст. Чтобы вывести надпись «tests» на экран, можно так и написать: print(""tests""). Освоить профессию Python-разработчика можно на курсе Яндекс Практикума.

◾️ Базовая программа → 9 месяцев
— интенсивная учёба по 20 часов в неделю;
— реальные рабочие задачи с первого дня;
— 6 учебных проектов в портфолио;
— программа трудоустройства: научим составлять резюме и проходить собеседования.

◾️ Расширенная программа → 14 месяцев
— учёба в среднем темпе по 15 часов в неделю;
— фундаментальная теория и много практики;
— 12 учебных проектов и проекты от реальных заказчиков в Мастерской;
— гарантия возврата: если вы не получите предложений о работе за 6 месяцев после выпуска, мы вернём деньги за обучение.

Наша статистика показывает, что сменить профессию — реально: 78% наших выпускников находят работу в новой сфере. Попробуйте курс бесплатно →

Когда мы со Стасом начинали делать Роадмап Тимлида, мы не ожидали, что он станет популярным. Им стали пользоваться и компании, и отдельные тимлиды. Он помогает с описанием ожиданий от роли тимлида, с систематизацией круга обязанностей, с организацией процесса найма менеджеров – да с кучей вещей. Но есть одна важная задача, с которой Роадмап не справляется – это обучение начинающих тимлидов и тех, кто собирается ими стать.

Вообще, обучение тимлидов – сложная штука. Одной теорией все запросы закрыть не получится – ведь полученные знания надо как-то применять и отрабатывать. Практику наработать тоже сложно – не у всех сходу есть готовая команда и проект, на которых можно учиться. Нам со Стасом всегда очень нравился Go Practice – симулятор работы продакт-менеджеров. Симулятор удерживает крутой баланс между прикладными знаниями, авторским опытом и проверкой изученного материала на живых заданиях и кейсах. И все это доступно для прохождения в асинхронном режиме в удобном именно для тебя темпе.

Мы решили попробовать перенести эту модель на обучение тимлидов, и несколько месяцев назад начали разрабатывать Симулятор Тимлида – большой интерактивный курс, который обучает и дает попробовать на практике самые важные инструменты и практики для менеджера, управляющего командами разработки. Чтобы разработать Симулятор, нам нужно подготовить огромную гору контента – и мы понимаем, что этот проект может спокойно занять год-полтора. Ждать столько времени, чтобы получить первичную обратную связь о том, насколько сам формат обучения и контент полезны – с продуктовой точки зрения самоубийство. Поэтому мы решили начать собирать фидбэк как можно раньше, и открыть программу раннего доступа к Симулятору. Что у нас уже есть – MVP версия обучающей платформы, одна очень большая глава про управление встречами и календарем, и еще две близкие к релизу главы – одна про обучение сотрудников, другая – про подбор людей в команду.

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

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

Мы очень верим в крутость Симулятора, и хотим собрать вокруг себя еще людей, которые смогут кайфовать в процессе его написания вместе с нами!

👉Форма регистрации

Принципы здорового алертинга и on-call процесса

Почти во всех компаниях процесс on-call дежурств – боль, страдание и частая причина увольнений. В презентации СТО Honeycomb предлагает следующие шаги по исправлению ситуации:
🌡Выключить алерты на симптомы, заменить их алертами на SLO, которые привязаны непосредственно к болям пользователей.
🤔Удалить все флакующие алерты, потому что моральное состояние людей важнее.
🚨Почти все алерты должны падать во второстепенную очередь, на которую не требуется мгновенная реакция дежурного. Вместо этого, очередь можно разбирать с началом рабочего дня.
📝Каждый алерт должен идти со ссылкой на подробную документацию о том, что его может вызвать.
👀Инвестируйте в observability своего кода и сервисов, профилируйте максимально часто и ловите баги до того, как они отстрелят у пользователей
📈Используйте SLO для того, чтобы приоритизировать работы по техническим улучшениям

#техлидство

Подборка инструментов, помогающих думать

Сайт с каталогом инструментов и фреймворков, которые помогают улучшить коммуникацию, прокачать системное мышление и принятие решений. Среди них – Пирамида Минто, Six Thinking Hats, Decision Matrix.

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

✍️Менеджерские практики
Большой гайд по менеджменту remote команды
Надо ли включать камеры на созвонах
Выпуск Подлодки про то, что оценки не нужны
Подборка шаблонов RFC и PRD

👀Поиск работы тимлидом
Коллекция видео Team DrivenCon про поиск работы тимлидом в Европе
Как подготовиться к собеседованию на Engineering Director
Публичное собеседование тимлида

💬Коммуникации
Как научить не бояться просить о помощи
Рассказываем о своем опыте, используя метод STAR
Системный разбор рабочих конфликтов
Как связаны выгорание и рабочие конфликты

👨‍👨‍👦‍👦Найм и рост
Почему карьерная линейка Staff инженеров часто не работает

🐣Подписывайтесь на мой Твиттер – там я пишу немного смешные шутки про айти, полезные тимлидские треды и рассказы про то, как мы деляем язык программирования.

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря! А если у вас будут конкретные предложения по его улучшению – смело пишите в комментарии!

#digest

Как общаться с топ-менеджерами

- Лучший способ подготовиться – изложить свои мысли в документе, это само по себе заставляет подходить к проблеме структурно.
- Попробуйте фреймворк SCQA: Situation – Complication – Question – Answer.
- Поговорите с теми, кто уже показывал что-то этому топ-менеджеру. Это поможет узнать дополнительные советы, которые помогут правильно подойти к разговору.
- Не стоит спорить с обратной связью. Лучше сделать это позже.
- Не избегайте ответственности и проговаривания проблем.
- Не приходите без готового ответа.

Путь из СТО в инженеры

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

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

Должен ли менеджер быть щитом от дерьма для команды

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

Как давать полезный фидбэк

- Используйте принципы radical candor: проявляйте явную заботу о том, кому вы даете фидбэк, но в то же время будьте максимально прямым и откровенным.
- Не пытайтесь защитить людей от неприятного фидбэка, это им не поможет. В то же время, не стоит и вываливать негативную обратную связь, не проявляя участия и заботы.
- Попробуйте следующий процесс: получить согласие на фидбэк > расскажите факты > объясните, как конкретно эти факты повлияли на результат > завершите вопросом про то, как человек сам видит всю ситуацию.
- Постарайтесь давать обратную связь как можно чаще, это помогает оттачивать навык.

Как сделать так, чтобы сотрудники приходили к тебе с решениями, а не проблемами?

Кажется, что так бывает только в раю, но эффективный менеджмент и честное взаимодействие с коллегами ещё и не на такое способны!
Вот несколько шагов, которые помогут взрастить уровень ответственности подчинённых.
👇🏻
Держитесь позиции взрослого
Не берёте ли вы на себя роль “родителя”, когда сотрудники обращаются к вам с позиции детей и приглашают взять на себя функции спасения? Есть вероятность, что у команды гораздо больше компетенций для решения проблем.
👇🏻
Сверяйте степень директивности
Не душите контролем тех, кто уже показывает высокий уровень ответственности. Лучше поощряйте автономность и воспроизводите постепенно эту модель с теми, кто пока нуждаются в конкретике.
👇🏻
Будьте готовы к ошибкам
Любая инициатива и изменения увеличивают шанс на ошибку, но без этого вы не получите развития коллег. Планируйте люфт и ресурсы для возможных экспериментов, внедряйте общие практики спокойного и позитивного разбора ошибок.
👇🏻
Спрашивайте, а не отвечайте
Постепенно увеличивайте количество навигирующих вопросов по задачам, чтобы побудить сотрудника к собственным предложениям. Не «Давай сделаем так», а «Как ты считаешь, что здесь можно сделать?»

👥 Этот и другие сложные управленческие кейсы разбирают на курсе «Как управлять командой и собой». Живые воркшопы от экспертов с многолетним опытом в управлении помогут решить ситуации, которые волнуют вас прямо сейчас. Вы подготовитесь к любым трудностям в команде — от кризиса до реструктуризации.

Все детали о спикерах и обучении здесь: https://clck.ru/sTiTx

Подборка статей про стратегию

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

- Оценка стратегии через призму “ставок”, и баланса между risk и reward
- Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
- Чем отличаются фокусировка и обобщение в стратегии
- Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
- Почему у многих команд и компаний нет стратегии
- Нормально ли, если стратегия часто изменяется

Переход из тимлида в менеджеры менеджеров: вредные советы

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

🎤Автор предлагает с первого месяца в новой роли ворваться в хайринг – разобрать все открытые вакансии, выяснить как они ложатся в общую стратегию, подключиться к процессу интервью самостоятельно. Цель всего этого – получить общую картину по тому, насколько здоровый в команде процесс найма.
💬Найм – это инструмент. До того, как пытаться его чинить, надо понять, а есть ли с ним вообще проблема. Наличие проблемы не определить, пока ты не понял, а что и зачем в командах разрабатывается. Поэтому я бы построил план по-другому:
1. Разобраться с общей стратегией компании, поговорив с релевантными людьми.
2. Выяснить, в чем заключается успех работы каждой из команд.
3. Поговорить с заказчиками и сотрудниками и собрать список известных им проблем, которые мешают достижению успеха.
4. Вместе с тимлидами своих команд оценить влияние этих проблем друг на друга, выделить корневые.
5. В зависимости от того, в чьей зоне влияния находятся проблемы, делегировать их решение тимлиду или заняться этим самостоятельно.

Найм – не обязательно самая горящая проблема. Без понимания контекста вы будете еще одним бесполезным ценным мнением, которое будет толтко мешать.

🎤Автор советует организовать регулярные встречи со всеми, с кем только можно – 1/1 с заказчиками, синки с коллегами, еженедельные митинги с прямыми подчиненными.
💬Синхронное общение – отличный инструмент для тех случаев, когда требуется соединить картины мира и знания нескольких людей чтобы быстро прийти к общему решению. Это очень дорогой инструмент – он сильно вырывает людей из рабочего контекста, причем в то время, которое удобно автору встречи, а не им.

Заводить кучу встреч без явной агенды с целью «посинкаться про статус» – вредно для всех участников. Вместо этого я бы рекомендовал следующий подход:
1. Асинхронное общение по умолчанию. Если вам нужно узнать статус каких-то проектов – настройте общение в чате или в проектном трекере.
2. Если требуется регулярное общение с одними и теми же людьми в рамках решения какой-то конкретной проблемы – регулярные встречи рабочих групп с внятной повесткой – тоже нормально.

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

Как подходить к решению крупных проблем

🤔Не всегда первое приходящее на ум решение будет самым лучшим. Потратьте время на то, чтобы аргументировать его.
💬Проверьте, что проблему вообще стоит решать, поговорив с людьми с другим бэкграундом.
🤬Не поддавайтесь на критику сомневающихся, но отрабатывайте их возражения.
🤝Учитесь убеждать стейкхолдеров, находя свои аргументы для каждого из них.
👨‍👩‍👧‍👦Постройте две команды – инженерную, которая будет работать над решением каждый день, и расширенную, включающую в себя юристов, бизнес, дизайн и другие функции, которые могут пригодиться.

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

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

Программа состоит из модулей:
⚫️Анализ ситуации и мышление на уровне бизнес-модели.
⚫️Трендвотчинг и изменение бизнес-модели
⚫️Редизайн бизнес-модели. Коммуникация изменений и питчинг.
⚫️Дорожная карта внедрения инноваций.
⚫️Лидерство в продуктовой команде.

В финале обучения вас ждёт презентация итогов работы и обратная связь от лидеров индустрии.
Обучение проходит в смешанном формате: офлайн и онлайн и длится 4,5 месяца. На обучение вам понадобится 10-15 часов в неделю:
- на офлайн-занятиях вы будете участвовать в воркшопах и деловых играх с лидерами индустрии и коллегами из других цифровых компаний,
- в онлайне вас ждут лекции, практические руководства от экспертов, а также мастермайнды и встречи с сокурсниками.

Стоимость программы 600 000 руб.

Узнать подробнее и записаться на курс можно по ссылке

Письмо от СЕО

Люди в команде всегда ценят прозрачность со стороны руководства. Интересный способ ее обеспечивать – писать регулярные письма или дайджесты на всю команду. Они могут включать в себя:
🤔Список ключевых проблем/хайлайтов, которые держат ваше внимание прямо сейчас
🚦Performance update – статус движения по ключевым целям или проектам
💬Разбор какого-то волнующего всех вопроса

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

Дизайн-спринт – набор практик для быстрой проверки гипотез

- Подход предлагает провести полный цикл тестирования идеи – от формулировки проблемы до создания прототипа и проверки его на пользователях за пять дней
- В Додо попробовали адаптировать его к еще более короткому промежутку – к трем дням
- В первый день формулируется исходная проблема, критерии успешности и вопросы, на которые надо найти ответ
- Во второй день генерируются способы решения проблемы, выбирается самый перспективный и дорабатывается
- В третий день разрабатывается максимально простой прототип и тестируется на пользователях
- Подробнее про методологию можно почитать в книге «Спринт»
- Похожий подход мы пробовали применять и в Kotlin, когда решали проблему улучшения онбординга пользователей и создания нового сценария Get Started – получилось очень полезно

Что делает разработчиков несчастными

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

Как разные компании платят за дежурства

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

⛑Для дежурств нанимают выделенных людей, это основная их работа
📵Дежурства вне рабочих часов отсутствуют
📳Дежурства вне рабочих часов отсутствуют, но потенциально вас могут поднять звонком
🌏Дежурства обязательны для всех инженеров, регулируются сообразно трудовому кодексу конкретного региона
💵Дежурства – часть работы, оплачиваются либо компенсируются выходными
☝️Дежурят волонтеры, но все компенсируется
🤬Дежурства обязательны для всех и никак не компенсируются

Сложные вопросы, которые помогают придумывать новые идеи

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

- Что надо сделать, чтобы оправдать повышение цен в 10 раз
- Все пользователи ушли, все надо отстраивать с нуля – как вы поменяете продукт
- Вам запрещено использовать ресурсы технического саппорта, как адаптироваться к ситуации
- Если сроки на реализацию проекта срежут в десять раз, как вы поменяете подход к реализации

Такие вопросы можно адаптировать и к небольшой команде разработки:

- Что произойдет, если ваш основной фреймворк задепрекейтят
- Все рекрутеры уволились, как поддержать найм
- В компании запретили все митинги до единого, как подстроить к этому ваши процессы

Вред KPI и метрик в процессе разработки

«Единственная причина вводить KPI – это отсутствие доверия к тому, что ваши разработчики заинтересованы разрабатывать с максимальным вложением своих сил и знаний и становиться лучше со временем».

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