Обязательно ли разработчики должны развиваться

Большинство начинающих тимлидов, засучив рукава, начинают заниматься развитием своей команды. Вооружившись матрицами компетенций, делают оценку 360, строят индивидуальные планы развития и на еженедельных one-on-one разбирают прогресс.

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

Про Кароля Адамецкого, автора российской теории проектного менеджмента

Интересная статья про довольно малоизвестного теоретика и практика менеджмента.

Кароль Адамецкий, работая менеджером на заводе, изучал взаимосвязь процессов в проектной деятельности и пытался управлять ими. Результатом его исследований стали гармонограммы – гибкие проектные графики, похожие на изобретенные позже диаграммы Ганта и PERT. Для работы с гармонограммой требовалось механическое устройство – гармонограмм.

Эффект IKEA

Исследование 2011 года показало, что люди, которые сами собрали мебель из IKEA, считают ее выгодным вложением на 63% чаще, чем те, кто просто приценивается к аналогичной собранной кем-то еще мебели. Привязанность к предмету тоже значительно повышается для тех, кто своими руками его собирает.

Этот эффект объясняет два других часто встречающихся в разработке синдрома:

💦Sunk costs effect – продолжение инвестиций в проект, который уже очевидно не выгорел, только потому, что в него уже многое было вложено раньше
🤷🏻‍♂️Not invented here syndrom – отказ от идей и технологий, разработанных где-то или кем-то еще только потому, что это не in-house разработка

Хотите быть крутым лидом, но эффективность команды падает?
Пытаетесь контролировать процессы, но не хватает времени и слаженности действий специалистов?

Не печальтесь! Учебный центр «Слёрм» подготовил кое-что интересное именно для вас, а именно бесплатный вебинар «7 типичных ошибок тимлида», в ходе которого опытные преподаватели учебного центра «Слёрм» Ксения Клен и Андрей Булов помогут разобрать самые распространенные, но не всегда очевидные ошибки и подскажут, как избавиться от них.

О чем обещают рассказать?
Что делать, если нет понимания куда двигаться самому и вести команду.
Как перестать все делать самому и начать делегировать работу.
Как выстроить в коллективе дружную атмосферу и справляться с конфликтами.
Что делать, если проблемы не решаются, а замалчиваются.
Как донести до команды ценность бизнес-метрик и важность их отслеживания.
Почему «тушение пожаров» — плохая практика.
Как быть, если команда стала неуправляемой и отказывается слышать.

Вебинар пройдет в среду 21 сентября в 19:00.

Успейте записаться — будет интересно и максимально полезно. 
Регистрация: https://slurm.io/webinars/team-lead-errors

Качество как функция системы его обеспечения

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

К характеристикам такой системы обеспечения качества относится:

🐞Культура и инфраструктура, поощряющие написание тестов и дающие на это время
💻Надежные и простые в использовании dev/test окружения
☮️Отсутствие давления на команду, заставляющего релизить недостаточно протестированный код
📝Наличие документации и выделяемое на нее время
💬Регулярный разбор факапов с исправлением их корневых причин, без попыток блеймить кого-то

44 правила начинающего тимлида

Список важных правил и принципов, которые нужно распечатать себе на стену, когда вы только стали тимлидом.

🤔Что вы должны и не должны делать
🤩Мотивация и культура
❤️Эмоции и люди
🌩Управление конфликтами
💬Сложные разговоры
🧱Отстаиввние личных границ

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

Помочь разобраться могут инструменты Scrum для разработчиков, а Практикум — разобраться с тем, как их внедрить.

За 7 дней обучения вы:
◾освоите самый популярный Agile-фреймворк;
◾разберётесь, как работает фреймворк Scrum;
◾удете много практиковаться и участвовать в вебинарах.

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

Узнать о курсе больше и начать учиться бесплатно →

Зачем тимлиду прокачивать продуктовую ветку

Одна из возможных веток развития тимлида – продуктовая. Разные люди качают ее по разным причинам:

