Разработка и продукт перестают быть отдельными командами: чьи зарплаты вырастут, а чьи процессы придётся ломать

Суть: крупные технологические компании, включая Apple, Microsoft и Google, системно не справляются с базовыми задачами интерфейса — например, выравниванием иконок с текстом. Параллельно в отрасли набирает силу подход, при котором разработка и продуктовая работа перестают быть изолированными звеньями и сливаются в единый цикл создания технологий. Это означает, что «чистые» инженерные или «чистые» продуктовые роли уходят в прошлое, а востребованными становятся специалисты, которые понимают и код, и пользователя.

Кто в выигрыше, кто под ударом. В выигрыше — разработчики с продуктовым мышлением и продукт-менеджеры с технической базой: их зарплатная вилка расширяется, а выбор позиций растёт. Также выигрывают компании, которые раньше других перестроят процессы под сквозную ответственность команд. Под ударом — узкие специалисты в крупных корпорациях, где разработка и продукт живут в разных этажах и часовых поясах: их компетенции обесцениваются, а проекты, за которые они отвечают, начинают отставать по скорости и качеству.

Страдают и заказчики цифровых решений — например, в сегменте умного города, — где разрыв между технологией и реальными потребностями пользователей приводит к дорогим доработкам.

Что это значит для вас. Если вы работаете в технологиях — пересмотрите свою специализацию: глубокая экспертиза в одной области больше не даёт той защиты, что давала пять лет назад. Изучите смежный слой — продуктовую аналитику, если вы разработчик, или архитектуру систем, если вы продуктовый специалист. Это не значит, что нужно стать универсалом, но понимание языка соседней дисциплины станет стандартом.

Если вы нанимаете технических специалистов — пересмотрите описания вакансий: требование «понимать бизнес-логику» или «уметь читать код» перестаёт быть «плюсом» и становится базой. Если вы инвестируете в технологические компании или выбираете подрядчика для цифровизации — спросите, как устроено взаимодействие между командой, которая пишет код, и командой, которая отвечает за результат для пользователя. Если ответ включает «передаём ТЗ между отделами» — это риск задержек и перерасхода.

На что обратить внимание. Проверьте, как устроены процессы в вашей текущей компании или у ваших подрядчиков: есть ли единый критерий успеха для разработки и продукта, или у каждого свои KPI. Если второе — готовьтесь к тому, что конкуренты, у которых процессы склеены, будут двигаться быстрее.

Честная оговорка: мы не знаем, насколько быстро крупнейшие игроки рынка смогут перестроить внутреннюю культуру — у них инерция масштаба, и даже очевидные технические проблемы, как та же с иконками, могут годами не доходить до приоритета.

Источники

Habr — Почему продукт и разработка не могут работать отдельно друг от друга: Habr — Задача со звёздочкой для фронтенда: выравниваем иконки с текстом: https://habr.com/ru/companies/avito/articles/1080464/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1080464