Comments

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


Бэклог команды разработки обычно содержит список функциональных требований к софту (как?), а не бизнесовых (что? и почему?). У этого есть вполне объективные причины. И это одна из причин, почему разработчики не могут влиять на принципиальные моменты. Есть смысл в том, чтобы на уровне лозунгов агитировать за работу по всем фронтам как одна команда, но пытаться на практике из каждого матроса сделать бизнесового эксперта уровня капитана это утопия.

И как до разработчиков донести смысл функционала отдельной фичи для всего продукта? Или допустим оптимизацию бекенда для фронтендеров? Ведь далеко не все функции видны снаружи, зачастую даже люди на должности *директор ХХХ* не видит или не составляет глобальной картины продукта.
Хороший вопрос. Первое, что приходит в голову – знакомить команды друг с другом, организовывать процессы и их описание прозрачнее для всех вовлечённых, подробно ставить и описывать цели, а также желаемый результат. Но чем больше компания, тем сложнее и медленнее интеграция.
Продуктолог в вашей схеме должен приоритезировать беклог исходя из требований бизнеса.
Делать то что принесет доход, повлияет на рынок или какая там еще цель у бизнеса.
А от разработчиков он должен ДО начала реализации получать примерную оценку сложности\трудоемкости, и учитывать это в планах.
Беклог может быть лет на 5 вперед, но он не статичен, из него продуктолог вытаскивает и дает в работу то, что актуально сейчас исходя из рынка.
О технологических долгах разработчики тоже должны сообщать, что вон тот сервис пора рефакторить, а то мы уткнемся в проблему с производительностью скоро итп.
Ну а бест практис, должны ускорять а не тормозить процесс даже в среднесрочной перспективе, если они применены правильно, а не для галочки. О них продуктолог тоже должен быть в теме, зачем юнит тесты tdd итп.

В идеале продуктолог должен иметь неплохой бекграунд в разработке, быть в теме, а то всякая фигня будет получаться.
Правильные замечания, спасибо. Поддерживаю насчёт опыта в разработке у продуктолога, иначе у команды перед релизом будет череда бессонных ночей.
Only those users with full accounts are able to leave comments. Log in, please.