对研发体系进行信息收集，就像为其做体检，目的是全面了解研发体系的客观现状。信息收集时，一方面需要有明确目的性的主动出击；另一方面需要冷静倾听，尽量减少调研者自身偏见的不当投射。下面是信息收集的典型方法：

◎​ 发放问卷

研发体系调研问卷一般涉及战略与规划、研发流程、项目管理、组织结构、绩效管理等内容，发放至研发业务骨干，目的是通过量化形式展现企业的研发体系现状。这些数据也可以在调研报告中使用，以说明某项问题。

问卷调研结果直接展现出研发骨干对各类问题的关注程度和严重程度，可以使改进者对企业研发体系有一个量化的了解。比如“68%的人员认为没有人对产品的市场成功负责”和“55%的人员认为项目经理缺乏足够的权力”，将会促使改进者将调研重点聚焦于产品规划、项目经理责任制等领域，开展更加深入的挖掘。

在设计调研问卷时，一般以优秀的研发管理体系和实践（如CMMI、IPD等）为依据，结合企业的实际情况进行设计。如果没有对“标准问卷”进行适应性的调整，将会出现水土不服的情况，甚至引起误解。比如某调研问题为“公司产品开发是否具有明确的路标指引”，但是接受调研公司的业务模式是以客户定制为主，并没有“路标”这一概念，显然这样的问题对该公司而言缺乏实际意义。因此，为了发挥调研问卷的真正价值，最好是在对企业有一定的了解后，调整问卷以适应当前企业。

问卷统计结果需要和其他调研信息结合起来进行分析才有意义。改进者不能仅凭一系列的统计数据，去断定研发体系的运作效率和重要问题。

在回答“项目开发过程中是否感到需求变化太多”的问题时，30%的人员回答是“很多，难于应付”，40%的人员回答是“较多，可以应付”，10%的人员回答是“少”，20%的人员回答是“没有”。

从上述统计结果来看，70%的受访者认为需求变化引起的问题并不严重。那么能否断定该公司在需求变更的问题上表现不错呢？这个问题目前下结论为时尚早，需要结合相关信息才能做出判断。可以设想这样一个场景：该公司包括两类项目，其中自主研发项目中的需求变更矛盾并不突出；而定制项目却饱受客户不断调整需求的困扰。而在问卷反馈人员中，参与定制项目的人员比例偏低，调研结果则无法反映真实情况。

在回答“项目立项是否有明确的流程”的问题时，30%的人员回答是“有，可以严格执行”，40%的人员回答是“没有”，30%的人员回答是“有，但不严格执行，只是走形式”。

上述统计数据表明项目立项的执行情况并不理想，同时咨询师也了解到该公司很多产品在市场上并不成功，没有带来良好的经济回报。是否由此可以判断，该公司由于没有严格执行立项流程，导致产品立项的成功率不高？

事实上，该公司所属行业处于一个特殊的发展阶段，业界同行都在寻求解决方案的大规模应用场景，这家公司也不例外。因此，该公司的立项成功率不高是事实、立项流程执行不严格也是事实，但是这两者之间没有必然的联系——通过严格执行立项流程，力促提高立项的成功率，这个解决思路是缺乏逻辑的，也不符合公司的业务现状。

◎​ 调研访谈

调研访谈一般是咨询师和企业受访人一对一进行的，独立的环境有利于双方畅所欲言，可以直接了解到宝贵的一手信息。为了全面了解研发体系运作现状，访谈对象不但在纵向上要涵盖企业领导层、研发管理层、研发业务骨干等不同层次人员，而且要横向涵盖与研发体系有关联部门（比如市场部、销售部、质量部、采购部、制造部、客户服务部、人力资源部等）的负责人和业务骨干。

对于不同的访谈对象，需要有明确的访谈目的和范围，事先准备好访谈提纲，并根据情况追加问题。比如对于高层领导，访谈关注于企业战略、改进目标与要求等；对于研发管理者，访谈重点则在于研发体系的总体运作情况、具体改进需求、痛点问题等。咨询师需要从不同领域和层次关注研发体系。打个比方，就像是全息摄影，能够从不同角度共同反映事物的全貌，而不是每个人各执一词。

