Нанять product engineer легко. Гораздо сложнее перестать согласовывать с семью людьми каждое его движение.
Сейчас продвигается концепт product engineer — человека-оркестра, который с помощью ИИ самостоятельно проходит весь путь от пользовательской проблемы до работающей фичи. Поговорил с пользователями, придумал решение, написал код, протестировал, выкатил и посмотрел на метрики. То есть — всё то, для чего раньше требовались аналитик, продакт, разработчик, тестировщик и несколько свободных слотов в календаре.
Инженеры, конечно, возражают. Мол, один человек не может быть специалистом во всём, независимая проверка исчезнет, качество упадёт, а техдолг однажды обретёт сознание.
Менеджеры тоже переживают: ведь аналитик должен проверить требования, тестировщик — разработчика, архитектор — всех сразу, а менеджер проконтролировать, что участники процесса не забыли проконтролировать друг друга.
Только люди, которые уже внедряют такую модель, говорят, что заметной просадки на продуктовых метриках пока не видно. Не то чтобы в наше непростое время стоило верить джентльменам на слово, но всё же.
И тут возникает неприятный вопрос: а зачем нам действительно было нужно столько отдельных ролей?
Возможно, разделение труда существует не только ради экспертизы. Оно ещё помогает компании справляться с недоверием.
Аналитик пишет требования, потому что разработчику нельзя доверить понимание пользователя. Архитектор согласовывает решение, потому что разработчику нельзя доверить архитектуру. Тестировщик проверяет код, потому что разработчику нельзя доверить качество.
В результате процесс производит не только продукт. Он ещё производит доказательства, что никто конкретно не виноват.
С product engineer такой фокус провернуть сложнее. В одной голове находятся проблема, решение, реализация и результат. Сказать "моя часть работала" уже не получится — дальше тоже был ты.
Но для этого человеку придётся выдать не только четыре чужие обязанности, но и полномочия четырёх ролей. А вот с этим компании традиционно тяжело 😁
Возможно, ИИ не создаёт новую профессию. Он просто удешевил производство настолько, что стоимость корпоративного недоверия впервые стала хорошо заметна. Когда код писался месяц, две недели согласований терялись внутри общего срока. Когда код пишется за день, внезапно выясняется, что самым медленным компонентом системы всё это время был не разработчик.
Сейчас продвигается концепт product engineer — человека-оркестра, который с помощью ИИ самостоятельно проходит весь путь от пользовательской проблемы до работающей фичи. Поговорил с пользователями, придумал решение, написал код, протестировал, выкатил и посмотрел на метрики. То есть — всё то, для чего раньше требовались аналитик, продакт, разработчик, тестировщик и несколько свободных слотов в календаре.
Инженеры, конечно, возражают. Мол, один человек не может быть специалистом во всём, независимая проверка исчезнет, качество упадёт, а техдолг однажды обретёт сознание.
Менеджеры тоже переживают: ведь аналитик должен проверить требования, тестировщик — разработчика, архитектор — всех сразу, а менеджер проконтролировать, что участники процесса не забыли проконтролировать друг друга.
Только люди, которые уже внедряют такую модель, говорят, что заметной просадки на продуктовых метриках пока не видно. Не то чтобы в наше непростое время стоило верить джентльменам на слово, но всё же.
И тут возникает неприятный вопрос: а зачем нам действительно было нужно столько отдельных ролей?
Возможно, разделение труда существует не только ради экспертизы. Оно ещё помогает компании справляться с недоверием.
Аналитик пишет требования, потому что разработчику нельзя доверить понимание пользователя. Архитектор согласовывает решение, потому что разработчику нельзя доверить архитектуру. Тестировщик проверяет код, потому что разработчику нельзя доверить качество.
В результате процесс производит не только продукт. Он ещё производит доказательства, что никто конкретно не виноват.
С product engineer такой фокус провернуть сложнее. В одной голове находятся проблема, решение, реализация и результат. Сказать "моя часть работала" уже не получится — дальше тоже был ты.
Но для этого человеку придётся выдать не только четыре чужие обязанности, но и полномочия четырёх ролей. А вот с этим компании традиционно тяжело 😁
Возможно, ИИ не создаёт новую профессию. Он просто удешевил производство настолько, что стоимость корпоративного недоверия впервые стала хорошо заметна. Когда код писался месяц, две недели согласований терялись внутри общего срока. Когда код пишется за день, внезапно выясняется, что самым медленным компонентом системы всё это время был не разработчик.