Teamlead Roadmap

Карта компетенций технического лидера, адаптируемая под различные организации. Roadmap состоит из двух основных частей: роли и обязанности (что делает тимлид) и личные навыки (как он это делает). Каждая компания расставляет акценты по-разному - где-то тимлид ближе к менеджеру проектов, где-то к техническому архитектору. Эта карта помогает определить свои зоны роста и выстроить план развития.

Источник

Карта основана на Teamlead Roadmap и дополнена практическими рекомендациями из опыта.

Роли и обязанности

Administrator

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

Построение цикла разработки

Разработка

Готовые подходы:

Lean
итеративная
Kanban - визуализация потока работы
XP (Extreme Programming) - инженерные практики
SAFe (Scaled Agile Framework) - масштабирование Agile

Подробнее: Agile методологии и фреймворки

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

Ключевые принципы:

Методология должна соответствовать ценностям команды
Чем проще работающая методология - тем лучше
Постепенное внедрение практик вместо единовременного навязывания
Автоматизация рутинных процессов для экономии времени коллег

Фазы внедрения:

Фаза	Действия
Подготовка	User Story документация, выбор инструментов, обсуждение с командой
Внедрение	Постепенная раскатка, уважение ко времени коллег, простота
Поддержка	Выделение времени на процессы, быстрое исправление ошибок

Антипаттерны:

Навязывание методологии сверху
Частая смена методологий
Cargo-cult ритуалы без понимания их цели
Несоответствие между ценностями команды и допущениями методологии

Пример: как внедрить code review в команду

Допустим, команда из 6 разработчиков работает без code review. Код попадает в main через прямые пуши. Внедрение сразу жёстких правил вызовет сопротивление.

Пошаговый план:

Неделя 1 - обсудить с командой, зачем нужен review. Показать реальные баги, которые могли бы быть пойманы. Не навязывать, а вовлечь в обсуждение

Неделя 2 - запустить в мягком режиме: review обязателен только для критичных модулей. Один аппрувер, время на review - до 4 часов

Неделя 3-4 - расширить на весь код. Написать короткий гайд: на что смотреть, как оставлять комментарии, что считать блокером

Месяц 2 - автоматизировать: настроить branch protection rules, линтеры на PR, шаблон описания PR

Ретроспектива - собрать обратную связь, скорректировать процесс

Результат: через 2 месяца команда воспринимает review как естественную часть работы, а не как навязанную бюрократию.

Ресурсы:

Получение задач

Процесс получения, анализа и приоритизации входящих задач. Включает фильтрацию запросов, оценку их важности и срочности, распределение по команде.

Пайплайн обработки задач:

Входящий запрос → Фильтрация → Декомпозиция → Оценка → Приоритизация → Backlog

Инструменты:

Jira, Linear, YouTrack - трекеры задач
Notion, Confluence - документация требований
Miro, FigJam - визуализация и декомпозиция

Техники приоритизации:

MoSCoW (Must, Should, Could, Won’t)
RICE (Reach, Impact, Confidence, Effort)
ICE (Impact, Confidence, Ease)
Weighted Shortest Job First (WSJF)

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

Практические шаги:

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

Формирование задач в трекере:

Задача попадает в трекер
Калибруем её приоритет
Подтверждаем необходимость
Стараемся держать фильтр пустым

Результат

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

Ресурсы:

Выпуск задач

Процесс завершения и выпуска выполненных задач.

Приёмка - проверка и принятие выполненной работы, соответствия требованиям и стандартам качества.

Чеклист приёмки:

Соответствие Definition of Done
Прохождение code review
Успешные автотесты
Документация обновлена
Демонстрация стейкхолдерам

Раскатка (Deployment) - развёртывание готового функционала в production.

Стратегии деплоя:

Стратегия	Описание	Риск
Blue-Green	Два идентичных окружения, переключение трафика	Низкий
Canary	Постепенное увеличение % пользователей	Низкий
Rolling	Последовательное обновление инстансов	Средний
Big Bang	Одновременное обновление всего	Высокий

Ресурсы:

Проектное управление

Методологии и подходы к управлению проектами для эффективного планирования, контроля и завершения проектов.

P3Express

Упрощённая методология управления проектами на основе PRINCE2, адаптированная для небольших и средних проектов. Фокус на практичности и минимизации бюрократии.

Ключевые элементы:

37 активностей, распределённых по 7 фазам
Адаптивность под размер проекта
Интеграция с Agile-практиками

Ресурсы:

PDCA

PDCA (Plan-Do-Check-Act) - цикл Деминга для непрерывного улучшения процессов.

    ┌─────────┐
    │  PLAN   │ → Определить цели и процессы
    └────┬────┘
         ↓
    ┌─────────┐
    │   DO    │ → Выполнить запланированное
    └────┬────┘
         ↓
    ┌─────────┐
    │  CHECK  │ → Проверить результаты
    └────┬────┘
         ↓
    ┌─────────┐
    │   ACT   │ → Скорректировать и стандартизировать
    └────┬────┘
         ↓
    (повторить)

Применение:

Улучшение процессов разработки
Решение повторяющихся проблем
Внедрение новых практик

Ресурсы:

PMBoK

PMBoK (Project Management Body of Knowledge) - свод знаний по управлению проектами от PMI.

10 областей знаний PMBoK:

Управление интеграцией
Управление содержанием
Управление расписанием
Управление стоимостью
Управление качеством
Управление ресурсами
Управление коммуникациями
Управление рисками
Управление закупками
Управление заинтересованными сторонами

Ресурсы:

Дополнительные фреймворки

OKR (Objectives and Key Results) - целеполагание
PRINCE2 - процессный подход к управлению проектами
Lean Six Sigma - устранение потерь и дефектов

Стейкхолдинг

Управление заинтересованными сторонами проекта.

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

Матрица стейкхолдеров (Influence/Interest Grid):

	Низкий интерес	Высокий интерес
Высокое влияние	Consultant (консультировать)	Partner (активно вовлекать)
Низкое влияние	Temporary Worker (минимум контакта)	Support (информировать)

Роли стейкхолдеров:

Роль	Влияние	Важность	Стратегия
Partner	Высокое	Высокая	Постоянное вовлечение, проактивность
Consultant	Высокое	Низкая	Консультации по ключевым решениям
Support	Низкое	Высокая	Регулярное информирование
Temporary Worker	Низкое	Низкая	Минимальное взаимодействие

Практики работы:

Уточнить свою роль с исполнителями проекта
Установить процессы взаимодействия (даты, критерии успеха)
Запрашивать обратную связь о своей работе
Периодически пересматривать роль при изменении контекста

Последствия плохой практики:

Снижение влияния на проект
Разочарование зависимых сторон
Избыточные переработки из-за поздно выявленных ожиданий

Ответственность и договорённости с руководством

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

Разное понимание важного - руководитель и тимлид по-разному видят приоритеты
Разное понимание областей ответственности - непонятно, кто за что отвечает
Оценка может казаться (или являться) необъективной

О чём нужно договориться:

Продукт и проекты: доставка задач в срок, важные проекты, ключевые метрики
Техническое: покрытие тестами, время ответа, технический долг
Люди и команда: тимбилдинг, bus-factor, обучение людей

Как договориться с руководством:

Назначить митинг
Подготовить важные показатели по нескольким проектам и определить, что нужно сделать в них
Обсудить с руководителем
Принять предложения руководителя
Зафиксировать
Повторять регулярно

Результат договорённостей

Есть список договорённостей и целей

Достижения стали измеримыми

Оценить результат становится проще

Нет рассинхрона с руководителем

Ресурсы:

Сбор и уточнение требований

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

Техники сбора требований:

User Story Mapping - визуализация пользовательского пути и декомпозиция на истории
Story Writing Workshop - совместная сессия команды и стейкхолдеров для написания историй
Impact Mapping - связь бизнес-целей с конкретными фичами через цепочку: цель, акторы, воздействие, deliverable
Example Mapping - структурирование требований через конкретные примеры поведения

Шаблон user story:

Как [роль], я хочу [действие], чтобы [ценность]

Пример: “Как покупатель, я хочу фильтровать товары по цене, чтобы быстрее находить подходящие варианты.”

Формат Acceptance Criteria (Given/When/Then):

Given: начальное состояние системы
When: действие пользователя
Then: ожидаемый результат

Пример: сбор требований для функции поиска

Задача - добавить поиск по каталогу товаров в интернет-магазине.

Провести Story Writing Workshop с продактом, дизайнером и 2 разработчиками (1.5 часа)

Результат - набор историй:

“Как покупатель, я хочу искать товары по названию, чтобы быстро найти нужный товар”

“Как покупатель, я хочу видеть подсказки при вводе, чтобы не печатать полное название”

