Культура разработки Tinkoff.ru
Переход от монопродукта к экосистеме глазами тимлида
Содержание слайдов
1. Культура разработки Tinkoff.ru
Переход от монопродукта к экосистеме глазами тимлида
2. Александр Поломодов
Руководитель разработки в привлечении Tinkoff.ru
МФТИ, продуктовые и медийные команды.
С 2016 — привлечение Tinkoff.ru.
Публичный веб, контент, каналы.
Рост: 10 → 120 технических специалистов.
3. О чем этот доклад
От роста компании к практическим зонам ответственности тимлида
Контур привлечения Tinkoff.ru.
От монопродукта к экосистеме.
Модель: что / как / кем.
Где тимлид действует напрямую.
4. Что входило в привлечение
Весь путь от интереса до заявки
Публичный веб — Страницы, формы, витрины и заявки.
Контент и каналы — CMS для веба и мобильных, трафик.
Персонализация и тесты — Релевантные продукты и гипотезы на трафике.
5. Tinkoff.ru вырос в экосистему
Каждый новый продукт создает новую нагрузку на привлечение, контент и процесс
6. Вертикали держатся на ИТ-платформе
Чтобы запуск новых направлений был повторяемым, нужны общие процессы и технический фундамент
7. Рост держится на трех опорах
Три грани: что делаем, как делаем и какой командой
8. Тимлид меняет систему изнутри контура
Стратегию важно понимать, но основные изменения тимлид делает внутри своего контура
9. 01. Что мы делаем
Стратегия, продуктовый подход, бизнес-процессы и требования
10. Стратегию нужно уметь объяснить на пальцах
Тимлид обязан понимать среду команды
Стратегия простыми словами?
Рост, доля, устойчивость?
CEO выступает перед сотрудниками?
Есть время думать вперед?
11. Система — тоже продукт
Оргструктура по типам команд.
Как выбираются проекты.
Разработка внутри бизнес-вертикалей.
Внутренние системы — продукты для других команд.
12. Разработка редко самоцель
Обычно команда автоматизирует бизнес-процесс, и качество видно по этому процессу
Какие процессы автоматизируем?
Кто держит документацию актуальной?
Где остались ручные операции?
Какие метрики общедоступны?
13. Требования — зона прямого влияния
Качество разработки начинается не с кода, а с качества входа
Аудит слабых мест бэклога.
Шаблоны задачи и бага.
Фиксация решений после встреч.
Критерии глубины документации.
14. 02. Как мы делаем
Процессы разработки, архитектура, тестирование и инфраструктура
15. Процесс живет по привычке
Без процесса рост быстро превращается в шум
Нет выстроенного процесса.
Нет прозрачности внутри команд.
Нет метрик и практики улучшений.
Нет владельца развития процесса.
16. Процесс подгоняют под цели бизнеса
Сначала понять текущую систему, потом менять ее под контекст
Аудит ролей и ответственности.
Зачем выбран этот процесс?
Связь с целями бизнеса.
Состав команды и ограничения релиза.
17. Архитектура — не факультатив
Прототип, который внезапно стал production, быстро превращается в дорогую систему
Система без бизнес-плана.
Опасный legacy: система растет.
Долг без технической дорожной карты.
Архитекторов не хватает.
18. Архитектуру спасает дорожная карта
Тимлид может превратить архитектуру из реакции в план
Аудит архитектуры проектов.
Дорожная карта с TCO и бизнес-планами.
RnD отдельно от production.
Найм с проверкой архитектурного мышления.
19. Скорость зависит от тестирования
Качество нельзя оставлять в конце
Код сейчас, тесты потом.
Разработка и QA перебрасывают задачи.
Ручное тестирование и автотесты отдельно.
Слабый QA ломает систему.
20. QA подключается до кода
Качество нужно проектировать вместе с системой
Кто тестирует и когда.
QA до основной разработки.
Архитектура под unit/component/e2e.
Качество как инженерная роль.
21. Убрать барьер между dev и ops
Инфраструктура — часть контура поставки команды
Аудит эксплуатации систем.
Понимание поведения в production.
Ops на старте проекта.
Общий pipeline, разделенная ответственность.
22. 03. Кем мы делаем
Кого мы нанимаем, как вводим в дело и как растим
23. Люди и среда — тоже система
Участие в найме.
Адаптация без потери людей.
Обучение и развитие команды.
Ежедневная поддержка и исключения.
24. Найм продаёт позицию и команду
Нужно выделяться среди конкурентов
Вакансия как обещание работы.
Зачем существует команда.
Рост вместе с системой.
Делегирование подсистем и ответственности.
25. Адаптация защищает результат найма
Сложно найденный человек должен быстро понять контекст и почувствовать опору
Карта продукта и команды.
Правила решений и договоренностей.
Наставник и первые задачи.
Включенность в культуру команды.
26. Тимлид состоялся, если люди растут
Культура разработки проявляется в ежедневных мелочах
Рост, а не удержание уровня.
Технические и процессные препятствия.
Доступы, коммуникации, ожидания.
Конфликты, переходы, увольнения.
27. Что забрать с собой
Культура разработки — управляемая система
Культура — фундамент роста.
Стыки отделов становятся болью.
Тимлид влияет инициативой.
Рост требует системы, не героизма.
Что / Как / Кем
28. Ссылки и материалы
Исходная презентация и модели для тимлида
Managing Humans + Principles: Life and Work
Рост команды на порядок.
Найм и мотивация в привлечении.
Software Process — Omar Elgabry.
29. Спасибо!
polomodov.tech
Все слайды и ссылки — в Telegram-канале
Александр Поломодов, Руководитель разработки, Tinkoff.ru
@book_cube