我和钟老师（顾问）在客户现场会议室利用午休时间聊天，钟老师是“70后”，毕业后在软件开发公司工作，2000年后，内地各省和地方政府开始对CMMI认证提供补助，他便开始为软件公司做咨询、培训工作至今。

顾问：听说我一直服务的那家软件公司马上就要裁员了，每个部门都定了指标，所以昨天去现场看到大家表情凝重，没有什么动力去做过程改进，担心自己会被裁掉。

我：裁员确实影响员工士气，哪里还有心情做过程改进为公司产生价值。其实公司最核心的竞争力就是有实力的员工，如果把那些为公司产生价值和收入的资源裁掉，不是反而对公司不利吗？所以有人认为公司裁员反映了管理者的不负责任。回顾历史，很多公司裁员后，也没有解决公司的根本问题，大部分公司过了一年继续裁员，恶性循环。

顾问：但现在市场都很难做，收入没有增长，公司哪里有钱付这么多人员的薪水。在软件公司，薪水是最大的成本，它们很多是上市公司，股民关注公司盈利，管理层要对股东负责，最佳的方式就是裁员减少成本，保持公司盈利，没有更好的方法。

我：真的没有更好的方法吗？跟你分享2个故事——某家美国老牌超市集团，它的人力成本比同行高，原因是内部有很多老员工，但因为有雇佣合同和工会限制，公司不能辞退那些老员工，所以到需要减少人力成本的时候，通常都是先辞退年轻的新员工，导致公司老龄化严重，人力成本也越来越高，整个集团一直不盈利。在美国宾州，在一年内关闭接近一半的超市，导致很多员工失业，本地政府觉得问题紧急，便找宾州大学的教授想办法，教授建议鼓励员工从公司购买这些关闭的超市，重新开业，并制定新的雇佣规则，比如降低月薪，但是员工可以得到超市的利润分成，后面发现这种方式很成功，于是集团也计划把更多超市转为这种新模式。20世纪90年代初，因为经济萧条，日本丰田汽车当时有7万员工面临裁员压力，管理层要求团队提出降本增效、提高士气的建议，于是员工提了很多改进建议，大部分被采纳并试用。到1996年，这些建议使公司生产率提升了10%，减少了裁员的压力（9万员工）。所以实际上有更好的办法解决公司利润的问题，比直接裁员好很多。从以上故事可以知道，直接裁员不一定是最好的解决方案，更重要的是找到生产力过剩的根本原因，不然的话，这种人力过多利润下降的情况还是会再次出现。

顾问：有什么好方法？

我：分享几个例子。先讲讲A公司，是我20年前开始提供咨询与评估服务的首批软件公司之一，它主要做香港特区政府的IT项目（也有做非政府的项目，但是占比不大）。因为政府项目都是要公开投标的，竞争激烈利润很薄。开始时，业务和盈利时好时坏，有时项目管理不善就会亏钱。大概10年前，换了一位技术总监管理公司后，就很少出现亏损了。每年的业务量与利润都有提升，同时很多竞争对手也陆续退出，不再参与政府项目，现在A公司在政府项目市场的份额很大，远远超过其他竞争对手。我为A公司服务多年，与这位总监很熟络，就问他有什么管理的好方法。

他说：“很简单，公司必须加入内部竞争，因为有竞争才有进步，所以我下面的每个业务组的负责人都要对每年盈利负责，除了收入，项目成本也要管好。”

他的管理思路跟前任的方式完全不一样，前任是以传统管理项目手段为主，项目经理只要把项目做好，不需要对项目是否盈利负责。

总监手里这么多项目，怎么有精力管好每个项目并保持盈利？所以整个公司业绩一直不太理想。

新任总监利用现有的项目管理工具，要求每个项目组在项目启动之时，在工具上输入预算并填写工时、进展，系统自动算出当前的项目成本是多少，按超支情况显示红黄绿灯。团队负责人、项目经理部门负责人和总监都能在系统里面即时看到项目成本，从而判断是否能按预期盈利。