“Как покупатель, я хочу видеть результаты с опечатками, чтобы не перенабирать запрос”

Example Mapping для истории с подсказками:

Given: пользователь на странице каталога

When: вводит “кросс”

Then: видит подсказки “кроссовки Nike”, “кроссовки Adidas” в выпадающем списке

Выявленные вопросы: сколько подсказок показывать? Нужна ли фильтрация подсказок по наличию? Какая задержка допустима?

Эти вопросы фиксируются и обсуждаются с продактом до начала разработки.

Integrator

Роль связующего звена между бизнесом и технической командой.

Знание бизнеса

Понимание бизнес-модели компании, источников дохода, ключевых метрик и стратегических целей.

Ключевые области:

Бизнес-модель и монетизация
Unit-экономика продукта
Ключевые метрики (North Star Metric, KPI)
Конкурентная среда

Ресурсы:

Структура компании

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

Важно знать:

Формальная и неформальная структура власти
Процессы эскалации
Ключевые decision makers
Зоны ответственности смежных команд

Ресурсы:

Корпоративная культура

Понимание ценностей, норм поведения и негласных правил организации.

Элементы культуры:

Ценности компании
Стиль коммуникации
Отношение к ошибкам
Work-life balance
Процессы признания и награждения

Ресурсы:

Пример: как разобраться в бизнесе за первый месяц

План на 30 дней для нового тимлида:

Неделя 1 - люди и контекст:

Провести 1-1 с каждым членом команды (30-45 мин): чем занимаются, что болит, чего ждут от нового лида

Встретиться с непосредственным руководителем: цели, ожидания, критерии успеха

Составить карту стейкхолдеров

Неделя 2 - продукт и процессы:

Пройти онбординг как пользователь продукта, записать все вопросы

Изучить текущие дашборды и метрики: что измеряется, какие тренды

Посидеть наблюдателем на всех регулярных встречах команды

Неделя 3 - бизнес и стратегия:

Встретиться с продакт-менеджером: roadmap, приоритеты, боли

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

Изучить бизнес-модель: откуда деньги, кто клиенты, какие unit-метрики

Неделя 4 - синтез и план:

Составить документ “что я понял за месяц” и обсудить его с руководителем

Определить 3 главные проблемы, которые можно решить в следующем квартале

Зафиксировать договорённости и начать регулярные синки

People Manager

Роль, отвечающая за развитие людей и команды.

Управление людьми

Административная работа

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

Инструменты:

HRIS системы (BambooHR, Workday)
Таблицы учёта рабочего времени
Календари команды

Ресурсы:

Административная работа

Делегирование

Передача полномочий и ответственности членам команды для развития сотрудников и освобождения времени руководителя.

Преимущества делегирования:

Для руководителя	Для сотрудника	Для команды
Освобождение времени	Возможности роста	Увеличение автономии
Развитие преемников	Расширение полномочий	Кросс-функциональность
Снижение bus factor	Карьерный рост	Меньше единых точек отказа

7 уровней делегирования (Jurgen Appelo):

Tell - принять решение и сообщить
Sell - принять решение и убедить
Consult - получить совет, затем решить
Agree - достичь консенсуса
Advise - дать совет, решение за сотрудником
Inquire - узнать о решении после факта
Delegate - полная передача полномочий

Практики:

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

Признаки плохого делегирования:

Критичные задачи не делегируются
Нет контроля выполнения
Несоответствие сложности задач и уровня сотрудника
Неясные дедлайны и критерии успеха
Перегрузка отдельных людей

Ресурсы:

Развитие

Содействие профессиональному и личностному росту сотрудников.

Инструменты развития:

Individual Development Plan (IDP)
Менторинг и коучинг
Ротация задач
Обучающие программы
Конференции и митапы

Модель 70-20-10:

70% - обучение через опыт (рабочие задачи)
20% - обучение через других (менторинг, обратная связь)
10% - формальное обучение (курсы, книги)

Ресурсы:

Обратная связь

Предоставление и получение фидбека для улучшения работы и развития сотрудников.

Типы обратной связи:

Тип	Частота	Своевременность	Полнота
Периодический	По циклам (1-on-1, ревью)	Средняя	Высокая
Непрерывный	В процессе работы	Высокая	Низкая
Ситуационный	По событиям	Контролируемая	Контролируемая

Модели обратной связи:

SBI (Situation-Behavior-Impact)
COIN (Context-Observation-Impact-Next steps)
Feedback Sandwich (позитив-критика-позитив) - спорная модель

Хорошие практики:

Получить разрешение перед предоставлением фидбека
Баланс конструктивной критики и позитива
Личная доставка в приватной беседе
Своевременность - сразу после наблюдения
Объяснение причин - почему поведение уместно/неуместно
Запрашивать фидбек о себе у коллег

Плохие практики:

Непрошеный фидбек
Только негативный или только позитивный
Отложенные письменные отчёты (спустя недели)

Ресурсы:

Увольнение

Процесс расставания с сотрудником - как инициированный компанией, так и добровольный уход.

Виды увольнений:

По инициативе работодателя (performance issues)
По инициативе сотрудника
По соглашению сторон

Процесс:

Документирование проблем с performance
Performance Improvement Plan (PIP)
Принятие решения
Exit interview
Передача дел
Offboarding

Ресурсы:

Найм

Профиль кандидата - описание идеального кандидата: hard skills, soft skills, опыт, культурное соответствие.

Компоненты профиля:

Технические требования (must have / nice to have)
Поведенческие компетенции
Культурный fit
Потенциал роста

Собеседования - процесс оценки кандидатов на соответствие профилю.

Типы интервью:

Скрининг (HR)
Техническое интервью
System Design (для senior+)
Поведенческое интервью (STAR method)
Cultural fit

STAR метод:

Situation - опишите ситуацию
Task - какая была задача
Action - что вы сделали
Result - каков результат

Практика проведения собеседований

Подготовка:

Создать scorecard - таблицу с критериями оценки и шкалой (1-5) для каждого навыка
Разделить требования на must-have и nice-to-have. Must-have - это фильтр, без которого кандидат не проходит
Подготовить вопросы заранее, одинаковые для всех кандидатов на одну позицию
Согласовать с командой, кто за какой блок отвечает

Структура интервью (60 мин):

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

Примеры поведенческих вопросов (STAR):

“Расскажите о ситуации, когда вам пришлось работать с трудным коллегой. Что вы сделали и чем это закончилось?”
“Опишите проект, которым вы гордитесь больше всего. Какова была ваша роль и какой результат?”
“Был ли случай, когда вы не согласились с решением команды? Как вы поступили?”
“Расскажите про ситуацию, когда что-то пошло не так на проде. Как вы действовали?”

Red flags при собеседовании:

Кандидат не может назвать конкретных примеров из опыта
Присваивает командные заслуги себе (“я сделал” вместо “мы сделали” на командных проектах)
Негативно отзывается о прошлых коллегах и руководителях
Не задаёт вопросов о команде и проекте
Ответы не совпадают при уточняющих вопросах

После интервью:

Каждый интервьюер заполняет scorecard независимо, до обсуждения с другими
Провести калибровочную встречу: сравнить оценки, обсудить расхождения
Принять решение в течение 2-3 дней
Дать кандидату развёрнутую обратную связь

Пример: найм middle backend-разработчика

Scorecard содержит 8 критериев: Go (must), SQL (must), проектирование API (must), тестирование (must), системное мышление (nice), коммуникация (nice), ownership (nice), культурный fit (nice).

На техническом интервью даём задачу на проектирование простого API (15 мин) и задачу на чтение и исправление кода с багом (10 мин). Оцениваем не только правильность, но и ход мышления, умение задавать уточняющие вопросы.

После интервью два интервьюера заполняют scorecard. Если оценки расходятся больше чем на 2 балла по любому must-have критерию - обсуждаем детально.

Onboarding - процесс адаптации нового сотрудника.

Чеклист онбординга:

Доступы к системам
Знакомство с командой
Buddy/mentor назначен
Первые задачи определены
30-60-90 plan составлен
Регулярные check-in встречи

Тестовый период - испытательный срок для оценки соответствия ожиданиям.

Практики:

Чёткие критерии успешного прохождения
Регулярная обратная связь
Промежуточные check-points
Финальная оценка с решением

Ресурсы:

Мотивация

Понимание и влияние на эмоциональное и психологическое состояние сотрудников.

Ключевые теории мотивации:

Теория	Автор	Суть
Пирамида потребностей	Maslow	5 уровней потребностей (физиология - самореализация)
Теория потребностей	McClelland	Достижение, принадлежность, власть
Двухфакторная	Herzberg	Гигиенические факторы vs мотиваторы
Drive	Pink	Автономия, мастерство, цель
Поток	Csikszentmihalyi	Баланс сложности и навыков

