Содержание слайдов

1. 1. SOLID'ный тимлид

   Основы менеджмента для технарей

2. 2. Технарь, который заходит в менеджмент

   Для кого доклад

   Вы — крутой технарь

   Вы — новичок в менеджменте

   Уже стали или готовитесь стать тимлидом

   Хотите преуспеть в новой роли

3. 3. 01. Команда

   Кто и как доводит идею до результата

4. 4. Команда закрывает цикл от идеи до финансового результата

   Современная кросс-функциональная команда разработки

   Роли: Analyst, Data Scientist, System Engineer

   …QA engineer, Developer, Infosec engineer

   Цикл: идея → требования → проектирование → разработка

   …deploy → эксплуатация → финансовые результаты

5. 5. Задача тимлида — сделать команду идеальной

   Идеальная команда заказчика

   Бизнес-заказчик приносит идею

   Обратно он ждёт финансовые результаты

   Между ними — одна «команда разработки»

   Тимлид отвечает за то, чтобы она была идеальной

6. 6. Начнём решать её через четыре знакомых слова

   Принципы ООП

   Абстракция — только то, что важно снаружи

   Инкапсуляция — детали спрятаны внутри

   Наследование — общая форма переиспользуется

   Полиморфизм — один интерфейс, разные реализации

7. 7. Команда — это объект, а тимлид — её интерфейс

   Те же четыре слова, применённые к команде

   Абстракция: заказчик видит команду, а не шесть ролей

   Инкапсуляция: между ним и командой стоит тимлид

   Наследование: та же форма команды под каждую идею

   Полиморфизм: три команды — три реализации интерфейса

8. 8. Разработчик — тоже объект, и он взаимозаменяем

   Те же четыре слова, применённые к роли

   Абстракция: требования → обязанности

   Инкапсуляция: важен результат, а не как написан код

   Наследование: Junior → Middle → Senior

   Полиморфизм: взаимозаменяемость на уровне

9. 9. 02. SOLID

   Пять принципов — и пять управленческих практик

10. 10. Каждый принцип звучит дважды

    Сначала для кода, потом для команды

11. 11. У команды одна цель и все ресурсы для неё внутри

    Пример: от общей IT-команды к feature-командам

    В коде: у класса единственное назначение

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

    Было: общая IT-команда с общей приоритизацией

    Стало: feature-команда на заказчика плюс платформенные

12. 12. Уровни расширяют контракт, а не переписывают его

    Пример: матрица компетенций QA

    В коде: открыт для расширения, закрыт для модификации

    В команде: это про матрицы компетенций

    Базу фиксируем на младшем специалисте

    Каждый следующий уровень расширяет контракт

13. 13. Одно название роли — один контракт

    Пример: архитектор, в которого ведут две лестницы

    В коде: наследник взаимозаменяем с родителем

    В команде: взаимозаменяемы все, начиная с тимлида

    Проблема: в Architect ведут разработка и аналитика

    Решение: Software Architect и Solution Architect

14. 14. Тимлид — интерфейс команды, но не единственный канал

    Пример: разделение интерфейсов и meeting notes

    В коде: много узких интерфейсов лучше одного общего

    В команде: наружу выставлен один интерфейс — тимлид

    Нельзя завязывать на него все активности

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

15. 15. Потоком управляют принципы, а не тимлид пошагово

    Пример: микроменеджмент против здорового менеджмента

    В коде: зависимость на абстракциях

    Важнее IoC: потоком управляет фреймворк

    Микроменеджмент: тимлид объясняет каждый шаг

    Здоровый вариант: сначала принципы, потом задача

16. 16. 03. Итоги

    Что забрать с собой

17. 17. Пять принципов — пять управленческих решений

    Менеджерская половина SOLID

    S: у команды одна цель и все ресурсы для неё внутри

    O: матрица компетенций фиксирует базу и расширяет контракт

    L: чёткие требования к уровням дают взаимозаменяемость

    I: тимлид — интерфейс команды, а не её единственный канал

    D: принципы вместо микроменеджмента

    «В сущности, все модели неправильны, но некоторые полезны» — Джордж Бокс

18. 18. Что почитать

    Источники знаний из финального слайда доклада

    Статья «SOLID'ный тимлид, или основы менеджмента для технарей»

    Статья «Принципы SRP и IoC в мире менеджмента разработки ПО»

    Статья «Подходы оркестровки и хореографии в мире менеджмента разработки ПО»

    Доклады «Современные подходы к разработке софта» и «Как мы принимаем архитектурные решения»

19. 19. Спасибо!

    polomodov.tech

    Все слайды и ссылки — в Telegram-канале

    Александр Поломодов, Technical Director & Fellow, Т-Технологии

    @book_cube