总之，如果在公司组织架构里有内部竞争，同时能用系统真实反映成本和资源利用的情况，就可以减少浪费，避免人员过剩。

顾问：我服务的绝大部分公司的项目经理都只管技术，不需要对成本负责，也没有用什么项目管理工具，无法即时监控项目的成本是否超预算，进度是否有延误等。听你这么说，其实都有很大的改进空间。

我：是的。例如A公司按市场划分4个部门，其中一个部门负责非政府项目，另外有专门针对政府大客户，如警察、医疗卫生等的部门。每个部门都有自己的技术人员，包括开发、测试、项目经理、需求等项目所需，所以每个季度都能计算各事业部的盈利。

任何组织都可以分为利润中心和成本中心。

以下面这家专门针对金融投资业务的X公司为例，员工人数不到300人，事业部有3个，针对不同市场；产品部负责标准产品的开发更新和维护，6—8周就会发布软件产品新版本给3个事业部去销售，除了有些定制开发，这些都是由各个事业部内部的工程师开发的。所以产品部是成本中心，事业部是利润中心。

产品部作为成本中心允许直接给客户销售产品，事业部为了全面满足客户需要，也可以卖其他软件产品（非产品部的产品）给客户。

图B1-1

另一家E公司，它们有多条产品线：

●   针对医保

●   针对人保

●   为相关政府部门提供培训和客服平台

图B1-2

开发人员包括测试和开发工程师，都归到交付部门里作为公用资源。虽然这个公用资源算是成本中心的，但因不知道工程师工时分别用于哪条产品线，也没有内部部门间的交易、结算，故无法计算某事业部（产品线）的利润是多少，只知道收入。公用资源里的工程师也没有动力提高效率和质量。

顾问：道理是有道理的，但我听说有些央企、国企在搞利润中心时会遇到以下问题难以解决：有些产品线本来就赚钱，有些产品线本来就很难赚钱，如何梳理产品线并合理配置，确保利润中心利润目标相对公平？

我：你想问领导应如何去管理利润中心，制定目标？并如何确保目标相对公平？但为什么领导要去管？

顾问：为什么呢？制定目标、定期监控本应是管理者的基本职责。

我：是吗？对企业能产生什么价值？让我先讲讲企业为什么要设立利润中心、成本中心。

美国通用汽车内部有很多分品牌和子公司，包括专门提供汽车零件的公司。高层规定，如果集团内部能提供，必须内部采购，这个政策导致以下内部纠纷：虽然公司花了很多精力分析数据，制定合理的内部优惠价，但往往内部的甲方乙方都不满意。解决办法：允许竞争，公司可以从集团外，找其他供应商购买。

所以，回答你的提问，高层不应该花精力制定各事业部‘相对公平’的利润目标，而应该按系统思维、自由竞争概念让事业部自己决定它的目标，最终与其他事业部比较，判断有没有价值值得继续存在。当然也要考虑产品都有生命周期，例如可参考谷歌的70/20/10原则，投资组合里的旗舰产品占收入的70%，20%的收入应来自新产品，10%用于专注未来的市场。

也可以同样解决某些资源比较紧缺，各利润中心相互争抢资源的问题。高层不应尝试去平衡和化解内部矛盾，而是让市场力量生效。哪个利润中心能付紧缺资源的‘市场价’，就能获取资源。

顾问：有道理，应依赖内部市场力量，鼓励内部竞争。

我：若要公司企业减少浪费，除了设置利润中心、成本中心外，整个企业的组织架构也要调整。

有很多企业还是按功能来划分，比如某软件产品公司，有独立的测试部，负责整个公司所有事业部的测试工作，由测试总监主管按业务单元需求，安排测试人员到项目中，配合事业部里的产品经理、项目经理做项目。专业的人做专业的事，这样分工能确保每个功能更专业、更优秀，你赞同吗？

