Платформенная команда vs продуктовая команда: почему в эпоху ии это еще важнее
Иишки сокращают путь от идеи до работающего прототипа. Все чаще можно собрать что-то за часы. Даже у red_mad_robot есть процесс фича за 120 минут. Но скорость создания решения еще не говорит о том, что оно кому-то нужно.
На мой взгляд, именно поэтому граница ответственности продуктовой и платформенной команд становится важнее.
Продуктовой команде нужно быстрее узнавать, какие экспы и абшки заслуживают дальнейших инвестиций. Есть проблема пользователя, мы делаем АБ тесты, выбираем какой дальше масштабируем. Продуктовым командам НЕЛЬЗЯ делать сразу идеально круто. Каждый эксп не заслуживает перфекционизма.
Если для каждого экспа команда заново собирает окружение, получает доступы, подключает аналитику и разбирается с выпуском, время, сэкономленное на написании кода, уходит в ожидание и интеграцию.
Здесь появляется задача платформенной команды: сделать быстрые экспы и дальнейшее развитие решений доступными для многих команд.
В эпоху AI это означает:
🟣Давать готовые окружения, тестовые данные, аналитику и способы ограниченного запуска.
🟣Поддерживать понятные API, документацию и быстрые проверки, которыми могут пользоваться разработчики и AI-агенты.
🟣Предоставлять общие инструменты работы с моделями: доступы, наблюдаемость, оценку качества и контроль стоимости.
🟣Обеспечивать понятный путь к эксплуатации: выпуск, мониторинг, масштабирование и откат.
И сама платформа должна развиваться как продукт. У нее тоже есть пользователи, гипотезы и необходимость доказывать пользу. Хороший ориентир из Team Topologies — снижать когнитивную нагрузку продуктовых команд и ускорять доставку ценности.
Иишки сокращают путь от идеи до работающего прототипа. Все чаще можно собрать что-то за часы. Даже у red_mad_robot есть процесс фича за 120 минут. Но скорость создания решения еще не говорит о том, что оно кому-то нужно.
На мой взгляд, именно поэтому граница ответственности продуктовой и платформенной команд становится важнее.
Продуктовой команде нужно быстрее узнавать, какие экспы и абшки заслуживают дальнейших инвестиций. Есть проблема пользователя, мы делаем АБ тесты, выбираем какой дальше масштабируем. Продуктовым командам НЕЛЬЗЯ делать сразу идеально круто. Каждый эксп не заслуживает перфекционизма.
Если для каждого экспа команда заново собирает окружение, получает доступы, подключает аналитику и разбирается с выпуском, время, сэкономленное на написании кода, уходит в ожидание и интеграцию.
Здесь появляется задача платформенной команды: сделать быстрые экспы и дальнейшее развитие решений доступными для многих команд.
В эпоху AI это означает:
🟣Давать готовые окружения, тестовые данные, аналитику и способы ограниченного запуска.
🟣Поддерживать понятные API, документацию и быстрые проверки, которыми могут пользоваться разработчики и AI-агенты.
🟣Предоставлять общие инструменты работы с моделями: доступы, наблюдаемость, оценку качества и контроль стоимости.
🟣Обеспечивать понятный путь к эксплуатации: выпуск, мониторинг, масштабирование и откат.
И сама платформа должна развиваться как продукт. У нее тоже есть пользователи, гипотезы и необходимость доказывать пользу. Хороший ориентир из Team Topologies — снижать когнитивную нагрузку продуктовых команд и ускорять доставку ценности.