Pull to refresh

Comments 7

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


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

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

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