看下面的访谈片段，其中，A为咨询师，B为企业项目管理部负责人。

A：“贵公司研发项目是否有延期情况？”

B：“比较普遍，每个项目大约延期50%。”

A：“这是比较突出的问题。”

B：“是的，我们公司对研发项目有严格的进度要求，但完成情况并不理想。项目团队也有意见，每次延期他们都很有挫败感，但是作为管理者，我们也没有办法。”

如果对话到此为止，可以得出该公司“项目进度目标制定不合理，导致项目普遍延期”的结论，但是如果再进一步了解，就会发现判断有些操之过急。

（继续上面的对话）

A：“为什么对研发项目提出如此激进的进度要求？项目团队是否接受这样的目标？”

B：“项目团队当然不愿意接受，明知道时间不够，项目资源就摆在那里，也不可能临时增加。但是他们也没有办法。”

A：“具体什么原因？”

B：“是这样的，我们领导认为给你10个月的时间，你要花15个月去完成；要是给你15个月，你就要20个月才能完成。所以，必须严格要求，不能放松。”

A：“你们每年立项的数量有多少？”

B：“今年立项了20多个项目，事实上事业部至少还有10个项目想立项，但是实在排不上了。这几年的情况都差不多。”

现在我们终于知道，根源在于该公司的主管领导认为“对研发团队压力越大，项目开发效率越高”，因此对研发项目提出了非常激进的进度要求。这指引咨询师对项目规划、资源配置、进度偏差等情况做进一步了解，才能做出客观判断。

在访谈中，双方经常会对企业当前的痛点问题做深入的交流，有经验的咨询师不会即刻给出解决建议。那些具有鲜明企业特征的研发问题，通常并没有简捷有效、立竿见影的解决措施；在对问题缺乏足够认识的情况下贸然作答，非但不会树立良好的形象，反而会将咨询师经验匮乏的弱点暴露出来。

◎​ 阅读文档

文档是研发工作的输出，也是工作留下的痕迹。在进行现状调研时，咨询师主要关注两类文档：一是研发体系管理制度和流程规范；二是研发工作的交付成果。简单地说，前者是制度要求，后者是实际执行；若两者不一致，表明企业在制度落实方面存在问题，就是常说的“两层皮”。

对于过程文档不完整的研发项目，一些重要的管理活动并没有体现在文档中，单纯阅读文档就无法抓住重点。面对这种情况，比较有效的手段就是要求项目成员将项目过程描述清楚，以此为链条将项目文档串联起来。

◎​ 搜集度量数据

“没有度量就没有管理。”11有针对性地搜集度量数据，有助于我们更加准确地把握研发体系的确切情况，也使问题展现更有信服力。

在搜集数据时，最重要的就是目的性。如关注研发项目过程，则进度偏差、计划变更、需求变更/设计变更、交付缺陷等就是比较通用的度量指标；而关注产品规划质量，那么立项数量、立项成功比例、新产品占比等度量指标比较能说明问题。

但是仅仅将度量数据罗列出来，貌似很有信服力，实际上也许无法说明任何事情。当看到某研发项目的进度偏差率为30%时，并不能得出“项目管理水平不高”的结论：因为偏差，可能是进度计划本身过于激进（屈于外部压力）、可能是项目控制不严、可能项目属于技术研究类、可能是项目过程中出现重大变更、可能是关键成员调离，也可能是诸多原因交织在一起。因此，上述较为突出的数据，将会促使改进者关注引起进度偏差原因，而不是惊讶于偏差过大。

英国传奇首相温斯顿·丘吉尔的演讲非常具有感染力和说服力。有人问他：“您在演讲中总会引用大量数据去论证一个事实和道理，您所谈及的数据是否真实？”

丘吉尔如此回答：“我花了三个月的时间去准备这些数据，如果别人怀疑这些数据，也会花上三个月的时间去搜集。所以，至少是在三个月之后我才会遇到麻烦！”