Модель Pink (Drive):

Autonomy - самостоятельность в принятии решений
Mastery - возможность развивать навыки
Purpose - понимание целей и смысла работы

Практические действия:

Конкурентная зарплата (+10-15% к рынку)
Полугодовые пересмотры компенсации
Публичное признание и спонтанные награды
Усложнение задач с ростом автономии

Инструменты оценки мотивации:

10K Test
Motivation Maps
Stay Interviews

Спектр вовлечённости:

Disengagement → External motivation → Internal motivation → Flow

Подъём настроения в команде

Быстрые победы:

Публичная похвала на общем созвоне за конкретный вклад
Неожиданные бонусы: дополнительный выходной, подарочная карта, мерч
Team lunch или совместный поход после успешного релиза
Записка в чат с благодарностью конкретному человеку за конкретную вещь

В стрессовые периоды:

Признать сложность ситуации открыто, не делать вид, что всё нормально
Сократить scope - убрать всё, что не критично для дедлайна
Защитить команду от внешних отвлечений: взять на себя коммуникацию со стейкхолдерами
Быть рядом - приходить на стендапы, спрашивать “чем помочь?”, а не “когда будет готово?”

Командные активности:

Hackathons - день или два на любой проект, который интересен
Tech talks - внутренние доклады по 15-20 минут, без подготовки презентаций
Game nights - настолки, квизы, совместные онлайн-игры
Learning Fridays - пятничные часы на обучение и эксперименты

Работа с выгоранием:

Заметить вовремя: снижение инициативы, цинизм, частые отгулы
Обсудить на 1-1 без давления
Предложить конкретную помощь: отпуск, смена задач, снижение нагрузки
Разнообразие задач - чередование рутины с интересными проектами

5 фраз, которые поднимают боевой дух

“Спасибо, что взял на себя эту задачу - без тебя мы бы не уложились”

“Я вижу, как ты вырос за последние месяцы”

“Твоё решение по [конкретная ситуация] было правильным, хорошо, что ты так поступил”

“Я ценю, что ты не побоялся поднять эту проблему”

“Давай я возьму на себя [рутинная задача], а ты сфокусируйся на [интересная задача]”

Ресурсы:

One-on-one

Регулярные приватные встречи руководителя с каждым членом команды.

One-on-one - регулярные приватные беседы между менеджером и его прямым подчинённым для построения доверия, обсуждения производительности и выравнивания целей.

Преимущества:

Для сотрудника	Для руководителя
Гарантированное время для обсуждения	Глубокое понимание мотивации
Обсуждение сложных вопросов	Раннее выявление проблем
Чувство внимания	Равномерное внимание всем

Последствия игнорирования:

Ухудшение доверия
Коммуникация только по операционным вопросам
Сложности с performance management
Ощущение фаворитизма

Правило 10/90: руководитель говорит 10%, слушает 90%.

Перед встречей:

Записывать то, что хочешь донести до 1-1 - мысли забываются, а записи остаются
Освежать память: просмотреть заметки с прошлой встречи, проверить статус договорённостей

Во время встречи:

Начинать нужно с подчинённого. Мы лучше знаем и понимаем, как должен вестись диалог и какие вопросы мы хотим задать, поэтому первой темой должен стать человек
Нужно больше обсуждать то, что нужно человеку, а не только рабочие задачи
Фиксировать результаты - action items с ответственными и сроками

Что ещё важно:

Настроить периодичность встреч - чаще чем раз в месяц
Не усложнять (не нужно фиксировать абсолютно всё)
Длительность - постараться сделать не больше часа в месяц на всех человек суммарно на подготовку

Внедрение процесса:

Создать профили сотрудников (мотивация, договорённости, достижения)
Запланировать регулярные встречи
Установить правила: частота, длительность, место, формат
Подготовить список открытых вопросов

Улучшение процесса:

Просить сотрудника готовить агенду заранее
Вести детальные записи встреч
Регулярно проверять актуальность карточки сотрудника
Собирать фидбек об эффективности встреч

Признаки плохих 1-on-1:

Нерегулярные встречи
Обсуждение только тривиальных тем
Односложные ответы сотрудника
Повторяющиеся обсуждения без прогресса
Незафиксированные договорённости
Частые отмены
Отсутствие исторической преемственности

Ресурсы:

Промо

Ассессмент - оценка компетенций сотрудника для принятия решений о повышении.

Методы оценки:

360-degree feedback
Performance review
Competency assessment
Self-assessment

Карьерная линейка - система грейдов и уровней в организации.

Типичные уровни для разработчиков:

Junior → Middle → Senior → Staff → Principal → Distinguished
                    ↓
              → Tech Lead → Engineering Manager → Director

Компоненты карьерной линейки:

Описание уровней
Критерии перехода
Ожидания по компетенциям
Процесс продвижения

Ресурсы:

Управление командой

Управление компетенциями

Отслеживание и развитие навыков команды.

Инструменты:

Skills Matrix
Competency Framework
Knowledge Map

Skills Matrix:

Навык	Alice	Bob	Carol
React	3	2	1
Node.js	2	3	2
PostgreSQL	1	2	3

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

Карточка содержит:

Навыки (неполная RACIS карта) - добавить список необходимых навыков для проектов, описать уровни владения (критерии оценки должны быть определимыми), проставить уровни владения каждым членом команды

План развития - к определённому времени, какую область ответственности должен закрывать, маркеры и доказанный опыт

Заметки с 1-1 встреч

Результат

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

Ресурсы:

Управление компетенциями

Климат в команде

Эмоциональное состояние команды и коллективная субъективная оценка ежедневной работы.

Влияние на:

Метрики производительности
Удовлетворённость работой
Эмоциональное благополучие членов команды

Последствия игнорирования:

Негативный фон усиливает все негативные явления
Конфликты эскалируются вместо разрешения
Уходы провоцируют дополнительные увольнения
Команда не может восстановиться без вмешательства

Методы оценки:

Интервью
Опросы (Team Health Check)
Ретроспективы
eNPS (Employee Net Promoter Score)

Практические действия для улучшения климата:

Проводить ретроспективы не только по процессам, но и по настроению команды
Реагировать на конфликты сразу, не дожидаясь эскалации
Создать безопасное пространство для обратной связи - человек не должен бояться говорить о проблемах
Отмечать успехи команды публично, ошибки обсуждать приватно
Следить за равномерностью нагрузки - перегруз одних при простое других разрушает климат
Регулярно спрашивать на 1-1: “Как тебе сейчас работается в команде? Что бы ты изменил?”

Инструменты:

Spotify Team Health Check
Officevibe, Culture Amp - платформы для опросов

Ресурсы:

Дизайн команды

Формирование оптимальной структуры и состава команды.

Факторы:

Размер команды (оптимально 5-9 человек)
Баланс компетенций
Team Topologies (Stream-aligned, Platform, Enabling, Complicated-subsystem)

Ресурсы:

Запуск команды

Формирование новой команды или перезапуск существующей.

Модель Tuckman:

Forming → Storming → Norming → Performing → Adjourning

Практики:

Team Charter
Working Agreements
Definition of Done
Kick-off meeting

Ресурсы:

Зрелость команды

Оценка и развитие уровня самоорганизации команды.

Уровни зрелости:

Directing - руководитель принимает все решения
Coaching - руководитель объясняет решения
Supporting - совместные решения
Delegating - команда принимает решения

Ресурсы:

Обеспечение прозрачности

Создание среды открытой коммуникации и видимости работы.

Практики:

Визуализация работы (Kanban board)
Регулярные статус-апдейты
Открытые каналы коммуникации
Документирование решений

Ресурсы:

Обеспечение прозрачности

Организация рабочего пространства

Создание комфортной физической и виртуальной среды для работы.

Факторы:

Физическое пространство (офис, удалёнка, гибрид)
Инструменты коммуникации
Доступ к информации
Эргономика

Ресурсы:

Организация рабочего пространства

Развитие технического бренда

Позиционирование команды и компании как технологического лидера.

Направления:

Tech-блог
Участие в конференциях
Open Source контрибуции
Митапы
Подкасты

Ресурсы:

Развитие технического бренда

Product Owner

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

Принятие продуктовых решений

Целеполагание

Определение целей продукта и команды на разных горизонтах планирования.

Фреймворки целеполагания:

OKR (Objectives & Key Results) - связка вдохновляющих целей с измеримыми результатами
SMART goals - конкретные, измеримые, достижимые, релевантные, ограниченные по времени
North Star Metric - единая метрика, отражающая ценность продукта для пользователей

OKR структура:

Objective: Качественная цель (вдохновляющая, амбициозная)
├── Key Result 1: Измеримый результат
├── Key Result 2: Измеримый результат
└── Key Result 3: Измеримый результат

