背景：

前面在B1里已经提到过这家X公司，它的组织架构见图B1-1。

我：非常感谢您给我时间，请先让我了解你们的产品和今年的发展方向。

总经理：我们公司已经成立了超过10年，覆盖了国内几个主要省份，客户都是中大型企业，业务主要提供金融相关的产品和服务，帮助他们更有效地管理投资。

我：你们公司在这么短的时间内能把业务开展到现在的状态已经很难得了。

总经理：确实不容易。比如刚开始的时候，我们的产品中心只有几位技术人员，现在已经接近20人了。

我：大概了解了。可否简单介绍一下你们的商业模式与公司组织架构？

总经理便用水笔在白板上画出他下面有3个事业部，加上产品中心。

我：请问现在如何监控3个事业部的绩效？

总经理：因为事业部之间相互独立，从财务部门就可以看到每个事业部的收入。事业部的成本主要是人力成本，所以整个公司的产品中心是公司的成本中心，产品中心专注通用的产品功能（我们只有一个产品）。如果某客户有定制报表或特殊功能需求，就会有事业部内的项目组负责。

我：很简单，也很清楚。所以每个事业部的负责人和你都能知道当前的利润如何？

总经理：如果有什么项目和管理问题，我都会先让事业部和产品中心处理，大部分权力都会下放到业务部里面的项目经理，我主要是每个月看他们的结果，如果都有满足要求的盈利，客户也没有什么投诉，除非某些会影响到公司的总体利益，否则我一般都不会插手。

我：很明智的策略，这样做公司才容易扩大与发展。

总经理：是的。事业部开始时，也都是几个人，现在都已经到了六七十人，整个公司人数超过两百。

我：可否请教一个核心问题？

总经理：可以，如果我能解答。

我：请问你们公司的最核心竞争力是什么？

总经理：当然是我们的产品。

我：我估计也是，你觉得现在的产品如何？满意吗？

总经理：虽然我不懂软件开发，但对产品应否添加某些功能我管得还是很严的。产品的新功能还是靠我们的现有客户提出来，先由事业部过滤是否应添加到我们的标准产品，如果只是某个客户的特殊需求，就只会让事业部自己为客户做小规模定制开发。

我：前两天我和你们的产品中心各岗位人员交流过，基本了解产品定期6—8周发新版的过程，与几年前比较，会不会觉得现在要增加一些新功能所花的时间比以前长。

总经理：确实有一些，比如最近有个很重要的新功能，原本计划可以在4个月前，就是5月份发版，但到现在还是有些缺陷未解决而未能发布。

我：你描述的这种情况，我确实在其他产品公司看见过。你乐意听听吗？

总经理：当然。

我：这家公司是专门为公共网络供应商提供家庭用户可以在家里付费看电影的系统，因为他们提供的软件系统要部署在网络商的服务器上，软件的新功能更新都有统一规定，新软件必须满足质量要求才允许‘切割’上服务器，为了降低对生产系统的影响，每两周才允许系统软件更新。为了不影响用户体验，每次切割都会在深夜，且必须先通过网络供应商一系列的测试，才能更新，如果不成功，就要再等两周到下一轮。

系统刚开发完成的前两年操作都很顺利，代码数量与最终用户数量都不算多，但这家公司的这套软件产品已经不断更新了接近10年，他们的开发人员发现要更新软件产品的功能越来越困难。软件与硬件不一样，软件可以修改代码，产生新功能，但这也是隐患，如果代码修改不对（有缺陷），未必立马报错，但隐患越积越多，后面就越难做维护与更新。做维护的工程师（因为很多代码不是他自己设计和写的），甚至不敢动核心代码的任何一条，如果要添加新功能，只能在周边加上，这种我们就叫“死”软件。

总经理：虽然我不懂软件，但也大概能想象出来你说的问题。

我：其实你们产品的情况绝对没有像刚才我说的那家公司那么严重，最主要的原因是你们产品中心的经理张总很熟悉整个软件产品的架构设计，开发人员的所有修正都要经过他的审批，所以严重的大问题应该可以受控。但他精力有限，有些不会立马直接影响软件功能的问题可能就会累积在你们的系统里，会让后面的维护越来越困难和耗时。

总经理：所以你刚才问我现在的功能更新是否比以前慢？

我：请问你觉得需要在这方面做改善吗？

总经理：这个软件产品是我们公司的核心，肯定要投入精力避免问题越来越严重。