顾问：有道理，但会遇到不少部门间的协调问题。

我：这种按功能划分的架构，公司越大需要协调的问题越多。逐渐地，功能人员被分配到其他工作，以减少沟通协调问题。这种按功能的区分，很难让事业部盈亏自负，因为很多成本来自公用的功能部门的分摊。但怎么分是一个问题，这种就违反了公司应该分成很多独立自负盈亏的部门的理念，为了良性内部竞争，每个事业部都要负责盈利。如果那些功能，比如需求或者测试没有提升效率，没有价值，那么它的成本就高了，利润就低了。

顾问：你说公司组织架构按功能来划分，确实会引起很多团队协调、沟通问题，但有矩阵式管理。比如测试人员虽然由测试总监管理，但是同时也长期被分配到某个事业部做测试，这不是就可以平衡了？一方面可以满足事业部人力资源需要，另一方面也能保持测试工作的专业性？

我：理论上是这样，但有很多实际问题，这种方式不能解决。比如员工都比较看重最后年终奖或者薪水提升了多少，这个还是要靠主管决定。问题就来了，现在他有两位总监，测试总监与事业部的总监，哪位能决定这位员工的考核？如果两位意见不合，就会产生很多内部纠纷，测试人员不知道应该讨好哪一方。

事业部的总监也有难处。刚才说事业部要自负盈亏，根据盈利来客观衡量他的成就，但在矩阵式管理下他要面对多位总监，各个专业都有各自的总监在管，比如研发，他就很难只专注自己事业部的盈利，因为总监们都会从自己的专业角度提要求。
最经典的例子，某大型上市公司很注重信息安全，IT部门在20多年前设置了信息安全组，防止内部信息泄露、被黑客攻击，于是制定了很多条款。有些做法很夸张，当时PC都有使用软盘，为了防止公司信息被泄露，把软盘驱动都贴封条封掉，定期抽查员工有没有违规，很影响员工的正常工作，不能专注把业务做好。因为最理想的信息安全就是禁止员工获取任何信息，员工什么信息都看不到是最安全的，这还怎么工作？同样地，测试也好，开发也好，如果都从各自专业立场提要求，那么可能导致事业部难以操作。
亚马逊你听说过吗？

顾问：当然，它是一家很大的电商。

我：亚马逊创始人Jeff Bezos靠帮大书店在网上卖书起家，后面电商越来越流行，盈利比那些最大的书店还多，后来他把业务扩大到卖各种物品，发展成世界有名的电商公司。因为他知道在互联网里只有No.1，所以必须要尽快占领市场，但他发现公司扩大的同时，出现很多协调问题。然后内部高层讨论怎么解决，结论是要完善和加强内部沟通。创始人听完他们的建议后提出，“其实我们需要的不是完善或更多的沟通，而是减少沟通”。内部高层有点蒙。创始人解释说：“你们有没有听过建教堂和摆地摊的比喻？例如在美食广场摆摊，美食广场只是提供一个平台，欢迎任何一个有创意的企业家来摆摊。我只要预订规则，企业家满足广场的规矩就可以了。我不管你里面怎么操作，店跟店之间没有任何沟通或关系。如果你赚了钱，你就可以继续，没钱赚，你自己也会关门走人，美食广场还是可以不断更新发展，保持吸引力。而建教堂是另一种形式，需要经过几年的精心设计，画大量设计图才能建出来，这种就需要多方不断沟通、协调。所以亚马逊若要继续高速发展，必须用摆地摊的形式，减少沟通。”

从很多实例看到，各自独立的小团队可以创造出具有影响力的新产品。

比如百科全书，以前百科全书都是聘请专家不断更新，所以非常昂贵，只有少数家庭能负担得起。后面有了维基百科，全世界任何人都可以参与去做，就占领了很大的市场。

比如Linux创始人Linus Torvalds也是协同了全世界各地的软件工程师花费3年时间（1991—1994）做出Linux V1.0操作系统，该系统成为互联网界最常用的开源操作系统之一。