OKR каскадируются от уровня компании к командам. Objective описывает куда идём, Key Results показывают как узнаем, что дошли. Хороший KR всегда содержит число и срок. Обычно ставят 3-5 KR на один Objective, оптимальный уровень достижения - 60-70% (если 100% - цель была недостаточно амбициозной).

Разница между OKR и KPI

KPI измеряет текущую эффективность процесса (процент uptime, conversion rate). OKR задаёт направление изменений и амбициозные цели. KPI отвечает на вопрос “как мы работаем сейчас”, OKR - “куда мы хотим прийти”.

Ресурсы:

Управление продуктовым бэклогом

Генерация элементов бэклога

Источники идей для бэклога:

Пользовательские исследования - интервью, опросы, наблюдения
Обратная связь клиентов - support-тикеты, NPS-комментарии, отзывы
Анализ конкурентов - что делают другие, какие тренды на рынке
Внутренние идеи команды - предложения разработчиков, дизайнеров, QA
Технические потребности - рефакторинг, обновление зависимостей, устранение долга
Аналитика продукта - воронки, retention, поведение пользователей

Приоритизация бэклога

Техники приоритизации:

Метод	Суть	Когда использовать
RICE	Количественная оценка по четырём параметрам	Когда нужна объективность и данные
ICE	Упрощённый RICE, быстрая оценка	Ранняя фаза, много идей
MoSCoW	Категоризация Must/Should/Could/Won’t	Фиксированный скоуп
Value vs Effort	Матрица 2x2	Визуальная приоритизация на встрече
Kano Model	Классификация по влиянию на удовлетворённость	Продуктовые решения
WSJF	Cost of Delay / Duration	SAFe, поток задач

RICE формула:

RICE Score = (Reach × Impact × Confidence) / Effort

Ресурсы:

Продуктовая стратегия

Долгосрочное видение развития продукта. Иерархия стратегических элементов:

Vision → Mission → Strategy → Roadmap → Tactics

Vision
картина
Mission - зачем продукт существует, какую проблему решает
Strategy - как именно достичь Vision, ключевые ставки и trade-offs
Roadmap - план реализации стратегии, последовательность шагов
Tactics - конкретные действия и эксперименты на ближайший период

Хорошая стратегия содержит явный выбор - от чего отказываемся не менее важно, чем что делаем. Стратегия без trade-offs - это просто список желаний.

Ресурсы:

Управление роадмапом

Визуализация и планирование развития продукта.

Типы роадмапов:

Тип	Описание	Плюсы	Минусы
Feature-based	Список конкретных фич с датами	Понятен стейкхолдерам	Фиксирует решения заранее
Goal-based (Now-Next-Later)	Группировка по целям и горизонтам	Гибкость, фокус на outcomes	Менее конкретен
Theme-based	Группировка по стратегическим темам	Связь со стратегией	Может быть размытым
Timeline-based	Привязка к конкретным датам	Предсказуемость	Давление сроков

Для большинства продуктовых команд формат Now-Next-Later работает лучше всего - он даёт достаточно конкретики для ближайших задач и гибкость для долгосрочных планов.

Инструменты:

ProductPlan, Aha!, Roadmunk
Notion, Miro
Google Sheets

Ресурсы:

Управление продуктом

Жизненный цикл фичей

Управление фичами от идеи до вывода из эксплуатации.

Стадии жизненного цикла:

Ideation → Discovery → Definition → Development → Launch → Growth → Maturity → Decline

На каждой стадии свои ключевые активности:

Ideation - генерация и сбор идей, первичная фильтрация
Discovery - исследование проблемы, валидация гипотезы, прототипирование
Definition - детализация требований, PRD, дизайн, оценка
Development - разработка, тестирование, итерации
Launch - выпуск, мониторинг, сбор обратной связи
Growth - оптимизация, масштабирование, A/B тесты
Maturity - поддержка, минимальные улучшения
Decline - решение о sunset, миграция пользователей, вывод из эксплуатации

Большинство идей не должны доходить до Development

Цель Discovery - дешёво проверить гипотезу и отсеять идеи, которые не решают реальных проблем. Чем раньше отброшена плохая идея, тем меньше ресурсов потрачено впустую.

Ресурсы:

Жизненный цикл фичей

Запуск продукта

Вывод продукта или фичи на рынок.

Компоненты запуска:

Go-to-market strategy - определение целевой аудитории, каналов, позиционирования
Launch checklist - технические и организационные задачи перед релизом
Communication plan - кто, когда и как узнает о запуске (внутри и снаружи)
Success metrics - какие метрики измеряем и какие значения считаем успехом
Rollback plan - при каких условиях откатываем и как

Пример launch checklist:

Feature flags настроены
Мониторинг и алерты на месте
Документация обновлена
Support-команда проинструктирована
Communication plan согласован
Success metrics определены и baseline зафиксирован
Rollback plan протестирован

Ресурсы:

Понимание продукта

Знание рынка

Понимание конкурентной среды и рыночных трендов.

Методы исследования рынка:

Competitive analysis - систематический анализ конкурентов, их стратегий, сильных и слабых сторон
Market research - качественные и количественные исследования рынка
Trend analysis - отслеживание технологических и бизнес-трендов
TAM/SAM/SOM - оценка размера рынка на трёх уровнях

TAM/SAM/SOM:

TAM (Total Addressable Market)    - весь потенциальный рынок
 └── SAM (Serviceable Available)  - часть, которую можем обслужить
      └── SOM (Serviceable Obtainable) - реалистичная доля

Ресурсы:

Знание рынка

Знание продукта

Глубокое понимание своего продукта на всех уровнях.

Области знания:

Функциональность - что продукт умеет, пользовательские сценарии, edge cases
Архитектура - как устроен продукт изнутри, основные компоненты и зависимости
Ограничения - технические и бизнес-ограничения, что продукт не умеет и почему
Метрики - ключевые показатели продукта, текущие значения, тренды
Roadmap - куда продукт движется, какие решения уже приняты

Тимлид в роли PO должен уметь ответить на вопрос “почему продукт работает именно так” - как с технической, так и с бизнес-стороны.

Ресурсы:

Знание продукта

Знание пользователей

Понимание потребностей и поведения пользователей.

Методы исследований:

User interviews - глубинные интервью для понимания мотивации и проблем
Surveys - количественные опросы для валидации гипотез на большой выборке
Usability testing - наблюдение за тем, как пользователи взаимодействуют с продуктом
Analytics analysis - анализ данных о поведении пользователей в продукте
A/B testing - контролируемые эксперименты для сравнения вариантов

Инструменты:

Hotjar, FullStory - сессионные записи и heatmaps
Amplitude, Mixpanel - продуктовая аналитика
UserTesting - удалённое тестирование юзабилити

Ресурсы:

Работа с требованиями на стороне продукта

Практический процесс превращения бизнес-потребности в конкретные требования для команды.

Ключевые артефакты:

PRD (Product Requirements Document) - описание проблемы, целей, метрик успеха и высокоуровневого решения
User Stories - описание потребности с точки зрения пользователя
Acceptance Criteria - условия, при которых работа считается выполненной
Wireframes/Prototypes - визуальное представление решения

Процесс discovery для новой фичи:

Пример: как провести discovery для новой фичи

Собрать данные - аналитика, обращения пользователей, конкурентный анализ

Провести user interviews (минимум 5 пользователей)

Сформулировать гипотезу: “Если мы сделаем X, то метрика Y вырастет на Z%”

Построить прототип и провести usability test

Написать PRD (Product Requirements Document)

Частые ошибки при работе с требованиями:

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

Technical Lead

Роль, отвечающая за техническое качество, архитектуру и технологическую стратегию команды.

Связанные материалы в репозитории:

Архитектура - обзор архитектурных подходов
SOLID принципы - принципы объектно-ориентированного дизайна
System Design - проектирование систем
Чистый код - практики написания качественного кода
DevOps - автоматизация и инфраструктура
CD - непрерывная интеграция и доставка

Архитектура

Проектирование и поддержка архитектуры системы.

Архитектурное ревью

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

Виды ревью:

Design Review (до реализации) - обсуждение подхода до начала написания кода
Architecture Decision Records (ADR) - документирование принятых решений и их контекста
Post-implementation review - анализ реализации после завершения, сравнение с планом

ADR структура:

# ADR-001: Название решения
 
## Статус
Принято / Отклонено / Заменено
 
## Контекст
Какая проблема решается?
 
## Решение
Что решили сделать?
 
## Последствия
Плюсы, минусы, риски

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

Ресурсы:

Проектирование

Создание архитектуры системы с учётом требований, ограничений и долгосрочных целей.

Архитектурные паттерны:

