Про инструменты
Что смущает меня во всех инструментах по управлению проектами, так это атомарность и независимость сущностей внутри системы. То есть задачи, баги, релизы и майлстоуны сами по себе, вики-странички сами по себе, бранчи кода сами по себе. Каждый класс сущностей висит в вакууме. Управлять каждой штучкой нужно отдельно. Отдельно принимать решение о том, нужна ли еще она или уже устарела и имеет смысл переложить в кучу "не случится никогда".
А ведь в реальности это не так. В реальности же есть некое видение продукта, которое худо-бедно можно уложить в майндмап: из некой центральной идеи/цели растут суб-идеи, варианты решения, ветвятся в детали реализации, конкретные задачи и конкретные данные. Фишка в том, что у некоторого требования может быть несколько альтернативных подходов к решению, каждый из которых детализирован задачами и данными, в процессе проработки выясняется, что выживает один; другой становится неактуален, вместе с ним должны быть заархивированы все артефакты из него следующие. Или другой пример: некий юз-кейс, не очень важный, хочется привязать к нему списки задач и дизайн документов, чтобы ждали своего часа. Однако, если выяснится, что концепция продукта поменялась и юз-кейс не актуален, то все артефакты с ним связанные должны уехать в архив.
К чему это я? К тому, что инструменты, которые я вижу, решают задачу с другого конца, предоставляются способы для управления конечными артефактами, в то время как они вторичны к менее формализованным исходным идеям. А надо наоборот, весь проджект-менеджмент - это управление детализацией некого видения, не задачами на 4 человека-часа макс, а большими неструктурированными блобами из которых через пару уровней детализации выводятся те самые 4-х часовые задачи. Более того: детализация некоторого блоба - тоже является задачей. У такого инструмента, конечно будут проекции вида "задачи, которые мы делаем сейчас" или "актуальные артефакты документации", но эти проекции будут вторичны к основной структуре, которая управляет видением.
Может быть я открываю Америку и все уже давно написано? Или может быть люди попробовали и поняли что это неудобно? Расскажите мне.
А ведь в реальности это не так. В реальности же есть некое видение продукта, которое худо-бедно можно уложить в майндмап: из некой центральной идеи/цели растут суб-идеи, варианты решения, ветвятся в детали реализации, конкретные задачи и конкретные данные. Фишка в том, что у некоторого требования может быть несколько альтернативных подходов к решению, каждый из которых детализирован задачами и данными, в процессе проработки выясняется, что выживает один; другой становится неактуален, вместе с ним должны быть заархивированы все артефакты из него следующие. Или другой пример: некий юз-кейс, не очень важный, хочется привязать к нему списки задач и дизайн документов, чтобы ждали своего часа. Однако, если выяснится, что концепция продукта поменялась и юз-кейс не актуален, то все артефакты с ним связанные должны уехать в архив.
К чему это я? К тому, что инструменты, которые я вижу, решают задачу с другого конца, предоставляются способы для управления конечными артефактами, в то время как они вторичны к менее формализованным исходным идеям. А надо наоборот, весь проджект-менеджмент - это управление детализацией некого видения, не задачами на 4 человека-часа макс, а большими неструктурированными блобами из которых через пару уровней детализации выводятся те самые 4-х часовые задачи. Более того: детализация некоторого блоба - тоже является задачей. У такого инструмента, конечно будут проекции вида "задачи, которые мы делаем сейчас" или "актуальные артефакты документации", но эти проекции будут вторичны к основной структуре, которая управляет видением.
Может быть я открываю Америку и все уже давно написано? Или может быть люди попробовали и поняли что это неудобно? Расскажите мне.