在解决方案初步合格后，仍然有很多细节问题需要其挖掘和弥补，才能锤炼出成熟的解决方案。研发改进的实施经历表明：几乎每个解决方案在实施和推行过程中都需要不断调整，才能日臻成熟。但是，如果以“即使考虑再全面，以后都需要改”为借口，对解决方案敷衍了事、妄图蒙混过关，将不成熟的解决方案去贸然实施，一旦出现重大问题，将会令改进工作搁置，根本没有调整的机会。

在问题挖掘时，需要经过实施细节论证、干系人分析、配套资源评估、影响分析四个步骤。如图4-4所示。

图4-4问题挖掘的四个步骤

◎​ 实施细节论证

任何解决方案都需要去实施，那么索性就让它在脑海里，或是虚拟环境里实施一下。我们可以选择几个有代表性的业务骨干，将解决方案/流程制度当成剧本，模拟着运行一下，时间可以很短，活动可以不充分，像彩排一样。只要仔细观察运行的过程，就能够发现其中不顺畅、不合理的地方。

当然最简单、最经济的方式，就是你一个人分别扮演若干个角色，在脑海里将解决方案完整地执行一遍，琢磨过程是否连贯、考虑每个角色内心的真实感受。就像运行程序出现BUG一样，将发现的问题记录下来，作为后续完善的目标。

在论证实施细节时，我们会关注如下几个典型问题：

​ 这个解决方案的实施细节、具体步骤是什么？

​ 在具体实施中会遇到哪些困难？如何克服或者规避？

​ 实施工作是否缺乏某些必要的支撑工具或者资源？

​ 在实施过程中，哪些人会反对？是否意味着解决方案存在缺陷？

通过实施细节的模拟，上述问题都有了明确且令人信服的答案，这说明解决方案在细节上是经得起推敲的。下面的案例展示了这一过程：

某公司引入集成产品开发体系，技术评审制度的建立是其中重要的组成部分。解决方案中明确规定，在产品研发流程中设置了若干技术评审点，并且对技术评审的执行过程、参与角色、评审要素都做了具体定义。

该公司组织研发管理和技术骨干，对技术评审制度进行细致的研讨。下面就是大家的主要意见。

项目经理首先提问：“在制定项目计划时，就需要考虑将技术评审作为计划的一部分，需要多长时间呢？”按照规范要求，一次典型的评审过程需要3~5天。项目经理对此提出异议：项目周期这么紧张，根本无法为每个技术评审留出这么长的时间！

技术专家也提出：“很多项目并不复杂，没有必要把每个技术评审都做得非常充分，只有复杂的产品才需要这样！”

对于制度中要求“在评审之前，需要将评审材料准备好，不能出现低级错误，否则将会影响评审效率”一项，项目经理指出：“在这里，肯定需要有人对评审材料的质量把关！”同时问：“谁来确定评审专家？哪些人可以作为评审专家？你选择人家，人家不乐意或者没时间怎么办？”

评审专家搞定后，就要将评审计划和评审材料发给专家。流程上规定评审专家及时反馈评审意见，防止出现没有准备就去参加评审会的情况。QA对此表示担忧：“评审专家不反馈或者在敷衍怎么办？”

……

咨询师将技术评审的全过程一幕一幕地展现出来，并在会后反复查看会议记录，总结当前解决方案存在的问题。原本以为这是个比较成熟的解决方案，在总体逻辑和操作细节方面应该不会有重大缺陷，谁想问题多得出乎预料：

​ 需要根据不同项目类型设置技术评审点，而不是一刀切；

​ 专人负责评审材料不能出现低级错误；

​ 常常找来评审专家并不称职，导致评审效果很差；

​ 公司是否可以对评审工作有激励措施，督促大家关注评审；

​ 有什么办法可以提醒评审专家投入精力去检查评审材料，并反馈有价值的意见呢？

​ ……

在制定解决方案时，改进者很容易从大处着手，高屋建瓴，忽略了这些不起眼的小问题。如果这些问题没有处理好，将使得实施效果大打折扣，甚至根本无法实施。通过实施细节的论证，可以提前发现实施中遇到的多数问题，从而有针对性地完善解决方案。

◎​ 干系人分析

干系人的能力和意愿决定了解决方案是否能够被落实到位。由于多数的企业并非拥有军队一样强悍的执行力，研发体系的管理者也没有生杀予夺的权力去驱使大家改变原来习惯的工作方式，因此在完善方案时必须要考虑主要干系人的实际态度。

哪些人属于主要干系人呢？一个寓言故事就说明了这一点。

一只母鸡和一头猪是朋友。一次，两位商量着要合作项目。

鸡说：“咱俩关系这么好，合作点项目吧？”

猪说：“合作什么项目？”

鸡说：“我考察市场，咱俩合作鸡蛋火腿肠项目，一定畅销。”

于是在鸡的动员下，猪就经过思考签了协议，生产鸡蛋火腿肠，而且还做了法律公证。