Monolith - единое приложение, простой деплой, сложное масштабирование
Микросервисы - распределённая архитектура, независимый деплой сервисов
Event-Driven - асинхронное взаимодействие через события
CQRS - разделение чтения и записи
Hexagonal (Ports & Adapters) - изоляция бизнес-логики от инфраструктуры
Clean Architecture - слоистая архитектура с правилом зависимостей
MV-паттерны - MVC, MVP, MVVM
FSD - Feature-Sliced Design

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

Ресурсы:

Проектирование
Software Architecture
System Design Primer
Fundamentals of Software Architecture
Внутренние: System Design, Архитектура

Эволюция

Постепенное развитие архитектуры без нарушения работы системы.

Практики эволюционной архитектуры:

Strangler Fig Pattern - постепенная замена legacy-компонентов новыми, запросы перенаправляются по мере готовности
Feature Toggles - переключатели для включения/выключения функциональности без деплоя
Database Migrations - управляемые изменения схемы данных с поддержкой отката
API Versioning - совместимость со старыми клиентами при развитии API
Blue-Green Deployments - два идентичных окружения для безопасного переключения

Эволюция архитектуры требует дисциплины: каждое изменение должно быть обратно совместимым, либо иметь чёткий план миграции. “Большой переезд” почти всегда проигрывает постепенной трансформации.

Ресурсы:

Сбор технических требований

Выявление и документирование нефункциональных требований (NFR).

Категории NFR:

Категория	Примеры метрик	Вопросы
Performance	Latency p95 < 200ms, throughput > 1000 rps	Какое время отклика приемлемо?
Scalability	Горизонтальное/вертикальное масштабирование	До какой нагрузки должна расти система?
Availability	Uptime 99.9%, RTO < 1h, RPO < 15min	Какой downtime допустим?
Security	Authentication, authorization, encryption	Какие данные обрабатываем? Какие стандарты?
Maintainability	Code coverage, documentation, onboarding time	Как быстро новый разработчик начнёт вносить изменения?
Observability	Metrics, logs, traces coverage	Сможем ли мы диагностировать проблему в production?

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

Ресурсы:

Техлидство на практике

Принятие архитектурных решений в команде

Архитектурные решения не должны приниматься в одиночку. Эффективные техлиды используют процесс RFC (Request for Comments):

Автор описывает проблему и предлагаемое решение в документе
Команда обсуждает, задаёт вопросы, предлагает альтернативы
После обсуждения техлид фиксирует решение в ADR

RFC не заменяет решения - он обогащает его. Финальная ответственность за решение остаётся за техлидом.

Баланс между идеальной архитектурой и сроками

Вопрос не в том, как сделать идеально, а в том, что достаточно хорошо для текущего этапа. Практические ориентиры:

Если проект в фазе Discovery - максимальная скорость, минимум абстракций
Если продукт растёт и набирает пользователей - инвестиции в архитектуру окупятся
Если дедлайн жёсткий - фиксируем технический долг как задачу, не делаем вид что его нет

Когда вмешиваться в код команды

Вмешательство оправдано когда:

Решение создаёт серьёзный технический долг или нарушает security
Архитектурный паттерн противоречит принятым ADR
Ошибка повлияет на другие команды или системы

Свобода уместна когда:

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

Как проводить design review

Чеклист вопросов для design review:

Какую проблему решаем? Кто пользователь?
Какие альтернативы рассматривались и почему отвергнуты?
Как решение масштабируется? Что если нагрузка вырастет в 10 раз?
Какие failure modes? Что произойдёт при падении зависимости?
Как будем мониторить? Какие алерты нужны?
Как будем откатывать, если что-то пойдёт не так?
Есть ли влияние на другие сервисы/команды?

Пример: design review для нового API

Команда проектирует REST API для корзины e-commerce. Вопросы на ревью:

Идемпотентность: что произойдёт при повторном добавлении товара? Нужен ли Idempotency-Key?

Конкурентный доступ: два запроса одновременно меняют корзину - как обрабатываем? Optimistic locking?

Консистентность: цена товара изменилась после добавления в корзину - когда пересчитываем?

Лимиты: максимальное количество товаров в корзине, максимальная сумма, rate limiting

TTL: корзина живёт вечно или истекает? Как уведомляем пользователя?

API contract: используем вложенные ресурсы /carts/{id}/items или flat /cart-items?

Обратная совместимость: если потом добавим промокоды - сломает ли это текущий контракт?

Автоматизация цикла разработки

Настройка автоматизированных процессов для повышения скорости и качества.

Continuous Integration

Практика частой интеграции кода с автоматическими проверками.

CI Pipeline:

Commit → Build → Test → Static Analysis → Artifact

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

Инструменты:

GitHub Actions, GitLab CI - интегрированные с VCS
Jenkins, TeamCity - self-hosted, гибкая настройка
CircleCI, Travis CI - облачные решения

Ресурсы:

Автоматизация релизов

Настройка автоматизированного процесса развёртывания.

CD Pipeline:

Artifact → Deploy to Staging → Integration Tests → Deploy to Production → Smoke Tests

Практики:

Infrastructure as Code (Terraform, Pulumi) - инфраструктура описана кодом, версионирована
GitOps (ArgoCD, Flux) - desired state хранится в Git, автоматическая синхронизация
Feature Flags - управление функциональностью без деплоя
Canary Releases - постепенное увеличение процента пользователей на новой версии
Blue-Green Deployments - мгновенное переключение между версиями

Инструменты:

ArgoCD, Spinnaker
Kubernetes, Docker
Terraform, Ansible

Ресурсы:

Работа с системами контроля версий

Организация работы с Git и branching strategies.

Branching Strategies:

Стратегия	Описание	Подходит для
Git Flow	Отдельные ветки для фич, релизов и хотфиксов	Продукты с версионированием
GitHub Flow	Одна main ветка + feature branches	Веб-приложения, частые деплои
Trunk-Based	Короткоживущие ветки, частый мерж в main	Команды с сильным CI
GitLab Flow	Environment-ветки (staging, production)	Несколько окружений

Trunk-Based Development требует зрелого CI и практики feature flags, но даёт минимальный merge pain и быструю обратную связь.

Ресурсы:

Работа с системами контроля версий
Git Flow
Trunk-Based Development
Внутренние: Git, GitFlow, GitHub Actions, Conventional Commits

Capacity Management

Управление мощностью команды: планирование загрузки, оценка ресурсов.

Метрики:

Velocity - количество Story Points, которое команда закрывает за спринт (среднее за 3-5 спринтов)
Capacity - доступные человеко-часы с учётом отпусков, митингов, поддержки
Cycle Time - время от начала работы над задачей до её завершения
Lead Time - время от создания задачи до её завершения (включая ожидание)

Sprint Planning с учётом capacity:

Определить доступность каждого члена команды (отпуска, обучение, on-call)
Вычесть время на митинги, код-ревью, поддержку (обычно 20-30%)
Зарезервировать буфер на незапланированную работу (15-20%)
Оставшийся capacity заполнить задачами из бэклога

Velocity - не метрика продуктивности

Velocity показывает пропускную способность команды для планирования. Попытки “увеличить velocity” приводят к инфляции оценок, а не к реальному ускорению. Сравнивать velocity разных команд бессмысленно.

Ресурсы:

Управление знаниями

Техническая документация

Создание и поддержка документации.

Типы документации:

Тип	Аудитория	Содержание
API Documentation (OpenAPI, Swagger)	Потребители API	Endpoints, параметры, примеры запросов
Architecture Documentation (C4 Model)	Разработчики, техлиды	Контексты, контейнеры, компоненты, код
README, Getting Started	Новые разработчики	Быстрый старт, настройка окружения
Runbooks	On-call инженеры	Диагностика и решение инцидентов
ADR	Вся команда	Решения и их контекст

Инструменты:

Confluence, Notion - wiki-системы
MkDocs, Docusaurus - документация как код
Swagger, Redoc - API-документация из OpenAPI спецификации

Документация ценна только если она актуальна. Лучше иметь краткий и точный README, чем подробную документацию полугодовой давности.

Ресурсы:

Распространение знаний

Обеспечение передачи знаний внутри команды.

Практики:

Практика	Формат	Эффект
Tech Talks	Презентация 20-40 мин	Широкое распространение знаний
Pair Programming	Совместная работа в паре	Глубокое обучение, контекст
Code Review	Асинхронный анализ кода	Стандарты, обнаружение проблем
Brown Bag Sessions	Неформальная презентация за обедом	Культура обмена знаниями
Internal Wiki	База знаний команды	Асинхронный доступ к информации
Mob Programming	Вся команда работает над одной задачей	Выравнивание понимания, сложные задачи

Ресурсы:

Распространение знаний

Обеспечение качества продукта

Работа с багами

Процесс обработки и устранения дефектов.

Жизненный цикл бага:

Reported → Triaged → In Progress → Fixed → Verified → Closed

