SM的价值或者脱离敏捷来讲，项目经理的价值是什么？编码实现的理解不如程序员，业务的理解不如产品经理。我的理解是“SM的工作就是在PO与团队之间的架桥”，要对整个软件项目负责。
既然是架桥，首先就得理解架桥的必要性，了解这座“桥”的作用，然后才知道这桥架成什么样子。
人最终是受限于自身的经验与知识体系的。
正因为分工不同，PO往往在业务知识、用户价值方面思考较多，对软件的实现方面思考甚少。结果就是PO在表达自己的产品设计时，或因为畏惧技术的不可达而设计得过于小气，发挥不出技术的最大潜能。或者就是天马行空般表达，完全脱离实际技术能力而导致项目流产。除以之外，PO在表述产品设计时容易出现想当然，认为只要把想法简单的说出来即可，对编码实现需要考虑非常具体逻辑判断的认识不到。PO大量细节考虑不周，程序员在实现时就会在细节的确认上花费大量的时间，最终结果就是实际花掉的时间远远超过当初认为“应该花掉”的时间。SM识别出这些潜在的问题，从需求的源头提升质量，就能提升实现的质量与速度。
从程序员的角度看，实现功能很容易成为目标甚至唯一目标，而可用性就是对最终产出的“评判”标准。功能实现出来就像厨师把饭菜做出来一样，只是最基础的要求，如何把软件产品这个“饭菜”做的色香味俱全，才是一个优秀IT工程师的所应该追求的。软件产品是否优秀的指标，有扩展性、维护性、可移植、安全性、健壮等等，每一项指标的提升都需要程序员去思考很多东西，不是一个简单只知道码代码的人能够深刻理解的。以功能实现为目标容易产出维护成本很高的软件产品，比如规范做的极烂、架构基本没有、模块高耦合等等。另外，有一些东西仅仅从技术的角度进行分析是远远不够的，比如扩展性以及设计模式的选用，很多就是基于业务场景想象来进行选型的，我们预见未来可能会有这些功能的扩展，在编码中就应该提前规划。而这些东西PO是无法从需求中提炼出来的，他仅仅知道未来要扩展，但不知道我们现在其实可以提前准备。这些点就是SM的价值，提前识别出来，引导好PO在澄清需求时讲出来，好让编码职员提前作好规划，提升整个项目的编码水平。
其次就是需要知道如何架桥，有一些常用的架桥手段。
这个架桥的手段就不仅仅指专业知识了，更多的涉及到人际沟通方面的东西，用一个时髦的词来说就是情商要高。当我们意识到某个方法有利于工作质量的时候，别人不一定认同或者明显是对的但是不愿意改变自己的工作方式，人对于改变往往是下意识抗拒的，这个时候我们就需要运用一切资源来推动这个东西了，比如从公司层面形成制度、利用自己的人格魅力施加影响、动之以情晓之以理等。那这些工作有没有规律可循呢，其实还真没有，需要因人而异，对症下药。不同的人有不同的思路，有权力的人可以强推，有权威的人就简单了，大家相信他，那他只需要表达出来，大家首先就信任了他三分。方法是没有定型的，资源也是有限的。战争是解决争端的最后手段，所以利用好现在的因素尤其是专家和公司层面制度等大家会信服的东西来“水到渠成”是最好的结果。
最终目的其实很好理解，就是要把想要做的软件产品做出来，但是这个架桥的理解却不是每个人都能够理解得透的。
其实，优秀的SM或者项目经理的工作不只是架桥这一个工作，于技术团队而言需要指导技术架构、设计模式等东西以提高软件架构的扩展性、维护性等。于PO来说，需要引导其确保设计层面考虑了易用性、在技术上是否可行、是否把握住了产品的核心价值等全局性、根本性的东西。