🤝В продуктовых компаниях тимлид и продакт-менеджер часто работают максимально тесно, и тимлид в экстренном случае должен быть способен подменить продакта. Например, во время моей работы в Авито это случалось не раз, как и обратная ситуация.
🤔Работа тимлида – находить оптимальные способы решения задач бизнеса. Ты не принимаешь решения, что делать, твоя задача – заниматься деталями реализации. Если тимлид хочет напрямую влиять на то, как конкретно принимаются решения, то он рассматривает для себя продакт-менеджмент как потенциальное продолжение карьеры.
🌩Не все продакты – одинаково скилловые. Вместо того, чтобы принимать все идеи продакта на веру, полезно уметь челленджить его доводы.
📝Несколько лет назад было популярно движение «Что угодно – это продукт». Продуктовый подход действительно можно применить к чему угодно – к инфраструктуре, процессам, своей команде.

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

🪄Воркшоп «Прогнозируем влияние фичей до начала разработки». Такой навык может помочь не бросать команду на заранее бесполезные задачи.
📊Воркшоп «Лезем в данные самостоятельно». Поможет посчитать метрики самостоятельно, чтобы отстоять свои собственные идеи перед продактом, или проверить его выводы.
💰Воркшоп «Финансовые метрики и юнит-экономика». То, как продукт зарабатывает деньги, часто остается черным ящиком для тимлида, хотя в итоге именно от этого зависит выживание его и его команды.

Конференция стартует уже в понедельник. Я забыл выложить анонс заранее, поэтому держите промокод – product_crew_2_SINaBE.

Подключайтесь, тимлиды с продуктовым мышлением – на вес золота!

Как в Shopify переделали систему расчета компенсации

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

Инструменты для управления ИТ-инфраструктурой

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

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

🛒Интернет-магазин, чтобы справляться с нагрузкой в самый пик
🐞Софт для тестирования
📊бизнес-приложения или хранить большие массивы данных

Все условия и подробности акции – по ссылке

Дисфункции организаций

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

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

Что такое data engineering

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

Курс «Английский для аналитиков» от Яндекс Практикума

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

• Самопрезентация. Рассказ о своей роли, задачах, сфере ответственности на поведенческом интервью и в неформальной беседе.
• Работа в команде. Стендапы, планирование спринтов, демонстрация навыков командной работы на собеседовании.
• Общение с заказчиками и исполнителями. Сбор требований у стейкхолдеров и постановка задач для разработчиков.
• Презентация результатов работы. Выступление на митапах, неформальное общение с коллегами из отрасли.
• Обсуждение решений по проекту. Генерация и аргументация идей, участие в мозговых штурмах.
• Рефлексия и самоанализ. Ретроспектива, ревью, ответы на сложные вопросы.

Запишитесь на бесплатную консультацию. Определят ваш уровень языка, расскажут про обучение и ответят на все вопросы

Как исправить худший проект, на который только возможно попасть

Представьте, что вас нанимают навести порядок в проекте, который:

- Разрабатывался 12 лет без системы контроля версий
- Никогда не рефакторился, и никакая функциональность не удалялась
- Писался без каких-либо фреймворков, архитектуры и паттернов
- Представляет собой полный хаос с точки зрения кода, модели данных и инфраструктуры
- Зарабатывает 20 миллионов долларов в год

Автор статьи дает много хороших советов про то, как в такой ситуации можно поступить:

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

Еще больше обсуждений этой ситуации есть на HackerNews. И расскажите в комментариях про свои похожие истории и то, как вы из них выкарабкивались!

Примеры карьерных линеек разных компаний

К нам в Роадмап Тимлида прилетел отличный pull request с примерами карьерных линеек в разных компаниях. Если у вас появится похожая задача, сможете использовать как источник для вдохновения.

Кстати, начался Хактоберфест, так что с радостью примем больше ваших PR! 🎉

Deep dive в современные фронтенд фреймворки и решаемые ими проблемы

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

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

Исследование проблем начинающих тимлидов

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

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

И главное – двум случайным участникам опроса выдам бесплатные билеты на Podlodka Teamlead Crew, которая пройдет уже довольно скоро.

Постоянная борьба с пожарами – это плохо

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

Observability: monitoring, alerting, tracing

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

Новый сезон Techlead Crew как раз помогает тимлидам вкатиться в то, как предотвращать инциденты до того, как они случатся. Архитекторы и SRE из Booking, Авито, Bolt и Datadog проведут кучу воркшопов и докладов про то, как выстраивать систему мониторинга, выбирать правильные метрики, оценивать доступность и внедрять SRE практики.

Старт – в следующий понедельник, 17 октября. Можно и участвовать вживую, и смотреть записи сессий позже, если не успеваете прийти.

Подробная программа уже есть на сайте!

Затраты на синхронизацию в команде и способ их уменьшить

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