Приоритизация:

P0 (Critical) - блокирует работу, потеря данных, security breach. Реакция немедленная
P1 (High) - серьёзное влияние на ключевой функционал. Фикс в текущем спринте
P2 (Medium) - умеренное влияние, есть workaround. Планируется в бэклог
P3 (Low) - минимальное влияние, косметические дефекты. По возможности

Ресурсы:

Работа с багами

Code Review

Проверка кода для обеспечения качества и распространения знаний.

Преимущества:

Обнаружение багов
Выявление архитектурных проблем
Стандартизация кода
Распространение знаний
Обратная связь для разработчиков

Хорошие практики:

Категория	Практика
Процесс	Чёткие критерии pass/fail, атомарные MR
Коммуникация	Вопросы вместо критики, похвала, приоритизация фидбека
Автоматизация	Линтеры, автотесты, интеграция с мессенджерами
Скорость	Быстрый отклик (в идеале в тот же день)

Структура ревью:

Понять бизнес-логику
Оценить архитектурные решения
Проверить детали реализации

Плохие практики:

Неясная ответственность
Отсутствие метрик успеха
Задержки с фидбеком
Токсичная коммуникация (сарказм, личные выпады)

Примеры тактичного общения в code review

Instead of: “Это неправильно” Better: “Я бы предложил другой подход - что если мы используем X? Вот почему…”

Instead of: “Зачем ты так сделал?” Better: “Интересный подход. Помоги мне понять логику - какие альтернативы ты рассматривал?”

Instead of: “Перепиши всё” Better: “Основная логика хорошая. Давай обсудим пару моментов, которые можно улучшить”

Ресурсы:

Управление инцидентами

Минимизация негативного влияния от неожиданных сбоев.

Классификация инцидентов:

Minor - минимальное влияние, не затрагивает ключевой функционал
Major - значительное влияние, требует координации ресурсов
Critical - критическое влияние на бизнес, требует эскалации
Security - инциденты безопасности (отдельный процесс, уведомление заинтересованных сторон)

Ключевые практики:

Практика	Описание
Документирование	Обязательная запись инцидентов с деталями решения
Приоритизация	Ранжирование по влиянию на бизнес
Коммуникация	Поддержание записей о конфигурационном влиянии
Постмортемы	Анализ без обвинений (blameless post-mortem)

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

Blameless post-mortem фокусируется на процессах, а не на людях. Вопросы “как наши системы допустили эту ситуацию” вместо “кто виноват”. Цель - предотвращение повторения, а не наказание.

Инструменты:

PagerDuty, Opsgenie - on-call ротация и алертинг
Statuspage - коммуникация о статусе для пользователей
Jira Service Management - управление тикетами инцидентов

Ресурсы:

Метрики и мониторинг

Сбор, анализ и визуализация метрик работы системы.

Типы метрик:

Методология	Метрики	Применение
Golden Signals	Latency, Traffic, Errors, Saturation	Универсальный подход от Google SRE
RED	Rate, Errors, Duration	Сервисы, обрабатывающие запросы
USE	Utilization, Saturation, Errors	Ресурсы (CPU, память, диск)

Observability Stack:

Metrics: Prometheus, Datadog - числовые показатели системы
Logs: ELK Stack, Loki - текстовые записи событий
Traces: Jaeger, Zipkin - прослеживание пути запроса через систему
Visualization: Grafana - дашборды и визуализация

Три столпа observability (metrics, logs, traces) дополняют друг друга. Метрики показывают что происходит, логи - почему, трейсы - где именно.

Ресурсы:

Нефункциональные требования

Обеспечение соответствия NFR.

Категории:

Performance - время отклика, пропускная способность
Scalability - способность обрабатывать растущую нагрузку
Availability - процент времени доступности сервиса
Security - защита данных и доступа
Maintainability - простота поддержки и развития

Ресурсы:

Нефункциональные требования

Тестирование

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

Нефункциональное тестирование

Тестирование характеристик системы: производительность, нагрузка, безопасность.

Виды:

Performance Testing - измерение времени отклика под нормальной нагрузкой
Load Testing - поведение под ожидаемой пиковой нагрузкой
Stress Testing - поведение при превышении лимитов
Security Testing - поиск уязвимостей
Chaos Engineering - внесение контролируемых сбоев для проверки устойчивости

Инструменты:

JMeter, Gatling, k6 - нагрузочное тестирование
OWASP ZAP - security testing
Chaos Monkey - chaos engineering

Ресурсы:

Пирамида тестирования

        /\
       /  \        E2E Tests (few)
      /----\
     /      \      Integration Tests (some)
    /--------\
   /          \    Unit Tests (many)
  /------------\

Автоматизация тестирования API

Создание автоматизированных тестов для REST, GraphQL API.

Инструменты:

Postman, Newman
REST Assured
Karate
pytest + requests

Ресурсы:

Автоматизация тестирования GUI

Автоматизация тестирования пользовательского интерфейса.

Инструменты:

Playwright
Cypress
Selenium
Puppeteer

Ресурсы:

Unit-тестирование

Тестирование отдельных модулей кода.

Best Practices:

Один assert на тест
AAA паттерн (Arrange-Act-Assert)
Изоляция (mocks, stubs)
Fast, Independent, Repeatable

Ресурсы:

Дополнительные ресурсы по тестированию:

Знание технологий

Написание кода

Способность писать production-ready код.

Ожидания от техлида:

Понимание кодовой базы на уровне, достаточном для ревью и диагностики
Способность закрыть критичные задачи, когда команда не справляется
Пример для команды по качеству кода и подходам
Эффективное code review с фокусом на архитектуру

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

Ресурсы:

Написание кода

Выбор и контроль технологий

Принятие решений о технологическом стеке.

Факторы выбора:

Зрелость технологии - стабильность API, наличие LTS версий, track record в production
Сообщество и экосистема - библиотеки, плагины, ответы на Stack Overflow, активность разработки
Команда и экспертиза - текущие навыки команды, доступность специалистов на рынке
Performance requirements - соответствие нефункциональным требованиям проекта
Total Cost of Ownership - лицензии, инфраструктура, обучение, поддержка

Принцип выбора технологий

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

Ресурсы:

Знание технологического стека команды

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

Ресурсы:

Знание технологического стека команды

Обеспечение технического качества

Чистый код

Написание понятного, поддерживаемого кода.

Принципы:

SOLID - пять принципов объектно-ориентированного дизайна
DRY (Don’t Repeat Yourself) - устранение дублирования логики
KISS (Keep It Simple, Stupid) - простейшее решение, удовлетворяющее требованиям
YAGNI (You Aren’t Gonna Need It) - не реализовывать функциональность, пока она не нужна

Эти принципы иногда противоречат друг другу. DRY может конфликтовать с KISS, когда абстракция для устранения дублирования усложняет код. В таких случаях предпочитайте читаемость.

Ресурсы:

Чистый код
Clean Code (Robert Martin)
Внутренние: Чистый Код - Роберт Мартин, SOLID принципы

Рефакторинг

Улучшение структуры кода без изменения поведения.

Техники:

Extract Method/Class - выделение логически связанного кода в отдельный метод или класс
Rename - переименование для лучшего отражения назначения
Move Method - перемещение метода в класс, к которому он логически относится
Replace Conditional with Polymorphism - замена условной логики полиморфизмом

Рефакторинг безопасен только при наличии тестов. Правило: сначала покрываем тестами, потом рефакторим. Без тестов это не рефакторинг, а переписывание с непредсказуемыми последствиями.

Ресурсы:

Управление техническим долгом

Непрерывное выявление, оценка стоимости и устранение технического долга.

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

Последствия игнорирования:

Рост времени разработки и поддержки
Сложность анализа кода
Хрупкость системы
В крайнем случае - необходимость полного переписывания

Практики управления:

Практика	Описание
Code Review	Детальная оценка качества при разработке
Статический анализ	SonarQube и подобные инструменты
Внешний аудит	Объективная оценка третьей стороной
Sprint allocation	Процент спринта на работу с долгом (обычно 15-20%)
Непрерывный мониторинг	Ручные и автоматические проверки

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

Инструменты:

SonarQube, SonarCloud
Code Climate
Codacy

Ресурсы:

Личные навыки

Личные навыки (soft skills) критически важны для тимлида - они определяют способность эффективно взаимодействовать с командой, стейкхолдерами и влиять на результаты. Технические знания помогают понять, что нужно делать, а личные навыки - как добиться того, чтобы это действительно произошло.

Связанные материалы:

DISC модель - понимание типов личности
Структура IT-команды - командная динамика

Коммуникации

Коммуникация - основной инструмент тимлида. Качество коммуникации напрямую влияет на эффективность команды, скорость решения проблем и общий климат.

