Антон Поваров, Badoo
- Как появляется инфраструктурная команда
- Путь инфраструктурной команды
- Как выбирать важное?
- Разработка
- Пиар важен
- Цикл работы инфраструктурной команды
- Всё растёт. Больше пользователей и нагрузки.
- Бизнес хочет ещё больше.
- Инфраструктурные задачи бизнесу непонятны, но необходимы для развития.
Примеры:
- Шардинг, масштабирование
- Visibility: логи, метрики, визуализация
- Второй ДЦ
- ...
Нужна отдельная инфраструктурная команда, которая будет это поддерживать.
Направления:
- Продуктовые бэкенды. C/C++/Go.
- Инфраструктурные сервисы
- скриптовое облако
- очереди
- фотографии
- миграция данных между ДЦ
- mobile API gateway
- Инструменты разработчика
- метрики: хранение и визуализация
- деплой PHP-кода
- сборки и модули для PHP и nginx
- тестирование: soft mocks
- unified data system (UDS)
над которой не стоит стейкхолдер из бизнеса и не требует задач.
Есть задачи:
- от бизнеса
- от продуктовых команд
- развивать инфраструктуру
Полезность команды растёт.
Потом становится так:
- от бизнеса — но зачем, это же фичи?
- от продуктовых команд — некогда нам?
- развивать инфраструктуру!!!
Полезность команды падает. Приуныли.
Нужна коммуникация и баланс между развитием платформы и конкретными фичами для бизнеса.
Важна культура.
- горизонтальные связи
- фокус на результате
- постоянный инженерный фидбэк
Воронка рождения проекта:
- Источники: собрать боль и хотелки. Делаем максимально широкую воронку. Сами идём к разработчикам и ищем боль. Устраиваем формат AMA (ask me anything) — в назначенное время в переговорке отвечаем на все вопросы.
- Вовлечение: найти заказчика. Слушаем, вовлекаем, предлагаем решения, формируем видение.
- Бизнес-цели: какую задачу решаем? Могут быть про продукт, про time to market, про оптимизацию работы или страховку «от метеорита». Бизнес-цели имеют нетехнические критерии оценки и меняют технический проект.
- Ready to dev: инженерный проект и ресурсы. Важный вопрос здесь — что НЕ делать? Помним о принципе YAGNI. Понять, что критично, и построить именно это.
- Приоритеты. Делаем сквозную приоритизацию всех проектов. Сверяемся с командами, которые делают фичи.
- проекты долгие
- высокая цена ошибки
- нельзя просто «написать код»
- внедрение часто сложное
- хорошее качество должно быть сразу (а в разработке фич не так; можно сделать как-то, а потом допилить, если выстрелит)
Кто делает? Разработчик
- проводит kick off
- формирует технический план
- ведёт проект
- отвечает за результат
Любой проект режется на этапы. Каждый этап:
- что именно будет сделано?
- сроки: когда на бою?
- длительность — 1-2 недели
- выкладываем на прод
- стараемся анонсировать, что получилось
- проекты долгие
- изменения часто невидимы «by design» пользователям и даже разработчикам.
поэтому:
- собираем фидбэк
- рассказываем, что нового
- делаем это постоянно
результат:
- разработчик понимает, что проблемы решаются
- доверяет и приносит новые проблемы
- слушаем
- вовлекаем
- предлагаем решения
- делаем
- вовлекаем и пиарим