我：听你这么说，我后面尽快跟张工谈谈，与他商量下一步如何逐步帮助团队开展些试点做改进，请张工每个月跟你汇报一下计划与进展。

关键经验教训

●   因为人都不喜欢问题，所以尽量正面地认同公司过去10多年的成就

●   扩大讨论范围包括企业的整个系统，包括组织架构、事业部的决策与监控等，才能接近老板的视角（因他不熟悉软件开发）

●   因为老板非技术出身，要避免从软件开发、质量等方面去讨论，而是引发他注意到公司最重要的资产是他们的软件产品

●   引起他的风险意识，指出现在软件产品的各种潜在危机（因不注重质量与可读性），主要说明因为开发团队扩大了，不能再用以前的作坊式管理，但也要肯定产品经理（技术负责人）的成就与贡献

背景：

●   主要依赖与客户的多年关系，加上市场营销等手段来提高业务增长

●   公司有多个产品线，都是由不到20人的公用资源池做技术支持

●   虽然技术难度比X公司低，但其实风险比X公司高，例如，如果某产品出现问题，因为一直都没有专职团队维护，所以可能会花很长时间才能找出问题并解决

●   虽然公司有自己的产品，但管理层不注重研发质量，后面会越来越难保持竞争力

●   管理层不关注公司的改进能力、创新能力

●   整个集团很大，利益相关者很多，这种环境导致就算企业里有能力的人当领袖，也难以带动改革（公司文化注重服从性）

总经理：我确实不懂软件开发，但如果你有关于技术的问题，我可以再安排一位懂技术的经理与你对话。

我：谢谢，暂时不用。你愿意给时间让我有机会了解贵公司的情况，帮助已经很大了，我们可否从公司的业务和组织架构开始，让我初步了解一下。

总经理在白板上介绍主要部门，有些是内部支持，有些是对外，他们主要是给政府做人保和医保业务，公司成立至今有20年历史，是集团下面的分公司，还有其他分公司提供一些专项服务，例如提供医保人脸识别设备。

我：你们管理层关注下面团队的哪方面，换句话说，比如希望哪些方面有提升？

总经理：效率和质量。

我：你们平常如何策划和监控项目？

总经理：用脑图把功能和日期标示出来，再做一些每周监控计划。相关负责人通过Excel表格把大计划分解成具体任务，并标注目标的截止时间、实际完成时间。我们就按这个表格每周回顾进展。

我：可以举个实例，投影看看具体如何操作。

总经理：好的。

经理展示脑图、Excel表格，Excel右边有一列标注了计划完成日期，它旁边一列标注实际完成日期。

我：我看这个项目的日期都是比计划日期延后2—3周，原因是什么？

总经理：以这个项目为例，中间有些变化，比如有些需求变化，需要增加工作量，有些项目中间插入了一些其他更紧急的任务，开发人员需要先处理。这些项目经理也汇报了，然后把计划延后了一段时间。

我：为什么你觉得他从原来的6月19日延迟到7月19日是合理的，是否这已经是最佳安排？负责的项目经理是否提供了一个依据，你也很难判断这个新日期是否合理？假如在学校，老师安排你周五交作业，你会什么时候交呢？

总经理：周五放学前。

我：大部分人会在截止日期前。所以这个时间有很多水分，会预留一些多一点的缓冲时间。项目经理汇报的预计完成日期也一样。在做好项目管理的前提下，这中间有很大的提升空间。所以我们需要先把项目分解成小任务，每个小任务不超过5天才好控制。这样整个计划才明确，后面才好监控。

总经理：是的。

我：以此为例，脑图是很粗略的，还是需要分解任务。这样就可以要求项目经理提供具体的理由，为什么要到7月19日？中间有什么任务？这样才能把策划做得更好。

有了具体的计划，监控实际与计划的对比也是非常重要的。因为没有监控的话，下面做项目的人就很自然会有延误。如果管理层也不关注，就起不了监督的作用。比如你现在是怎么监控实际与计划的对比的？

总经理：我们就每周看脑图，原本计划的日期，它现在是多少，然后如果有更新的话就更新，比如刚才这种。