Управление коммуникационной нагрузкой

Тимлид постоянно сталкивается с проблемой переключения контекста. После каждой смены контекста требуется 5-20 минут на вникание, а старые задачи теряются - нарушаются договорённости и фокус на важном.

Решение - уменьшать трафик:

делегируя часть на кого-то

переопределяя на что-то

Оптимизация каналов:

Почта (Zero Inbox) - удалить спам, ненужное в архив, важное + срочное - реагировать сразу, важное + несрочное - планировать через todo и напоминалки

Мессенджеры - уведомлять только по личным сообщениям, удалять ненужные комнаты, DnD, push-уведомления

Встречи - напоминалки за день (подготовить материал), за час (ничего не планировать), за 5 минут (подготовить аппаратуру)

Помним про матрицу Эйзенхауэра - если меньше отвлекаемся, не пропускаем важное и вовремя реагируем, то это успех.

Коучинг

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

Когда применять:

Развитие сотрудников
Помощь в принятии решений
Преодоление препятствий
Карьерное планирование

Модель GROW:

G (Goal) - цель
R (Reality) - текущая ситуация
O (Options) - варианты действий
W (Will) - план действий

Ресурсы:

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

Навыки разрешения и предотвращения конфликтов. Конфликты неизбежны в любой команде - важно уметь управлять ими конструктивно.

Стратегии (Thomas-Kilmann):

Стратегия	Описание	Когда применять
Competing	Отстаивание своей позиции	Кризис, срочные решения
Collaborating	Поиск win-win решения	Важные вопросы, есть время
Compromising	Частичные уступки обеих сторон	Равные силы, среднее решение
Avoiding	Уход от конфликта	Незначительные вопросы
Accommodating	Уступка другой стороне	Отношения важнее результата

Признаки деструктивного конфликта:

Переход на личности
Эскалация вместо разрешения
Снижение продуктивности
Формирование “лагерей”

Практики разрешения:

Выслушать обе стороны отдельно
Определить корневую причину
Найти общие интересы
Выработать решение вместе
Зафиксировать договорённости

Ресурсы:

Сотрудничество

Навыки эффективной работы с другими людьми. Включает кросс-функциональное взаимодействие, работу с другими командами и отделами.

Принципы эффективного сотрудничества:

Общие цели важнее локальных
Прозрачность и открытость
Взаимное уважение
Своевременная коммуникация
Готовность помочь

Барьеры сотрудничества:

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

Практики улучшения:

Регулярные синки между командами
Общие ретроспективы
Ротация сотрудников
Совместные OKR

Связанные темы:

Масштабирование Agile

Ресурсы:

Сотрудничество

Фасилитация

Управление групповой дискуссией для достижения целей встречи. Фасилитатор нейтрален по отношению к содержанию и фокусируется на процессе.

Роль фасилитатора:

Управление временем
Вовлечение всех участников
Фиксация решений
Предотвращение доминирования
Разрешение тупиковых ситуаций

Техники:

Техника	Описание	Когда применять
Brainstorming	Генерация идей без критики	Поиск решений
Dot Voting	Голосование точками	Приоритизация
Silent Writing	Тихая запись идей	Включение интровертов
Round Robin	Высказывание по кругу	Равное участие
Fishbowl	Внутренний и внешний круг	Сложные обсуждения
1-2-4-All	Индивидуально → пары → группы	Консенсус

Типичные встречи для фасилитации:

Ретроспективы
Planning sessions
Design workshops
Brainstorming
Decision-making meetings

Ресурсы:

Фасилитация
Liberating Structures
Retromat - форматы ретроспектив

Дача и получение обратной связи

Навыки предоставления и принятия фидбека. Регулярная обратная связь - основа развития команды.

Модель Radical Candor:

              Высокая забота о человеке
                        │
    Ruinous Empathy     │     Radical Candor ★
    (не говорите        │     (говорите прямо
     неприятное)        │      с заботой)
                        │
────────────────────────┼────────────────────────
                        │
    Manipulative        │     Obnoxious Aggression
    Insincerity         │     (агрессивная критика
    (политкорректность) │      без заботы)
                        │
              Низкая забота о человеке

    ← Низкая прямота         Высокая прямота →

Формула эффективного фидбека (SBI):

S (Situation) - конкретная ситуация
B (Behavior) - наблюдаемое поведение
I (Impact) - влияние на результат

Пример:

“На вчерашнем standup (S), когда ты перебил коллегу (B), это создало напряжённую атмосферу и он не договорил свою мысль (I).”

Получение фидбека:

Слушать без защиты
Задавать уточняющие вопросы
Благодарить за фидбек
Рефлексировать и действовать

Ресурсы:

Тактичное общение

Умение доносить сложные вещи так, чтобы человек услышал суть, а не защищался. Тактичность - это не мягкость, а точность коммуникации.

Примеры тактичного общения в разных ситуациях

Ситуация: сотрудник не выполнил задачу в срок Плохо: “Ты опять не успел. Это неприемлемо.” Хорошо: “Я заметил, что задача не закрыта к дедлайну. Давай разберёмся - что помешало? Может, я могу чем-то помочь?”

Ситуация: нужно отклонить идею коллеги Плохо: “Эта идея не сработает.” Хорошо: “Интересный подход. Меня беспокоит вот этот аспект - как ты видишь решение проблемы X? Может, мы можем адаптировать идею?”

Ситуация: конфликт между двумя разработчиками Плохо: “Разберитесь сами.” Хорошо: “Я вижу, что у вас разные взгляды на решение. Давайте обсудим это втроём - я хочу услышать аргументы обеих сторон.”

Ситуация: нужно дать негативный фидбек Плохо: “Твой код ужасен.” Хорошо: “В этом PR есть хорошая основная идея. Давай обсудим несколько мест, где мы можем улучшить читаемость и покрытие тестами.”

Принцип: Assume positive intent

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

Нетворкинг

Построение и поддержание профессиональных связей. Нетворк - один из главных активов тимлида.

Почему важен нетворкинг:

Найм талантов (рефералы)
Обмен опытом и практиками
Карьерные возможности
Решение сложных проблем
Видение индустрии

Практики:

Участие в митапах и конференциях
Активность в профессиональных сообществах
Менторинг и коучинг
Регулярные coffee-чаты
Ведение блога / канала

Инструменты:

LinkedIn
Telegram-чаты
Discord/Slack сообщества
Twitter/X

Ресурсы:

Личный бренд

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

Каналы:

Технический блог
Социальные сети (LinkedIn, Twitter)
Выступления на конференциях
Open Source контрибуции
Подкасты и видео
Книги и статьи

Стратегия развития бренда:

Определить нишу/экспертизу
Выбрать 1-2 основных канала
Регулярно создавать контент
Взаимодействовать с аудиторией
Измерять и корректировать

Метрики:

Подписчики и охват
Входящие запросы (найм, выступления)
Цитируемость
Узнаваемость в сообществе

Ресурсы:

Публичные выступления

Навыки презентации и выступлений - важный инструмент влияния для тимлида.

Типы выступлений:

Внутренние презентации (команда, стейкхолдеры)
Tech Talks (компания)
Митапы (сообщество)
Конференции (индустрия)
Подкасты и интервью

Структура выступления:

Hook - привлечь внимание
Problem - обозначить проблему
Solution - предложить решение
Proof - доказательства (данные, примеры)
Call to Action - призыв к действию

Практики подготовки:

Репетиции вслух
Запись и просмотр себя
Фидбек от коллег
Постепенное усложнение (митапы → конференции)

Типичные ошибки:

Слишком много контента
Чтение со слайдов
Отсутствие историй и примеров
Игнорирование аудитории

Ресурсы:

Работа с текстом

Навыки письменной коммуникации. В распределённых командах текст - основной способ коммуникации.

Области применения:

Техническая документация
Emails и письма
Slack/Teams сообщения
RFC и Design Docs
ADR (Architecture Decision Records)
README и onboarding

Принципы эффективного письма:

Ясность - одна мысль = одно предложение
Краткость - убирать лишнее
Структура - заголовки, списки, выделения
Контекст - reader-first mindset
Actionability - чёткие следующие шаги

Шаблон RFC:

# RFC: Название предложения
 
## Статус
Draft / Under Review / Accepted / Rejected
 
## Контекст
Какую проблему решаем?
 
## Предложение
Что предлагаем сделать?
 
## Альтернативы
Какие варианты рассматривали?
 
## Последствия
Плюсы, минусы, риски

Ресурсы:

Стили менеджмента

Различные подходы к управлению командой.

Основные стили:

Стиль	Описание	Когда применять
Авторитарный	Руководитель принимает все решения	Кризис, новая команда
Демократический	Совместное принятие решений	Зрелая команда
Делегирующий	Передача полномочий команде	Высокая зрелость команды
Ситуационный	Адаптация под контекст	Всегда актуален

