Преимущества и недостатки работы в платформенной команде
Читаю книгу Гергели Орош - Разработчик ПО. И внезапно встретил описание платформенных команд разработки и того, чем они отличаются от продуктовых команд, например, разработчиков конфигураций.
С удовольствием пересказываю.
Преимущества платформенных команд:
- Техническая сложность
Они решают самые сложные технические задачи. Нужно учитывать масштабирование, разные среды выполнения и много других факторов
- Широкое влияние
Работа платформенной команды не ограничивается одним продуктом.
Она оказывает существенное, хоть и косвенное, влияние на все продукты, использующие платформу
- Больше свободы для разработчиков
В таких командах часто нет продакт-менеджеров. Поэтому программисты могут сами влиять на процессы, заниматься техническим долгом и внедрять новые технологические идеи
- Меньше давление в повседневной работе
Платформенные команды обычно дальше от конечных пользователей, поэтому на них меньше давят сроки выпуска новых фич. Это позволяет больше думать о долгосрочных решениях и качестве архитектуры
- Уровень сотрудников
В платформенных командах часто работают разработчики уровня сеньор и выше, потому что такие задачи требуют большого опыта
Недостатки работы в платформенной команде:
- Сложнее оценить влияние своей работы на дела компании
Продуктовая команда может легко показать результат своей работы. Например, рост дохода или приток новых пользователей благодаря новой функции. Платформенным командам сложнее связать свою работу с понятными бизнес-метриками
- Часто считаются центрами затрат
Из-за того, что платформенным командам сложнее показать прямую пользу для бизнеса, их чаще воспринимают как центр затрат. Поэтому им бывает труднее обосновать расширение команды, а при сокращении расходов такие команды могут пострадать сильнее продуктовых
- Отдалены от пользователей
Платформенные команды часто находятся далеко от конечных пользователей продукта. Из-за этого можно потерять понимание реальных потребностей пользователей, начать неверно расставлять приоритеты и чаще конфликтовать с продуктовыми командами
Читаю книгу Гергели Орош - Разработчик ПО. И внезапно встретил описание платформенных команд разработки и того, чем они отличаются от продуктовых команд, например, разработчиков конфигураций.
С удовольствием пересказываю.
Преимущества платформенных команд:
- Техническая сложность
Они решают самые сложные технические задачи. Нужно учитывать масштабирование, разные среды выполнения и много других факторов
- Широкое влияние
Работа платформенной команды не ограничивается одним продуктом.
Она оказывает существенное, хоть и косвенное, влияние на все продукты, использующие платформу
- Больше свободы для разработчиков
В таких командах часто нет продакт-менеджеров. Поэтому программисты могут сами влиять на процессы, заниматься техническим долгом и внедрять новые технологические идеи
- Меньше давление в повседневной работе
Платформенные команды обычно дальше от конечных пользователей, поэтому на них меньше давят сроки выпуска новых фич. Это позволяет больше думать о долгосрочных решениях и качестве архитектуры
- Уровень сотрудников
В платформенных командах часто работают разработчики уровня сеньор и выше, потому что такие задачи требуют большого опыта
Недостатки работы в платформенной команде:
- Сложнее оценить влияние своей работы на дела компании
Продуктовая команда может легко показать результат своей работы. Например, рост дохода или приток новых пользователей благодаря новой функции. Платформенным командам сложнее связать свою работу с понятными бизнес-метриками
- Часто считаются центрами затрат
Из-за того, что платформенным командам сложнее показать прямую пользу для бизнеса, их чаще воспринимают как центр затрат. Поэтому им бывает труднее обосновать расширение команды, а при сокращении расходов такие команды могут пострадать сильнее продуктовых
- Отдалены от пользователей
Платформенные команды часто находятся далеко от конечных пользователей продукта. Из-за этого можно потерять понимание реальных потребностей пользователей, начать неверно расставлять приоритеты и чаще конфликтовать с продуктовыми командами