Comments 6
Очень хорошая и нужная статья. Спасибо. Рассказываете вы, по сути, азбучные истины управления разработкой, но именно понимания азбучных истин современному менеджменту катастрофически не хватает.
Я, в последнее время, чаще встречаюсь с тем, что команды ломаются даже не доходя до этапа storming. Просто потому, что менеджмент не в состоянии ответить на вопрос "что делать?". Про User Stories я вообще молчу - увидеть вменяемый роадмап и беклог - это из разряда фантастики :)
Еще рекомендовал бы формализовать процесс декомпозиции бизнес задач из беклога User Stories в технические задачи. Связь между ними далеко не такая очевидная, как кажется на первый взгляд. Одна "бизнес задача" может распадаться на несколько технических, и одна техническая задача может требоваться для закрытия нескольких бизнес задач. В сложных проектах имеет смысл вести 2 беклога - бизнес задачи и технические задачи.
Дополнительно очень рекомендую вести беклог "Технический долг". Любой проект на этапе создания MVP для ускорения "берет в долг" у мироздания. Где то срезали угол, где то сделали неоптимально, где то пожертвовали нефункциональными требованиями (отказоустойчивость, масштабируемость), где то не заложили фундамент под планируемое развитие проекта и т.д. и т.п. Технический долг - это нормально. Без него практически нереально запустить разработку. Но очень важно уметь управлять техническим долгом. Первый шаг в управлении - это формализация долга. На каждом этапе развития проекта вы должны очень четко понимать, что вы должны мирозданию. Второй шаг - это составить план погашения долгов. Роадмап выплат по долгу так сказать. Когда и на каких этапах мы будем возвращать долги мирозданию? Ну и третий шаг - проявить силу воли и возвращать долги в соответствии с планом, даже если этого очень сильно не хочется делать. Если вы не управляете техническим долгом, то рано или поздно технический долг начнет управлять вами.
Вроде и хорошо написано, но не очень понятно, если не глубоко в теме :(
Обычно Project Manager (PM) или Product Analyst (PA), реже сам PO,
погружается в конкретный User Scenario и нарезает его на множество User
Stories.
Какие понятия вы вкладываете в эти сочетания букв? Даже при использовании общеизвестных слов приходится уточнять их смысл в контексте, а тут сразу иероглифы.
Не может быть так, что если разговаривать на более понятном языке, то процесс создания команды ускорится, а работа улучшится?
Как запустить команду разработки