Ресурсы:

Отношения

Понимание ценности различий

Навыки работы с разнообразной командой (diversity & inclusion). Разнообразие команды коррелирует с инновационностью и бизнес-результатами.

Измерения разнообразия:

Демографическое (пол, возраст, национальность)
Когнитивное (стиль мышления, образование)
Функциональное (роли, экспертиза)
Личностное (интроверты/экстраверты)

Преимущества разнообразных команд:

Больше перспектив и идей
Лучшее понимание пользователей
Снижение группового мышления
Привлечение талантов

Практики:

Inclusive hiring practices
Awareness training
Psychological safety
Активное включение всех голосов
Адаптация коммуникации

Связанные модели:

DISC - понимание разных типов личности

Ресурсы:

Эмоциональный интеллект

Способность распознавать и управлять эмоциями - своими и других людей. EQ часто важнее IQ для лидеров.

Компоненты (Goleman):

Компонент	Описание	Как развивать
Self-awareness	Понимание своих эмоций	Journaling, медитация, фидбек
Self-regulation	Управление эмоциями	Пауза перед реакцией, дыхание
Motivation	Внутренняя мотивация	Цели, смысл работы
Empathy	Понимание эмоций других	Активное слушание, наблюдение
Social skills	Управление отношениями	Практика, networking

Признаки высокого EQ:

Способность сохранять спокойствие под давлением
Понимание невербальных сигналов
Адаптация стиля общения под собеседника
Конструктивная реакция на критику
Способность вдохновлять и мотивировать

Связанные модели:

DISC - типы личности

Ресурсы:

Развитие себя

Непрерывное развитие - ключевой навык для тимлида. Технологии и практики меняются, и лидер должен расти вместе с ними.

Систематизация своего развития

Приёмы для упрощения саморазвития:

выделить время для развития

завести карточку навыков на себя

уточнить у руководителя, что стоит подтянуть

пройти курсы, добавить больше каналов информации

периодически спрашивать себя: как я вырос?

Полезный ресурс для оценки компетенций: teamlead roadmap

Работа с привычками

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

Модели:

Atomic Habits (James Clear):

Привычка = Сигнал → Желание → Действие → Награда
1% improvement daily = 37x за год
Системы важнее целей
Identity-based habits

Habit Loop (Charles Duhigg):

Cue → Routine → Reward
Изменение routine при сохранении cue и reward

Полезные привычки тимлида:

Утренний обзор приоритетов
Регулярные 1-on-1
Weekly review
Чтение/обучение
Физическая активность

Техника внедрения:

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

Ресурсы:

Умение учиться

Навыки эффективного обучения. Meta-skill, который усиливает все остальные навыки.

Техники:

Техника	Описание	Когда применять
Spaced Repetition	Повторение с интервалами	Запоминание фактов
Active Recall	Активное вспоминание	Изучение концепций
Feynman Technique	Объяснение простыми словами	Глубокое понимание
Deliberate Practice	Целенаправленная практика	Навыки
Learning in Public	Публичное обучение	Мотивация, фидбек

Feynman Technique:

Выбрать концепцию
Объяснить простыми словами (как ребёнку)
Выявить пробелы в понимании
Вернуться к источнику и упростить

Пирамида обучения (retention rates):

Лекция            5%
Чтение           10%
Аудио/Видео      20%
Демонстрация     30%
Обсуждение       50%
Практика         75%
Обучение других  90%

Практики для тимлида:

Регулярное чтение (книги, статьи)
Участие в конференциях
Обучение команды (усиливает своё понимание)
Эксперименты и pet-projects
Ведение заметок (Obsidian, Notion)

Ресурсы:

Рефлексия

Анализ своих действий и решений. Рефлексия превращает опыт в обучение.

Почему важно:

Извлечение уроков из опыта
Выявление паттернов поведения
Корректировка курса
Предотвращение повторных ошибок

Практики:

Практика	Частота	Описание
Journaling	Ежедневно	Запись мыслей и наблюдений
Weekly Review	Еженедельно	Анализ недели, планирование
Monthly Retrospective	Ежемесячно	Глубокий анализ месяца
Quarterly Goals Review	Ежеквартально	Оценка прогресса по целям
Annual Review	Ежегодно	Анализ года, планирование следующего

Вопросы для рефлексии:

Что прошло хорошо? Почему?
Что можно было сделать лучше?
Что я узнал?
Что я буду делать по-другому?
Какие паттерны я замечаю?

Weekly Review (шаблон):

## Неделя [дата]
 
### Достижения
- ...
 
### Вызовы
- ...
 
### Уроки
- ...
 
### Фокус на следующую неделю
- ...

Ресурсы:

Мышление

Принятие решений

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

Процесс принятия решений:

Идентификация и понимание проблемы
Определение целей
Сбор информации и генерация альтернатив
Оценка альтернатив по критериям
Конвертация субъективных оценок в числовые значения
Установление порогов отсечения
Реализация с итеративным пересмотром

Фреймворки:

Decision Matrix
PDCA (Deming-Shewhart Cycle)
Theory of Constraints
TRIZ (теория решения изобретательских задач)

Хорошие практики:

Рассматривать несколько вариантов одновременно
Использовать проверенные практики из других команд/индустрий
Быстрые интуитивные решения для простых проблем
Post-mortem анализ для улучшения будущих решений
Баланс аналитической строгости и затраченных ресурсов

Антипаттерны:

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

Ресурсы:

Стратегическое видение

Способность видеть долгосрочную перспективу и принимать решения с учётом будущего.

Компоненты стратегического мышления:

Анализ трендов и рынка
Понимание бизнес-целей
Видение технического развития
Оценка рисков и возможностей
Планирование на 1-3-5 лет

Инструменты стратегического планирования:

SWOT-анализ
Porter’s Five Forces
Technology Radar
Scenario Planning
OKR для долгосрочных целей

Практики развития:

Чтение индустриальных отчётов
Участие в конференциях
Networking с лидерами индустрии
Анализ конкурентов
Обсуждение стратегии с руководством

Ресурсы:

Тайм-менеджмент

Навыки эффективного управления временем.

Постановка личных целей

Определение и формулирование личных и профессиональных целей.

Методологии:

SMART - Specific, Measurable, Achievable, Relevant, Time-bound
OKR - Objectives and Key Results

Ресурсы:

Управление приоритетами

Умение различать срочное и важное.

Техники:

Матрица Эйзенхауэра:

	Срочно	Не срочно
Важно	Делать сейчас	Планировать
Не важно	Делегировать	Отказаться

MoSCoW
Must
Eat the Frog - начинать с самой сложной задачи

Ресурсы:

Управление временем

Техники для эффективного использования времени.

Методы:

Pomodoro - 25 минут работы, 5 минут отдыха
Time Blocking - выделение блоков времени под задачи
GTD (Getting Things Done) - система управления задачами
Weekly Review - еженедельный обзор и планирование

Инструменты:

Todoist, Things 3, OmniFocus
Calendly, Cal.com
RescueTime, Toggl

Ресурсы:

Книги и ресурсы

Base

Проводник

Teamlead

Teamlead Roadmap

Роли и обязанности

Administrator

Построение цикла разработки

Разработка

Получение задач

Выпуск задач

Проектное управление

P3Express

PDCA

PMBoK

Дополнительные фреймворки

Стейкхолдинг

Ответственность и договорённости с руководством

Сбор и уточнение требований

Integrator

Знание бизнеса

Структура компании

Корпоративная культура

People Manager

Управление людьми

Административная работа

Делегирование

Развитие

Обратная связь

Увольнение

Найм

Практика проведения собеседований

Мотивация

Подъём настроения в команде

One-on-one

Промо

Управление командой

Управление компетенциями

Климат в команде

Дизайн команды

Запуск команды

Зрелость команды

Обеспечение прозрачности

Организация рабочего пространства

Развитие технического бренда

Product Owner

Принятие продуктовых решений

Целеполагание

Управление продуктовым бэклогом

Продуктовая стратегия

Управление роадмапом

Управление продуктом

Жизненный цикл фичей

Запуск продукта

Понимание продукта

Знание рынка

Знание продукта

Знание пользователей

Работа с требованиями на стороне продукта

Technical Lead

Архитектура

Архитектурное ревью

Проектирование

Эволюция

Сбор технических требований

Техлидство на практике

Принятие архитектурных решений в команде

Баланс между идеальной архитектурой и сроками

Когда вмешиваться в код команды

Как проводить design review

Автоматизация цикла разработки

Continuous Integration

Автоматизация релизов

Работа с системами контроля версий

Capacity Management

Управление знаниями

Техническая документация

Распространение знаний

Обеспечение качества продукта

Работа с багами

Code Review