31 ｜节点六: 如何组织阶段性的价值交付？

我们主要是做一些toG业务，参与过很多的项目，我个人觉得并没有商业价值、用户价值和技术价值，比如说驾驶舱大屏，只是一张皮，多数用于宣传，开发布会，但并没有实际用。这类的项目对我感触比较深的就是在消耗自己的技术水平，

郭老师，大项目的联调成本很高，请问是哪些成本，针对这些成本我们应该怎么做呢？我现在的项目常态是3个研发团队合作开发，期待您的指导

🤔☕️🤔☕️🤔 * 📖：目标分解 = 商业价值视角 + 用户价值视角 + 技术价值视角。 * 🤔：用户，不等于购买方，或者说，不等于客户。有些产品，在这个点上多辨别，会打开新的启发。典型如孩子用的任何东西，都是爹爹妈妈爷爷奶奶外公外婆在掏钱，前者是用户，后者是客户，这两者的价值视角不一样。孩子要手表，是因为没有跟其他小伙伴碰一碰，就无法入群，可是爹妈要的可能是实用，怕太贵会影响孩子的观念。如何在这不同的视角下，找到让用户和客户都满意的交集，值得探索和琢磨。

郭老师，take away~~~最近反思，从事计算机工作，需要具备两个最基本的思维能力，递归思维和分治思维~~~ 递归思维解释为自顶向下、以终为始的逆向思维、然后以小建大，就像动态规划，需要先看到终点目标、最终的一小步如何走才能成功，然后从0开始多阶段决策~~~ 分治思维解释为问题定义，拆解问题，拆解问题的限制条件，拆解问题的成功标准~~~ MVPU的全称，我上网查了一下，MV=Mate value(伴侣价值)，PU=Paternity uncertainty(亲子不确定性);为什么总是强调MVPU？因为现在是VUCA时代，通过消除信息论定义的不确定性(人工智能)成功；Build~Measure~Learn，无数据不决策~~~ 如果谁还纠结牛顿时代的确定性和机械思维，一定是忘了爱因斯坦、普朗克、达尔文、引力波理论、基因双螺旋结构~~~

最小可行产品（Minimal Viable Product，MVP）。不过我要稍稍做一些更改，将这个概念称为最小价值单元（Minimal Value Proposition Unit），指的是从架构活动中分离出最小的、有增量价值的交付单元。

分段交付的目的是：给自己和团队赢得了宝贵的试错机会和调整方案的时间。 因为前期我们可能对用户/客户的需求理解不够深入或者不全面，通过市场反馈来判断我们的产品是否符合目标，错误越早发现，修正错误的成本越低。

感谢东白老师的精彩课程，老师的MVPU方法，可以作为敏捷开发中每个PI排任务的指导。 从未使用过老师的MVPU方法，因此第一和第三个问题，不知道怎么回答。关于第二个问题，几年前学生还真经历过，一般来说或是一些digital tool来节省重复的人力流程之类的，因为在交付前，往往只是老板的一个idea，不会去认真研究商业价值或技术价值，过程也挺有趣。 - 即不轻松——很难抢资源； - 也不意外——觉得自己该做的； - 也不失落——因为老板的诉求也是要突破现状，对于自己也是业务上的新探索。 其实也没有什么心情可言，就是不断思考如何out-of-box地以最低成本最快低交付，而且比期望的结果更好。

MVPU同学的解释是没看30节，哈哈