与政治家演讲中的数字相反，研发体系调研获得的数据不仅要准确可信，还需要咨询师分析背后的原因。分析后的结论也许符合原来预期，也许并不能指向任何问题。尽管是“费力不讨好的苦差事”，但分析数据是调研工作的一个必要组成部分。

分析度量数据为深入调查指明方向，通常横向比较和纵向深入分析可以帮助咨询师快速了解企业问题的分布。

横向比较是将目前的数据与历史数据、企业其他产品线的数据进行比照，分析其中的差异。

某公司本年度的研发人员离职率约为20%。

这个数据并不显眼。如果和历史数据进行比对（前年和去年的离职率均未超过10%），改进者就会有所警觉，进而去探究导致离职率飙升的原因。

纵向深入是将量化数据和定性分析结合起来、相互佐证，有利于我们得到更加接近事实的结论。下面是一个关于变更的数据分析案例。

某大型机电公司对其在产品制造过程中发生的大量工程变更非常头疼，“变更通知单一次比一次厚”，后续部门应接不暇。为了搞清楚背后的原因，需要对相关数据做深入的分析。

在与设计部门访谈时，咨询师了解到引起工程变更的主要原因是客户的需求不断地变化，而且难以控制，设计部门只能被动响应并传递到后续环节。

咨询师搜集了近三年的变更数据，分别为2221次、3138次和6789次。而在去年的6000+次变更单中，修正设计错漏占比为62.38%，客户需求变更占比为4.06%。由此判断绝大多数变更的直接原因为设计本身所致，并非感觉上的客户因素。

为什么去年的变更数量急剧增加？事实上源于该公司的一项管理制度的调整。去年之前，一份工程变更单中可以包括很多相关的变更请求；去年开始则要求一份工程变更单只能包括一条变更请求。也就是说，原来的一份变更单被拆成了现在的几份。在进一步核实后，发现工程变更的实际数量并没有明显的增长。

◎​ 组织小组讨论

对于需要不同领域人员集体做出现状描述的时候，一对一访谈的方式无法满足要求，这需要组织小组进行讨论。如果企业在产品规划、产品开发、需求管理等过程中涉及多个部门，其中还有很多工作接口，任一领域的人员都无法将这些信息完整地展现出来，那么就需要相关人员共同还原该过程。

有别于单独访谈的一个显著区别，就是小组成员容易受到他人，尤其是领导意愿的影响，而采取明哲保身、趋利避害的态度，使得咨询师获得了被扭曲的信息。

咨询师组织某公司主要业务部门领导和骨干召开研讨会，按照AQPC12的评估模型，进行业务流程成熟度的测评。公司总经理抛出了问题：“我们公司的流程成熟度目前处于哪个级别？”

部门经理A认为公司处于3级（即集成级）的水平，理由是公司在业界处于先进行列，管理水平自然也不会差。结果他的说辞遭到了总经理的痛批：部门经理A说的不对，扣罚当月奖金！

接下来部门经理B降低了评估结论，发言表示公司处于2级（即职能级）的水平。结果他的说辞也遭到了总经理的痛批：部门经理B说的也不对，扣罚当月奖金！

之后又点名让部门经理C发言。部门经理C暗自揣摩：“从老总的发言看，肯定是认为公司管理水平低。前两位都说得太高了，我应该按照最低的级别说。”因此，他表示公司的流程成熟度为1级，也就是初始级。没想到还是没过关，总经理认为他说的还是不对，自然也被扣了奖金！

这就奇怪了，按照APQC的评估模型，初始级已经是最低级别，部门经理C已经是最“谦逊”了，为什么还是没有达到领导满意？

最后，公司总经理抛出了自己的观点。他认为，公司流程管理水平太差，甚至连初始级都达不到，因此应该是0级。大家这才恍然大悟，领导的心思还是很难猜的。

可以想象最终测评结果并不能体现该公司的真实水平，领导已经定了基调，夸大其词的问题描述纷纷涌现，公司的管理情况被说得极端糟糕。这样的小组研讨已经失去了意义。

在小组研讨过程中，要尽力避免“钓鱼执法”“请君入瓮”等情况出现。实践证明，组织小组讨论必须具备如下两个特点，才能获得预期的效果。