亚马逊Web services为各种业务提供针对性的服务，欢迎有创意的小团队加入平台，像美食广场一样，提供平台给人做生意，不需要和其他团队沟通，自负盈亏，有盈利就表示有市场，可以继续发展，亚马逊也可以健康扩大，但如果按建教堂那种形式，各个团队都相互关联，亚马逊是无法快速发展的。

但如果独立单元的功能不像亚马逊小团队那么简单，就可以考虑参考多维组织架构。

企业通常可以从3个维度来划分：

●   按功能（输入单元）

●   按产品或者服务（输出单元或事业部）

●   按市场或者地域（市场单元）

所以企业架构图由三类单元组成：

图B1-3

实例：总经理下面有6个产品服务事业部（见图B1-4），技术中心、人事、策划等支撑这些事业部，每个事业部都是独立的利润中心，所有输入单元都是成本中心，事业部需要承担服务付费，外部市场接口不是利润中心，它主要协调各类市场接口支持事业部的工作，它可以按内部客户（事业部）或外部客户细分。

图B1-4

有些企业可能完全没有市场单元，例如上面专门关注投资项目服务的X公司，所有的市场工作都归到事业部，产品中心是唯一的输入单元（成本中心）。

以上面E公司为例（图B1-2），公司的组织架构也是按输入、输出和市场，营销中心对应市场，业务中心对应输出，都属于利润中心。交付中心、后台中心、财务中心等对应输入，都归属于成本中心。

因研发资源都归属到公用资源，故无法知道某利润中心所花的研发成本，总经理只可以监控各业务部门的季度收入。但如果把公用资源里的工程师具体划分到归属哪个业务部门，业务部门每季度所花的研发成本就很明确了。如果某业务部门有业务增长，但有些业务部门萎缩，总经理便可以重新分配开发人员，避免资源的冗余和浪费。所以使用这种组织架构划分，方便企业应对市场变化，不需要改变总体架构，也可以快速适应市场的变化。

顾问：内部竞争配合系统衡量，企业就能提升效率，健康发展吗？

我：当然不是，但是其中的一个必要条件。请问你遇到过什么问题？

顾问：部门之间不合作，例如开发觉得产品经理未做好需求，测试觉得开发质量差等。

我：你真是经验丰富，很多管理者误以为每个部分做好，整个系统必定会好，没有考虑之间的协作。我就遇到过开发责骂需求没有做好分析，导致无法做开发。或者测试责骂开发不注意质量，大量的缺陷都在测试才发现等。虽然公司设置了很多度量指标去衡量需求、开发、测试，不达标就扣绩效，但还是杜绝不了做项目的时候，不同的功能部门之间的冲突。所以管理层应该主要关注企业各部分之间的交流沟通，而不是单独看每个部分。如果是同级的，就是部门之间的协调。如果是向下级的，就是部门的集成。这是第一点。

如果团队需要包括多种功能，不像亚马逊的独立小团队这么简单，如何能利用多维架构，利润中心、成本中心来减少协调沟通引发的问题?

以前面 E 公司为例，如果将研发资源里的研发人员都归到公用资源池（见图B1-2），那么有经验的软件研发工程师，每个事业部都想占有。负责公用资源池的技术总监是这位有经验的软件研发工程师的领导，资源池里工程师的时间安排应由这位总监负责。你应想到这里牵涉很多协调与沟通问题，导致很多内耗。

如果把工程师安排到事业部，就能减少以上问题。但每个事业部的研发资源每个月都可能会有变化，资源池的负责人应依据每个月各事业部的人员需求策划工程师分配，然后按需求变化，每个月调整。

所以每个事业部都有它的独立团队，但工程师人数会每月调整。也可以很简单地按照安排的工程师人数算出每个事业部的研发成本和每个事业部（利润中心）的毛利。

顾问：明白。