我：你还记得你这个项目到现在为止跟最初的时间相比，延迟了多少？我估计你是无法记得住的。Excel表的好处是非常灵活，但是它最大的毛病是在做项目管理的时候，任何人都能很容易不留痕迹地修改内容。所以从你现在的Excel表中是无法知道最初定的时间的，目前延误了多少也没有任何统计。但是如果有项目管理工具，它就会把计划和实际记录下来，而且修改是有痕迹的。这样就起到了很大的作用，项目经理也知道原本承诺的日期，现在是有痕迹的，就会更注意，尽量不会延误。他下面的成员也是一样的。所以我们说，如果单靠Excel表、人去监督，很费劲，且不如一个WBS项目管理工具起到的作用好。

总经理：其实我们的OA系统里面有个报工功能，我们也要求我们的员工按照我们的计划任务去填报工。

我：好啊，我想看看你们现在是怎么做的，让我学习一下。

经理就开始展示他们的报工系统，比如某个任务是某个项目的一部分，写了42人时和截止时间。然后经理也展示了报工后，实际显示的是多少。

我（看了两三行以后）问：我们看看前面两行，有没有发现他们报工的工时跟完成预期都跟你计划的完全一样？有两个可能的原因，一个就是确实他们是准时的，按42人时做完了，也确实是那天完成的。另外一个可能就是他们知道你们管理层是无法知道真实情况的，既然计划这么写，他们就按计划报。你觉得是哪个原因呢？

总经理：我懂你的意思了。其实我们这个系统无法起到监控的作用，随便他们怎么填写，我从管理层的角度是难以判断是否正确的。

我：你说得很对。所以通常项目管理系统需要有防止这种随便填报的功能，就是每个任务都应该有明确的产出物。比如开发某个组件，产出物就是相应的代码。如果是做测试，可能用了3个小时，就应该产出一堆测试用例、文档。然后这些产出物需要有人确认是否完成，系统才允许这个任务相关人填写任务完成时间。这样的话，系统就会帮助经理确保人员填写的时候会按实际去填，因为知道如果随便填，实际没完成，就过不了内部的评审。

总经理：你说的方式还是挺有道理的，但是现在那些开发人员都非常忙，再要求他们做评审，做相互监督，填写这些工时表，他们可能会有意见，很难推动。

我：我懂你的意思，也确实有些公司开始推动这种工具的话，有很大的反弹。甚至有些工具买了，后面因为员工反对也推不动，因为改变员工的习惯是非常困难的。但是也有些成功的例子，我们可以参考一下。比如，我们这种系统报工，可以把报工的颗粒度宽松一点。比如我要求把颗粒度放到一周，甚至两周，才需要填写一次。那些评审也一样，这有个好处，就是对他来讲，那种额外占用的时间少了，但是对管理层来讲，还是起到了监工的作用。尤其是如果你们开始管理项目的预算，没有这种系统的话，是无法知道项目在开展的过程中有没有延误的。比如之前，你展示过你们的OA系统，也有相对预算，比如人工是8万元，采购设备是7.5万元等。但是你有没有发现你们的系统是无法让你知道这几个月的进展中有没有延误的，只能从财务的角度统计项目结束后的实际人工是多少。而通常到那个时候已经太晚了，但是如果你有刚才那种项目管理系统的话，你就可以在每一个里程碑发现有没有延误，延误了多少，是否需要采取行动。这样的话就可以把项目延误控制住，也可以通过一个最好的方式帮你提升效率，因为你也希望提高公司的效率。软件开发最大的成本就是人工成本，所以在这方面将效率提升很多。我看过有些成功使用项目管理系统的公司，他们的收入都是靠项目，以前没用工具的时候，项目是有盈有亏的，业绩不太好，虽然是上市公司但差不多要解散了。后面新的总经理入职后严格要求项目要填在系统里进行预算、监控，然后基本上每个项目都不会亏钱了，业绩也做出来了，所以这个效果是很明显的。这个系统可以按不同工种、人天来进行成本结算。虽然你们现在的OA系统也有，但是没有项目管理的功能，所以还是不会有效果的。如果你的团队比较厉害，每两周有冲刺、迭代，就可以在每个两周迭代里面做任务计划和监控，其实就不需要用项目管理去做，因为每个任务是半天、一天、两天，如果要写在工具里面，可能员工会觉得反感。这种短期的策划和监控，其实完全可以在一个白板或者大白纸上面画上计划和实际，效果不会比用系统来管理的差。这样也可以避免有些员工觉得每次都要把任务写在系统里，太死板、太浪费时间了。

图B2-1

下面解释A到G的具体任务：

图B2-2

例如，A任务本来预估要16人时，然后按1天8小时简化为2人天，安排李工周四和周五2天完成。