一是适当人员的参与。需要那些执行流程、真正了解业务实际情况的骨干人员参与研讨，这样才能获得真实的一手素材。在咨询项目过程中，笔者曾经遇到这样的情况：研讨小组成员都是由流程制定者所组成，而那些在一线工作的业务骨干却没有机会参加。这将使得了解到的信息偏纸面化，无法接触执行细节和真实情况。

二是气氛平等、宽松。组织小组研讨的目的是，全面了解管理现状和业务需求，并非现场对工作的是非曲直做出评判。因此，需要创造一个宽松氛围，使大家将注意力聚焦于展现现状，即使偶尔的冲突，也是为了澄清不一致的执行现状而引起的。

在还原某公司的产品研发过程时，咨询师选择了研发、市场、财务、采购、测试、质量、制造等部门的业务骨干参加小组研讨，共同组成一个虚拟的跨部门团队，逐步展示一个典型的研发项目过程。

在展示过程中，产品开发团队成员之间也会有矛盾，比如流程是否需要展现到细节、工作接口关系和执行顺序、重大返工等，大家都会有不同的意见。一方面咨询师强调了相关的原则；另一方面从争执中了解到项目真实的执行细节。

这是一次给大家带来收获的研讨：第一次了解到了研发过程的全貌，尤其是相关部门是如何配合开展工作的，消除了很多误解，也发现了研发过程中有待改进的地方。

◎​ 工作观摩

观摩企业的重要管理活动对咨询师来说是非常必要的，只要条件允许就要去参与，包括技术评审会、项目汇报会/总结会、质量回溯会等。工作观摩提供了比其他调研手段更加直接、真实的感受。在研发体系改进工作中，对执行力度和效果影响最大的因素就来自人员本身，工作观摩恰好使得咨询师有机会对业务人员的工作习惯、企业文化拥有最直接的认识。

从工作细节上可以看出很多东西：在开会之前，与会人员具有明确的座次和入场顺序，标志着该公司等级森严，各项工作都要进行层层的汇报和审批，否则寸步难行；当分管不同领域的领导能够开诚布公、畅所欲言，标志该公司拥有比较轻松、民主的工作氛围，但需要提防议而不决、执行不力；当碰到相互指责推诿、文过饰非、言之无物的情况，则提醒我们，该公司的官僚做派将会对改进工作造成极大的阻碍。

◎​ 信息收集工作实践

在《三国演义》中有一段对大谋士庞统的传神描述。当时庞统被刘备安排去做耒阳县令，实在是大材小用。庞统无所事事，饮酒度日，这直接遭到张飞的指责。

飞曰：“汝到任百余日，终日在醉乡，安得不废政事？”统曰：“量百里小县，些小公事，何难决断！将军少坐，待我发落。”随即唤公吏，将百余日所积公务，都取来剖断。吏皆纷然赍抱案卷上厅，诉词被告人等，环跪阶下。统手中批判，口中发落，耳内听词，曲直分明，并无分毫差错。民皆叩首拜伏。

庞统的名士风采实在是令人神往！然而咨询师的调研工作却难得这般潇洒，在对企业现状进行了解时，往往无法一下子就抓住问题的实质，需要一个逐步深入、去伪存真的过程。

下面展现了一个调研工作计划（片段）的样例。如表2-2所示。

表2-2调研工作计划（片段）的样例

在表2-2的调研计划中，咨询师将调研工作分为两轮。第一轮主要是广泛了解企业研发体系现状，明确主要干系人对体系改进的诉求，初步确定重点问题；第二轮是在全面了解的基础上，对重点问题和假设进行验证，有针对性地关注细节，最后对信息进行分析总结，形成调研报告。

某些公司的研发体系比较复杂，拥有多条彼此独立的产品线或事业部，甚至还包括企业研究院。在对此类企业进行调研时，可以将各个部分看作独立的研发体系，在撰写调研报告时，也需要彼此独立。

将各产品线问题拼凑为一份调研报告的方式是不可取的。这种报告或许让企业管理者感觉内容丰富，业务问题比比皆是，但实际上无法如实体现任何一个研发体系的真实情况，误导改进的方向。