我：第二点是，现在的员工的知识水平比上一个世纪高多了，之前的员工都没有读过太多书，但现在的员工很多都大学水平或更高，所以管理者应该从以前的监督指导的角色转变为赋能、提供环境，让员工去发挥。现在的知识工作者也很厉害，如果一线员工有想法（心里不服上级），任何管理层的措施都将变成无效。

顾问：上有政策，下有对策。

我：各个层级的员工，尤其是“80后”“90后”等，越来越崇尚自由，不喜欢受约束，但在工作环境里上下级的观念却很重，所以越来越多的管理者了解这个趋势，开始在企业里打造一个开放的环境，主要有两个中心点：

●   每个人除非他是罪犯或者精神有问题，都应该能参与决策

●   没有最终的权力者，下属也能影响经理的意见，提出反对意见

但不要误以为组织架构完全是没有层级的，因为还是要协调，所以难做到，但是应该尽量把组织架构扁平化。

顾问：赞同你说的趋势，但如何既有上层级，又说下属可以反对上级的决策，不是自相矛盾？

我：明白你说的问题，但如果把“改进小组”制度化，可以帮助企业打造一个开放循环的环境，也能解决上面第一、二点的问题。

顾问：改进小组？

我：下属员工可以向他们的经理提改进建议，经理可以接受也可以反对，但要解释原因。开始时，可以介入第三方，例如咨询顾问，代表员工把意见汇总给经理，但当下属员工了解了汇报的形式，第二次甚至以后都由员工直接向经理汇报。

顾问：我一直都以为改进小组应该由部门经理领导，没想到改进小组反而可以向领导提改进建议。

我：这才可以形成闭环让改进小组起作用，不然员工都以为改进小组只是经理的手段，巩固经理的管治，改进小组除了包括事业部的经理和他的直接下属，也应该包含经理的上级，因为他也是相关人之一，应该了解小组的建议，改进小组不仅适用于事业部层级，企业的每一层都可以建立改进小组。只是最顶层的可能就只有CEO本身。

顾问：听你这样解释，如果企业每一个层次都成立改进小组，确实能对企业产生很大影响，但估计不是每一位经理都能接受。

图B1-5

我：你说得对，我们只能遵从客户意愿。如果可以，最简单的方式是直接找高层。例如上面提过的A公司做完现场差距分析诊断后，我晚上直接打电话跟技术总监说：“你们公司虽然历史悠久，但团队一直都没有积累经验教训，很可惜。”总监同意，但他确实太忙了，安排我联系他的助手协调4位事业部负责人开会，他们都认为改进小组有用，安排在一个月后做2天的工作坊，让改进小组尽快可以运作起来。

但我也遇到过类似的情况，跟部门经理的直接下属讲解改进小组的好处，他们都很赞同，但补充说最终还要看公司高层的看法。我之后也跟公司高层提过这个建议，他说：“你的建议很不错，但还是让我先问问下面员工的意见。”最后不了了之，所以如果有部门经理与他的下属愿意参加试点，就应尽快启动。开始时，大部分的部门经理会觉得不习惯，觉得有些建议不可思议，但如果能持续一段时间，当他见到团队有显著提升后，他就不会再反对了。

我：如果企业已经分成利润中心和成本中心来衡量每一个单元是否值得存在，是否要被删除，就看单元的表现。成立各层级的改进小组，每个岗位都有机会提意见，不断改善。裁员问题，无论是由于结构性人员过剩或绝对的人员过剩，都应该用系统的思维来分析：把企业看成由很多相对独立的事业部组成，如果某事业部的业务量不足以支撑它的员工成本基础，这个事业部就应该裁员。但如果另外一些事业部有盈利和增长，就应该聘用更多有能力的人支撑业务的扩大发展。而且企业有灵活的多维组织架构，只需要内部调动人手，不需要更改组织架构。如果企业一直有着内部汰弱留强的竞争机制，便不会出现绝对的人员过剩。好比人体，如果内部各器官都健康，就不应出现体重超标。

