Как появляется инфраструктурная команда

• Всё растёт. Больше пользователей и нагрузки.
• Бизнес хочет ещё больше.
• Инфраструктурные задачи бизнесу непонятны, но необходимы для развития.

Примеры:

• Шардинг, масштабирование
• Visibility: логи, метрики, визуализация
• Второй ДЦ
• …

Нужна отдельная инфраструктурная команда, которая будет это поддерживать.

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

• Продуктовые бэкенды. C/C++/Go.
• Инфраструктурные сервисы
  • скриптовое облако
  • очереди
  • фотографии
  • миграция данных между ДЦ
  • mobile API gateway
• Инструменты разработчика
  • метрики: хранение и визуализация
  • деплой PHP-кода
  • сборки и модули для PHP и nginx
  • тестирование: soft mocks
  • unified data system (UDS)

Путь инфраструктурной команды

над которой не стоит стейкхолдер из бизнеса и не требует задач.

Есть задачи:

• от бизнеса
• от продуктовых команд
• развивать инфраструктуру

Полезность команды растёт.

Потом становится так:

• от бизнеса — но зачем, это же фичи?
• от продуктовых команд — некогда нам?
• развивать инфраструктуру!!!

Полезность команды падает. Приуныли.

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

Как выбирать важное?

Важна культура.

• горизонтальные связи
• фокус на результате
• постоянный инженерный фидбэк

Воронка рождения проекта:

1. Источники: собрать боль и хотелки. Делаем максимально широкую воронку. Сами идём к разработчикам и ищем боль. Устраиваем формат AMA (ask me anything) — в назначенное время в переговорке отвечаем на все вопросы.
2. Вовлечение: найти заказчика. Слушаем, вовлекаем, предлагаем решения, формируем видение.
3. Бизнес-цели: какую задачу решаем? Могут быть про продукт, про time to market, про оптимизацию работы или страховку «от метеорита». Бизнес-цели имеют нетехнические критерии оценки и меняют технический проект.
4. Ready to dev: инженерный проект и ресурсы. Важный вопрос здесь — что НЕ делать? Помним о принципе YAGNI. Понять, что критично, и построить именно это.
5. Приоритеты. Делаем сквозную приоритизацию всех проектов. Сверяемся с командами, которые делают фичи.

Разработка

• проекты долгие
• высокая цена ошибки
• нельзя просто «написать код»
• внедрение часто сложное
• хорошее качество должно быть сразу (а в разработке фич не так; можно сделать как-то, а потом допилить, если выстрелит)

Кто делает? Разработчик

• проводит kick off
• формирует технический план
• ведёт проект
• отвечает за результат

Любой проект режется на этапы. Каждый этап:

• что именно будет сделано?
• сроки: когда на бою?
• длительность — 1-2 недели
• выкладываем на прод
• стараемся анонсировать, что получилось

Пиар важен

• проекты долгие
• изменения часто невидимы «by design» пользователям и даже разработчикам.

поэтому:

• собираем фидбэк
• рассказываем, что нового
• делаем это постоянно

результат:

• разработчик понимает, что проблемы решаются
• доверяет и приносит новые проблемы

Цикл работы инфраструктурной команды

1. слушаем
2. вовлекаем
3. предлагаем решения
4. делаем
5. вовлекаем и пиарим