uml|产品经理的思考利器——UML(7000字长文)

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片

uml|产品经理的思考利器——UML(7000字长文)

文章图片




看到这个标题 , 产品的朋友们大概率会一头雾水 , 为什么一个产品要学这么“奇怪”的东西?产品把产品本职工作做好就行了吧?
且听我快速道来~
在我之前的产品经历里 , 经常会遇到一个场景 , 在我拆解(或调研)某个业务系统时 , 无法梳理出一个系统层面清晰的脉络 , 思考出整个业务和系统架构的融合方式 , 即使后期我梳理清楚了 , 也是一个“大力出奇迹”的方式 , 一步一步硬推出来的 。
但这种蛮力的方式不是长久之计 , 如果我以后换了领域或者行业怎么办?我的业务线调整裁掉了该怎么办?都要硬啃吗?显然不行的
在工作中 , 我们接触新领域/产品的时候 , 都会“开头难” , 这个难在于没有在这个新领域下有历史经验 , 以致于用最笨的方法去调研 , 验证 , 学习 , 然后积累出一点点优势 , 慢慢滚雪球 , 形成加速 。 但如果又换一个新领域 , 我们很大概率还依赖这种行为方式 , 这就会造成认知的低效率 。
我其实一直想找到一个比较底层的方法工具 , 便于快速切换领域和习得经验 。
我先后学习与应用了一些思考框架 , 如