Комментарии 7
Спасибо за интересную тему. Scrum и Agile выглядят как практики для одомашнивания бизнесом диких анархо-разработчиков. Разработчикам предлагается принять определенную картинку мира, где некоторая часть бизнесовых ценностей и рисков должны восприниматься как свои собственные.
Бэклог команды разработки обычно содержит список функциональных требований к софту (как?), а не бизнесовых (что? и почему?). У этого есть вполне объективные причины. И это одна из причин, почему разработчики не могут влиять на принципиальные моменты. Есть смысл в том, чтобы на уровне лозунгов агитировать за работу по всем фронтам как одна команда, но пытаться на практике из каждого матроса сделать бизнесового эксперта уровня капитана это утопия.
Настала пора перемен.Как-то даже настроение приподнялось
И как до разработчиков донести смысл функционала отдельной фичи для всего продукта? Или допустим оптимизацию бекенда для фронтендеров? Ведь далеко не все функции видны снаружи, зачастую даже люди на должности *директор ХХХ* не видит или не составляет глобальной картины продукта.
Продуктолог в вашей схеме должен приоритезировать беклог исходя из требований бизнеса.
Делать то что принесет доход, повлияет на рынок или какая там еще цель у бизнеса.
А от разработчиков он должен ДО начала реализации получать примерную оценку сложности\трудоемкости, и учитывать это в планах.
Беклог может быть лет на 5 вперед, но он не статичен, из него продуктолог вытаскивает и дает в работу то, что актуально сейчас исходя из рынка.
О технологических долгах разработчики тоже должны сообщать, что вон тот сервис пора рефакторить, а то мы уткнемся в проблему с производительностью скоро итп.
Ну а бест практис, должны ускорять а не тормозить процесс даже в среднесрочной перспективе, если они применены правильно, а не для галочки. О них продуктолог тоже должен быть в теме, зачем юнит тесты tdd итп.
В идеале продуктолог должен иметь неплохой бекграунд в разработке, быть в теме, а то всякая фигня будет получаться.
Делать то что принесет доход, повлияет на рынок или какая там еще цель у бизнеса.
А от разработчиков он должен ДО начала реализации получать примерную оценку сложности\трудоемкости, и учитывать это в планах.
Беклог может быть лет на 5 вперед, но он не статичен, из него продуктолог вытаскивает и дает в работу то, что актуально сейчас исходя из рынка.
О технологических долгах разработчики тоже должны сообщать, что вон тот сервис пора рефакторить, а то мы уткнемся в проблему с производительностью скоро итп.
Ну а бест практис, должны ускорять а не тормозить процесс даже в среднесрочной перспективе, если они применены правильно, а не для галочки. О них продуктолог тоже должен быть в теме, зачем юнит тесты tdd итп.
В идеале продуктолог должен иметь неплохой бекграунд в разработке, быть в теме, а то всякая фигня будет получаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фрейминг для разработчиков