提醒：以下内容非针对食品行业，但对食品研发人员仍有很大的借鉴价值，供大家参考。

我们期望的目标是：

——研发过程通过严密管控提升产品研发质量；

——路径便捷、工具适用、组织协同高效、减少过程漏洞降低后期返工，以提升研发效率；

——团队组织管理、设计方案与部件选型等活动，成本计划制定及控制合理、整个过程成本受控，降低研发成本与产品成本；

——研发方向正确（产技规划与立项论证）、确保项目成功、市场成功、财务成功。

但从目前实际情况来看，普遍与我们的期望相差较大。本文列出了一些常见的、典型的研发管理“痛点”。

一、高能低配，人力资源浪费

（一）概念解释

开始的时候水平高的人去接项目，接了以后做需求调查研究分析，推动项目立项，接着做方案、展开设计、制造样机，最终这部分人被拖到后续一系列的产品工艺、质量、成本问题解决、售后服务支持等事务性工作中去，便无力再接新项目了。

‍我拿建筑领域来形容这是个什么概念：好比农民盖房，由于前期没有正规的设计、各种各样的图纸资料不完整，‍‍线往哪穿往哪走在图纸上没标，布线施工由“设计”人员在现场指导却没有留下记录；‍‍地上挖了沟铺管道，最后砂子加土埋了就完事。等出了问题别人解决不了，只有请“设计”人员到场解决，到此时“设计”员就变成了维修指导人员。

（二）问题原因

前面强调时间紧张，思考不全、不愿认真写报告便盲目动手；最终‍‍问题留到了后面去，再用大量的时间去救火。

1、前面不舍得花时间

比如在做某产品方案设计时，如果多花一个月时间把所有的事尽量想清楚、编写报告再加反复评审便减少了很多漏洞，后面就没有那么多事情了。

2、前面不会花时间

‍即使你给了时间也不会花，就不知道怎么写，不知道怎么表达。

（三）问题后果

‍‍最终等产品面市后，用户成了测试员，‍‍用户不提问题自已觉得都是好的，所以随着用户使用程度加深与认知水平提高，问题便不断被发现。这样就大把的时间都浪费到后面去了，有可能一年两年都成熟不了，‍‍但是前面让抽出一两个月时间堵漏却不行。

——因为是设计开发导致的质量问题，设计“高手”最终成了维护支持人员！

二、低能高配，开发效率低

（一）概念解释

前面项目拖拉延期，后面新项目没有高手接了，能力稍差些的人员或新来的大学生，只要能干点活的也就上去了。‍‍这部分人做的产品设计漏洞更多，后面的火便烧得更旺。

（二）招聘人才

成熟人才难招聘，新毕业生招聘入公司短期无法发挥作用。

由于前期缺乏人资筹划，人到用时才申请招聘，从招聘实施再到人员能承担任务，至少2年以上才能起到作用。

（三）问题后果

现有人员越来越忙，加班成为常态，人才梯队脱节，问题日趋严重，这样就陷入了一个恶性循环。

三、人员离职，项目中断

研发过程缺乏团队角色分工与组织，常出现一个人将一件事甚至一个项目从头干到尾，且过程文档不全、评审形同虚设的现象；一旦离职或因其它原因需要调离，会产生项目中断且其他人员难以接续的风险。

四、人员协同效率低

项目型组织，容易出现项目组之间抢夺资源，但又不能充分使用资源的问题。

例如一个电子工程师在A项目组中任务量不足，而其它项目组电子工程师却不够用，通常会出现什么情况呢？

跨项目组的资源协同，包括人才、技术、cbb等如何共享协同？

跨产品线？跨部门呢？

五、人员成长缓慢

通常，新招聘人员的培养模式是师傅带徒弟，或主要靠自身的悟性成长，缺乏体系化训练。

（一）不均衡

师傅水平的高低、带徒的主动性与方法，直接影响新人的成长，不同师傅带徒效果差异大。

（二）不系统

师傅的能力范围局限，无法做到系统性训练的安排。

本专业知识的系统性？ 跨专业的视野拓展？ 研发体系培训？ 逻辑维、时间维能力训练？

一、立项可行性分析不充分

前端需求分析不透，市场调研分析不充分，立项论证把关不严，开发出来的产品与市场实际需求产生偏差，甚至会因为市场趋势与容量判断错误导致市场和财务目标无法达成。