请问一下，你做了这么多年的培训和咨询，无论是用现有或者自创的方式，你觉得效果如何?

顾问：挺好啊。例如，刚开始只有三四位学员来参加。后面现场也多了几位参加，远程参加的也多了，他们反馈觉得学到了不少东西。

我：我想知道最终客户有什么显著的改善，对业务起到了什么作用，有什么帮助？

顾问：这个我就管不了了。因为做实际的改善改进还是挺长的过程，也需要内部管理层的支持，并提供资源。我只能告诉他们一些最佳实践，他们怎么用，我无法控制。我也不希望企业觉得每次做培训咨询都应该有实际的显著改善，后面如果没有了，他就可能觉得货不对版，反而影响客户的长远合作关系。

我：但客户给我们培训和咨询费，他也希望企业从中有获益，不然他下次就不会做这方面的投资。

顾问：你说得也对。

我：所以我们的最终目标还是希望企业能得到实际的改善，为企业带来价值。

顾问：没错。

我：其实我这些年一直在想，什么主因会影响改进未能给出显著效果。后来慢慢想通了，其一是，改进不够彻底、全面。如果改进只关注最终交付产品（或服务）的质量，未考虑人的因素、公司环境、组织架构等，改进便无法持久。例如我们前面讨论的要加入内部竞争，要有开放循环环境，提高工作环境质量等。

顾问：有道理。

我：其二是，质量可以定义为满足和超越客户的预期，但很多人误以为客户只局限于最终的消费者，但如果把客户广义为除了外部客户，也应包括内部客户，改进才能更全面。例如某产品开发公司的这些软件产品开发出来以后，不一定立马就能让客户真正使用。比如产品部开发了一个新报表，用于某个客户的项目中。客户使用时发现了问题，但因为直接面对用户的并非报表的开发工程师，而是前线另外一组软件工程师，他们就不知如何处理，最后往往就把问题转到产品部，导致可能最终要很长时间才能解决用户遇到的问题，以致客户满意度受影响。但若能更全面地把前线部门也当成客户，每次内部交付都有全面的验收准则，就可以确保不会出现一些问题到客户使用时才发现。如果把下游的部门也当作内部客户，就能减少团队协调与沟通问题。

顾问：确实很多公司有功能部门间的问题。

我：其三是，误以为已经了解了客户的需求。因为新产品开发是依据产品经理写的产品需求来开发的，但是那些需求是否确实是客户要的功能，这是关键。往往因为产品经理并非实际的用户，不一定很了解。但如果能让用户参与设计，效果会更好。比如要开发一款未来的手机，可以使用工作坊的形式，邀请了一些相关的用户来参与设计，他们其实不用很懂软件或者工程，只需要从用户的角度来提出需求，因为他天天都使用电话或手机，很清楚需要什么功能。这个角色更可以反映最终的用户要求，依据这个传达给工程师去开发，整个效果会更好，这样就能避免开发出一些客户不需要的东西。最后一点，如果没有可衡量的数据就无法改进。如果公司缺乏系统，便没有客观数字反映情况，管理单凭经验是无法判断或者无法做出好的决策的。比如公司没有项目管理系统，管理者与项目组都无法了解项目目前延误了多少，往往要等到项目结束才知道。

顾问：确实有不少公司存在这类问题。

我：以前，当培训课上只有两三位学员参加，也不积极听课时，我会怀疑培训设计与准备存在不足。后来，当对公司架构、公司环境与制度、项目管理等了解更多后，我便明白了做研发的人都很聪明，他们很清楚公司的管理模式，了解到学了一些好方法也不一定能在团队里用上。如果我处于他们的位置，也会做出同样的反应。

顾问：我也有遇到过你说的情况，听完你的分析后，理解企业要持续改进，公司的环境、价值观都要配合。