关键经验教训

前面与各岗位交流、诊断，已了解到公司当前的问题，但也了解到集团里相关人较多，很多问题非总经理个人可以解决的，所以策略集中在项目策划与监控阶段。如：

●   项目策划与监控都缺乏系统/工具（只靠Excel表），导致项目延误，超支是常态

这也是总经理最关注的。精力与资源有限，每一点都改进还不如针对项目管理，如执行，应很快就能看到显著效果。

背景：

公司专攻地质、采矿IT系统，没有自己的软件产品，一直以为客户做项目为主要收入。

跟X公司和E公司不同，S公司的员工都很积极，第一天培训便有10多人抽空来参加，下午做互动小组练习时，也一直没有离开，后面发现里面包括中层经理、开发主管、测试人员等。

我每天都会八点三十分之前到现场准备，培训室在大楼的最高层12层，公司的总经理万总办公室也在同一层。

第一天早上，虽然还没有正式介绍，早上万总碰到我的时候，都会客气地说辛苦你了。

我估计他年纪比我小一点，但应该接近60岁了，个子不高，平头，面带笑容，看起来比较随和。

后面正式会面后，我们进行了以下对话：

我：我看你们员工的积极性还是很高的。

万总：对，我们的员工还是不错的，虽然我们公司不是在一线城市，难以招到顶尖员工，但他们都很有进取心，都希望帮公司做大做强。

后面我了解到他们员工都能分到一些公司股份。

我：员工是公司最重要的资源，你们能做到这样已经很不错了，我看你们公司在这个行业已经做了很多年了，一直都专注这个地质采矿IT服务行业，但从长远来看，不希望仅仅只是提供IT和软件开发服务的话，为客户做定制化项目，必须要有自己的产品，不然公司只能靠员工的辛劳盈利，利润有限。

发现万总的微笑开始消失。

他接着说：10年前我们原本是行业的领先，很多出名的客户都是依照我们的标准来做，但可是后来有了一些大型软件公司加入竞争，他们的软件接口反而成了好几个省的标准，现在我们做项目反而要听他们的，对接他们的标准接口。

当听他说到这里时，我估计他已经没有动力去开发公司自己的产品或框架。感觉万总已经没有信心像公司起步时那样充满朝气了，现在只想把公司维持下去，所以已经有一种“老人”心态，没有兴趣再挑战自己，学习新的东西，这倒成了公司发展的最大障碍。

关键经验教训

●   公司刚创业时，领导还年轻，有活力、有抱负，并有领袖力，员工乐意追随公司文化，比较开放，所以感觉到员工的参与积极性都比较高

●   遇到强大的竞争对手后，屡次失败，领导便失去信心，逐渐故步自封，成了公司健康发展的阻碍

●   公司总体文化还是比较传统的，注重对领导的服从性，这会影响公司的创新能力和对环境变化的适应

如今，领导越接近退休越没有改革的动力，预计企业会最终无法适应市场变化而消失

如果老板有软件开发经验，能了解软件开发的困难和风险，那么可以尝试用缺陷前移提高质量，并能减少返工，提高生产率来说服老板。

在我编著的《A++敏捷开发实践》里，就写了如何尽早发现并排除软件缺陷，提高最后交付客服软件的质量并减少返工，最终提高团队生产效率。

但如果老板没有软件开发经验，公司有自己研发的产品，就可以用风险管理来跟老板说明，如果不尽快提升软件开发的质量，早晚会出事，到时候可能就太晚了（见案例1）。

上一章（B1）讲到要宏观看待整个系统，可以帮助总体整顿企业的问题。虽然很多地方可以做改进，但必须先抓重点。例如，如果老板关注效率，而且没有软件开发经验，就可以从项目管理、成本管理入手，这样成功的机会较大（见案例2）。

跟销售做营销一样，不可能与每一位潜在客户都成功签单。所以，如果公司老板本身没有动力，或者组织架构存在很多限制，又有很多利益相关者，不是老板一个人可以决定的，公司不是做产品，只是做定制开发，那么说服老板改变习惯支持改善会非常困难，几乎不可能（案例3）。

开始跟X公司和E公司的领导交流时，感觉到他们都是首次听到我这样直接的意见。他们天天都在这个环境里工作，难以识别出不足，但我们做咨询、培训的，接触的公司多，问几个问题就能得出初步判断，这也是咨询服务能提供给企业的重要价值。