Лидерство

• Ведущий разработчик отвечает за свой код
• Руководитель команды отвечает за качество кода всей команды
• Ведущий разработчик решает технические задачи сам
• Руководитель команды создаёт среду, в которой команда решает задачи лучше

• Успех измеряется не личной продуктивностью, а результатами команды
• Скорость работы зависит от умения распределять задачи, а не от личной скорости
• Влияние строится через доверие и технический авторитет, а не через статус
• Придётся работать с неопределённостью и принимать решения при неполных данных

💡 Помните: Самая частая ошибка нового руководителя — продолжать работать как ведущий разработчик, только с дополнительными обязанностями. Роль требует сознательного переключения мышления.

Быстрый справочник

• Руководитель команды: твой результат — это результат команды, а не твой личный код
• Первые 90 дней: слушай больше, чем говоришь; не меняй процессы сразу
• Распределение задач ≠ устранение от ответственности: ставишь задачу → согласуешь подход → контролируешь ключевые этапы
• Архитектурные решения: организуй обсуждение, не диктуй ответ
• Технический авторитет поддерживается совместным программированием, проверкой кода, предложениями по архитектуре — не должностью
• Индивидуальные встречи — твой главный инструмент, а не опциональная встреча
• Наставничество начинающим: научи ловить рыбу, а не дай готовую

• Определяет технический стек и ключевые паттерны
• Документирует решения через записи об архитектурных решениях
• Оценивает технические риски и компромиссы
• Убеждается, что команда понимает «почему», а не только «что»

• Выявляет и определяет приоритеты технического долга
• Отстаивает время на улучшение кода перед руководством
• Не допускает накопления критического долга в угоду скорости

# ЗАПИСЬ-001: Выбор ORM для проекта
## Статус: Принято
## Контекст: Нужна ORM для работы с PostgreSQL
## Решение: SQLAlchemy
## Последствия: +гибкость, -сложность миграций
## Отвергнутые варианты: Django ORM (нет Flask), Tortoise ORM (малая экосистема)

• Объяснять «почему», а не только указывать «что не так»
• Выделять уровень комментария: замечание (мелочь), предложение (рекомендация), блокировка (обязательно к исправлению)
• Хвалить хорошие решения — это закрепляет правильное поведение
• Не переписывать чужой код при проверке, а направлять автора

[предложение] Здесь можно использовать генератор списка вместо цикла:
result = [process(item) for item in items if item.is_valid()]
Это читаемее и в 2 раза быстрее для больших списков. Но оставляю на твоё усмотрение.

• Время проверки: не более 24 часов для обычных запросов на слияние
• Размер запроса: не более 400 строк изменений
• Плотность комментариев: не более 10–15 на запрос

• Индивидуальные встречи: 30 минут раз в 1–2 недели, фокус на росте
• Совместное программирование: совместная работа над сложными задачами
• Проверка кода как наставничество: комментарии объясняют принципы
• Технические доклады: внутренние выступления по технологиям

• Понимать цели каждого члена команды
• Давать задачи, которые развивают нужные навыки
• Создавать возможности для роста: выступления, технические задачи

• Говорить на языке бизнеса: риски, сроки, стоимость, ценность
• Избегать технического жаргона без объяснений
• Всегда приходить с вариантами, а не только с проблемами
• Управлять ожиданиями заранее, а не в момент срыва сроков

Плохо: «Это технически невозможно»
Хорошо: «Сделать X к пятнице мы не успеем, но есть два варианта:
  1. Базовая версия с основным функционалом — готова в пятницу
  2. Полная версия — через 2 недели
  Какой приоритет важнее для бизнеса?»

• Финальные решения по архитектуре с высоким риском
• Сложные технические переговоры с заинтересованными сторонами
• Разговоры о серьёзных проблемах с производительностью
• Задачи, где скрыта высокая неопределённость и нет права на ошибку

• Команда может работать без руководителя 2–3 дня без потери продуктивности
• Руководитель не является единственным проверяющим всего кода
• Руководитель успевает писать код и не только устранять проблемы
• Команда принимает технические решения самостоятельно в знакомых областях

• Проектирование систем: создание масштабируемых систем
• Проверка кода: оценка качества, безопасности, производительности
• Отладка: быстрое нахождение и устранение проблем
• Оценка сроков: реалистичное планирование сроков и рисков

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

• Провести индивидуальные встречи с каждым: «расскажи что работает, что не работает, что тебя радует в работе»
• Наблюдать за командными ритуалами, не менять их
• Писать код наравне со всеми — устанавливать доверие через компетентность

• Определить одну острую проблемную точку команды (не твою) и решить её
• Наладить регулярные индивидуальные встречи (раз в 2 недели минимум)
• Проверить и устранить один технический риск

• Предложить ретроспективу (не приказать — предложить): «Хочу попробовать 30 минут раз в 2 недели, окей?»
• Первое архитектурное решение — через предложение по архитектуре, а не монолог
• Выявить карьерные цели каждого на индивидуальных встречах

• Сформулировать техническую стратегию на 6 месяцев (вместе с командой)
• Провести первый разговор о результатах работы, если есть явная проблема
• Отпраздновать первый командный успех публично

1. Сколько часов идёт на написание кода?
2. Сколько на проверку кода?
3. Сколько на встречи с заинтересованными сторонами?
4. Сколько на индивидуальные встречи и наставничество?
5. Сравните результат с рекомендуемым балансом. Что нужно изменить?

1. Какие задачи в команде может сделать только руководитель?
2. Что случится, если руководитель уйдёт в отпуск на 2 недели?
3. Какие из этих зависимостей можно устранить за 1–2 цикла разработки?
4. Составьте план распределения задач для 3 ключевых зависимостей.