这个协议签完了，会发生什么事情呢？鸡回去下蛋就可以了，猪却要献出生命啊！

在这个故事中，母鸡和猪都是干系人，不过重要程度不同：猪需要全情投入、舍命相助；母鸡只是负责摇旗呐喊，不必做关键性的付出。由此可见，猪的角色就是主要干系人，必须在解决方案中对其予以足够重视。

IBM日本总部曾发生过一个著名的“东京事件”，起因是IBM东京公司高层决定秘密重奖几位工作出色的骨干分子。这在美国IBM本部也是一种例行的激励手段，但让管理层意想不到的是，领奖的几个人刚走不久，一些没有得到奖励的人就跑来要求辞职。

他们这么做倒不是闹情绪，原因很简单：别人被重奖，而自己没有得到奖励，证明自己工作成绩不突出，得不到领导认可，继续“混”下去没劲儿，还不如自己知趣点，主动申请走人，免得日后被老板裁掉那么尴尬。

令管理层想不到的是，等这些人刚走，那些受到奖励的人又跑来要求辞职！原因更简单：由于自己被老板重奖的原因，害得同事们丢了饭碗；而同事因此辞职又害得公司工作陷入被动。所以，既对不起同事也对不起公司，只好坚决辞职，以谢同事和公司。

IBM的东京高层并没有意识到员工之间具有如此之深的认同感，以致重奖少数“功臣”的同时挤走多数的“群众”。由此可见，对干系人意图的充分了解，不能仅仅停留在口头上。

对于研发体系改进而言，主要的干系人包括赞助者、执行者、监督者和重要旁观者四类角色，他们具有完全不同的业务诉求。如表4-4所示。

表4-4干系人的业务诉求

在实际工作中，主要干系人的意愿和能力对方案落实具有决定性影响，而各类干系人的影响程度也不尽相同。比如对于执行者而言，是否具备足够的业务能力是体系运行的根本保证，同时也需要积极的态度。而对于赞助者而言，其坚定的推行意愿就显得尤为重要。针对不同的解决方案、解决方案的不同模块，干系人的能力和意愿都可能有所差别，需要对此仔细分析，采取积极措施去弥补关键性的差距。

表4-5展现了一个简要样例。

表4-5能力和意愿对方案落实的影响

某软件开发公司，在推广编程规范的过程中，就充分考虑了主要干系人的切实情况，采取一系列有针对性的措施，打消了各方面的顾虑，在短期内达到了改进目标。

该公司在长期软件研发过程中，一直没有对编程规范进行明确要求，这样对产品稳定性、维护性带来不小的麻烦。于是该公司决定严格推行编程规范：《编程规范》撰写好后，通过了小范围适用，接下来就是如何进行全员推广。

不妨对主要干系人进行具体分析。如表4-6所示。

表4-6主要干系人的主要观点

在软件公司里，遵循编程规范是基础要求。对软件工程师来讲，并非提出了难以企及的技能要求；工程师从熟悉规范到遵循，大约需要一周时间。咨询师得出的结论就是，从技能方面来讲并不存在障碍，主要阻力来自于大家的心态。

针对赞助者的顾虑，实际上是不存在的。目前尽管工程师的工作压力较大，但工作氛围尚可，不存在成规模离职的可能性；推广工作难度较小，不会诱发不满，可以通过沟通打消赞助者的顾虑。

针对工程师的反对，主要源于改变工作习惯的不满，但是通过适当地引导和督促，并非不可逾越。值得注意的是，该公司一直以来温和的管理方式，使得任何一项制度的推行过程都比较漫长，如何克服惰性才是关键。

综上分析，可以采取“软硬兼施”的策略进行编程规范的推行工作，解决方案的具体步骤如下：

​ 组织业务骨干对《编程规范》进行集中评审，以供软件工程师和QA去遵循和使用；

​ 责成研发骨干在公司范围对《编程规范》进行培训，使大家对规范要求有准确理解；同时结合以往的典型质量案例，传递统一编程规范的重要意义；

​ 要求在统一的时间点，实施新版的《编程规范》，项目组内部互相检查，QA进行抽查，通报所发现的不符合项，为期一周；

​ 在第二周，继续项目组互检和QA抽查的工作，对于发现的不符合项进行公司范围的通报批评；

​ 从第三周开始，进行项目组之间的互检/抽检，QA负责组织，对于不遵循规范者进行停职培训，所在项目绩效降级处理。

在上述案例的解决方案中，由于充分考虑了主要干系人的切身感受，同时也没有一味迁就，在短时间内顺利完成了改善目标。

◎​ 配套资源评估

标杆公司的研发体系令人耳目一新、运作协调顺畅，仿佛研发出高质量产品就成了顺理成章的事情。事实上，产品成功的背后，充足的资源投入是必不可少的。同样的，改善解决方案时也应该评估企业的承担能力。主要的配套资源包括如下四类：