我：所以在讲敏捷开发课程时，我都会从2000年的谷歌案例开始讲，虽然当时谷歌公司还在起步阶段，但已具备前面提到的关键要素，加上公司招聘新人要求非常高，所以当年的谷歌人都是很有能力的A级球员。

顾问：我接触客户，尤其是做产品的，越来越多用敏捷或者迭代的方式快速交付，我做咨询本来想从一些标准的模型或者方法去辅导他们，因为我觉得他们很多时候都没有用好迭代或敏捷来改善开发工作，没有获得本应的效果。

我：你参考过哪些模型、方法？

顾问：SCRUM、极限编程（XP）和SAFe。

我：你有没有发现你刚才说的几个方式都有一个共同点，就是都偏技术。例如SCRUM主要偏重项目管理，因为创始人之一Ken Schwaber是飞行员，因先做好项目管理让团队更容易取得效果，SCRUM主要关注项目管理，他常用如何把飞机安全起飞下降控制好来比喻如何管理项目。

极限编程XP是Kent Beck提出来的，他本身是一位很优秀的Smalltalk程序员，很熟悉面向对象开发，所以他的极限编程偏向于开发技术方面。XP源自他1996年开始的C3项目咨询经验。美国佳是拿（Chrysler）汽车公司从1994年开始开发新系统，内部简称C3项目，替代基于Cobol编写的旧的付薪水系统，目标到1999年能处理公司8.7万员工的薪水发放。1994年开始用Smalltalk开发，但一直进展缓慢，1996年Kent Beck作为顾问加入，引进了多种软件开发实践，开发速度立马提升，并估计能在12个月后发布第一版，最后只是延迟了几个月，1997年上线时能支持大约一万员工的薪水发放，它基于这个成功项目总结成XP，并在其他项目中使用。

所以你参考的敏捷模型和实践，都是偏于技术方面的，但我们前面讨论过，技术只是影响改进的其中一个元素，如果没有考虑人的因素、动力、奖罚等，还是难以取得效果的。

顾问：赞同。

我：如果我们问有经验的研发主管“要做好软件开发项目，最大的困难是什么？”，以我的经验，超过八成研发主管都会说是需求。但如果我们仔细看你刚才说的那些模型或实践，只是强调要跟客户代表或者产品经理一起面对面沟通，按产品经理的思路开发出有价值的产品。但如果产品经理本身就不清楚产品的重点价值，就难以做出优秀的产品。所以，当我给客户培训需求时，会强调不仅仅是听客户说要做什么功能，更应该把自己定位成业务分析师，从业务的角度最终希望产生什么价值，从业务的角度出发来制定产品应该开发哪些重要功能。也可以用上面提过的方式，指导客户做工作坊，让所有利益相关人一起参与设计。现在大部分的项目都会利用原型图，与客户确认沟通。但很多团队还没有把那些原型图配合场景（场景就是什么人完成什么任务），以方便客户或用户更容易理解。上面说到很多产品团队，他们开发了新版本产品后，只有简单做了内部验收，也没有立马发给客户使用，导致缺陷在客户使用时才暴露。

SAFe把前面SCRUM、XP都加进来，在上面添加了价值流、精益等思想，作为一个框架，希望帮企业利用敏捷从团队扩大到企业使用。但这些偏技术的模型、最佳实践或框架能打动管理者吗？很难。不少高层是不懂软件开发的，他们心想：“这些偏技术的，我听不懂。”比如SAFe框架列举出很多敏捷开发的规定或最佳实践，理论上可以指导小团队发展到企业。SAFe 4.0版本把能接触到的团队的最佳实践都放在里面，portfolio、programme等各个层次，非常全面。但是看完以后，我想到一个问题：企业家怎么使用它呢？

除了利用这些技术框架、最佳实践以外，加上简单管理学的组织架构，加强内部竞争，分割成独立的单元，自主盈亏等，对管理层才更有说服力。如果只讲技术不讲管理，企业内部员工还是没有动力，也做不出什么改进。