二、方案设计不系统

产品开发设计常见用模板填空式的做方案，不明白报告的逻辑结构、缺乏严密的逻辑交互关系分析、遗漏应管控要素及其实现方法；

关键技术的事先识别与预研没有在产品开发前开展，常致使产品开发过程等待或中断。

三、需求变更频繁

对需求理解的层次低，被动等待需求是普遍现象；承担产品设计方的需求理解能力不足，用户一方对需求的描述又往往只能停留在对一些关键使用属性的指标上无能力系统表达，甚至许多时候还会出现满足用户提出的需求并不能实现其真实意图的情形。

例如：研发管理信息化平台的建设

用户方提出需求，给出各种需求条目；但用户有能力描述清楚真正的需求吗？请思考以下问题，用户有无能力理解与表达清楚：

1）研发的流程？

2）研发的需求管理：需求有哪些构成？怎么分析、传递、转换、控制...？

3）研发的过程如何管控？

4）研发的图纸、资料、成果如何管理？

5）如何在研发过程中做好统型管理？

6）如何做好状态管理？

所以，做为设计方，如果没有需求的理解、分析与管理能力，必然会导致后期不停地变更与返工。因为对双方来说，大量需求是渐进明细的，事先没能力理解与表达清楚。

四、评审控制不力

1、设计人员：报告编写质量欠佳。

2、项目管理人员：报告的预审把关能力欠缺，如编辑性、逻辑结构审查；评审组织、记录、整理能力不够专业。

3、评审专家：没有受过系统、专业的训练，主要依靠自已的经验做判断。缺乏对报告的逻辑结构、交互关系、要素控制、工具/方法/技术应用、CBB应用与构建等视角的系统审查能力。

4、评审组长：意见的分析、综合、提炼、筛选抉择能力欠缺，未能将多位专家意见整合成统一、准确的修改意见。

五、过程测试缺位

测试是产品研发过程的质量控制四大手段（设计、仿真、评审、测试）之一，

在单元测试阶段以白盒测试为主，到集成、系统、验收测试阶段逐渐向黑盒测试为主过渡。

1、大量的隐含质量问题通过白盒测试，去发现与控制缺陷来达到质量控制的目的，需要有很深厚的专业技术功底；许多单位忽视了这些过程测试阶段，主要依靠质量部门以黑盒测试为主的方式进行部件和整机测试，致使许多隐含的质量问题被忽略。

2、对过程测试重视度不够，没有组建专业团队或虽然组织了人员但能力不匹配，无能力发现潜在的质量问题，整个团队没有高水平人员牵引。

试想：什么样的能力才能真正发现关键问题？ 测试团队中有吗？‍如果哪个企业测试团队中舍得设置一两名高手，是不是感觉就很厉害？

六、项目延期常态

1、需求不明盲目动手，开发过程需求不断变更；

2、方案设计不系统，逻辑关系不严密/要素遗漏等导致过程频繁返工；

3、设计、仿真、评审、测试各手段质量控制能力差，过程隐性缺陷堆积，最后到测试阶段不断修改。

这些问题的存在让项目延期成为常态。

七、事后返工不断

样机制作、试验验证、产品上市，频繁地陷入发现问题—>解决问题—>再发现问题—>...... 的循环。

1、软件管理工具

PLM、PDM、DOORS、Rhapsody、TCM、评审管理、项目管理...

研发人员的烦恼：干一个活，需要让我在多少种软件间来回折腾？

2、多体系

GJB9000体系、GJB5000A、AOS、IPD、MBSE...

研发人员的烦恼：让我按哪个体系执行？

产品种类增加、客户数量增多—>问题不断爆发—>深陷修补泥潭—>

无暇顾及长远—>新品开发乏力—>竞争能力下降。

【思考】参见图1-1，我们的技术人员用于产品升级维护、产品开发、技术预研的占比？发展趋势？

图1-1 研发“救火”状态背后的模式与结构

来源：数企赋能，作者丨陈南峰，转载请联系出处。封面图来源：千图网

提醒：文章仅供参考，如有不当，欢迎留言指正；读者不应该在缺乏具体的专业建议的情况下，擅自根据文章内容采取行动，因此导致的损失，本运营方不负责；如文章涉及侵权，请联系我删除或支付稿酬。