所以若要帮助团队更好地用上敏捷开发，还是应先考虑前面讨论过的3点：

●   不仅需要考虑产品质量，还要全面考虑整个系统，包括人

●   除了关注外部客户，也要考虑内部

●   全面考虑需求，不仅仅是产品功能

各位读者，让我们一起利用下列简化图，回顾上面对话覆盖的范围，取得更全的视角：

图B1-6

0 避免裁员（人员能力与动力）
1 需要加入内部竞争（报酬）
2 利用管理工具监控项目的成本与进度偏差（工具）
3 把单元分成利润中心或成本中心（组织结构）
4 亚马逊创始人提倡小团队，减少沟通（部门间的协调、上下级的集成），以便公司能快速发展（组织结构）
5 公司架构都可以分成输入、输出和市场三类单元（结构），并归属到利润中心或成本中心
6 这种多维架构让企业可以快速调配部门的资源分配，适应市场变化（结构）
7 每个层级的部门都可以组成改进小组（人员能力与动力）

7.1 逐步形成每位员工都可以提出改进意见的循环环境

7.2 举办2天工作坊加快各事业部开展改进小组试点

8 配合内部Wiki平台，帮助团队持续学习（团队学习）
9 过程改进的常见问题

9.1 未充分考虑与人相关的因素（报酬、组织结构、动力）

9.2 未充分考虑内部客户（产品、服务）

9.3 误解客户需求（产品、服务）

9.4 最后讨论3个常用敏捷开发实践，它们主要覆盖产品、服务

从这个简化图看到，虽然产品服务很重要，但不是全部，其他的地方出现问题都会产生影响。如果我们使用系统思维把范围扩大，才能更全面看到问题所在和之间的相互影响：

图B1-7

大部分软件开发的模型、最佳实践等，如SCRUM、XP都是偏技术方面的，只覆盖图中的“产品、服务”部分，虽然很重要，但如果周围的系统不配合，也难以取得改进效果。

如果咨询顾问只关注软件开发技术问题，很可能只能在短期内做出效果，难以持久。但如果能扩大范围更全面分析企业的问题，才有机会引起高层的关注，团队和企业的改进才有机会延续。

从另一个角度来看，系统思维能扩大咨询顾问的视野，帮助他更全面地预估能帮助公司持续改进的机会有多大。

从2014年开始做敏捷开发ACP培训，我便引用埃里克·施密特（Eric Schmidt）当年出版的 How Google Works（《谷歌是如何运营的》）里的故事。

当我写完这篇初稿，便想起那些谷歌故事，再次翻开书的目录，发现从第一章到第六章几乎都可以落到图B1-7中，而且大部分是围绕“产品、服务”。

例如第一章讲文化层面：

●   7的法则，不要自扫门前雪，“2个比萨”原则，重组是关键等，都与组织结构相关。

●   别听“河马”的话，驱逐恶棍，保护明星，跟我来，以领袖人物为中心，不能作恶等，都与人相关

整个第三章“人才”，从招聘、宁缺毋滥、报酬等都是关于人的。

第四章“决策”和第六章“创新的故事”，除了落在“产品、服务”以外，也覆盖到目的，工具和人的地方列举了部分故事，如下图：

图B1-8

2001年，埃里克·施密特开始就任谷歌首席执行官。他从1983年开始在太阳公司工作，到1997年当Novell公司的首席执行官，18年里的大部分时间都是管理者，所以他很清楚应该关注哪些重点。

谷歌从2000年时的一家几百人的新创公司，凭着巨大创新能力，已经成为当今互联网世界级超大公司。所以公司若要提高创新能力，也必须注意这些地方。

虽然Kent Beck大师1996—1997年使用XP实践帮助开发团队在一年多时间内完成了第一版发布，但随着他完成了接近2年的咨询工作，离开了项目，后面系统的扩大便停滞不前，最终在2000年时C3项目正式被取消。