研发管理典型问题包括：1、未形成正确、系统的研发理念；2、缺乏前瞻性的、有效的产品规划；3、在开发过程中缺乏投资决策评审；4、职能化结构带来的协调困难；5、不规范、不一致、接力式/串行的开发流程等。
一、研发管理典型问题的认识及建议
1、未形成正确、系统的研发理念
企业研发过程是一项复杂的系统工程，企业高层管理者必须认真考虑新产品开发战略，灌输正确、系统的研发理念，而这正是我国企业的薄弱之处。明确的新产品开发战略能够指引企业的新产品开发活动朝着正确的方向迈进，系统的研发理念是企业新产品开发中各项活动的指针。新产品开发战略和开发理念应确定企业的新产品开发方向，范围和竞争对策，合理地组织新产品开发活动和分配研发资源，从而为新产品开发活动取得成功提供保障。
2、缺乏前瞻性的、有效的产品规划
在经济全球化、市场环境瞬息万变的背景下，企业要高瞻远瞩，时刻关注市场和顾客需求以及竞争对手策略的变化，做好众多产品的开发规划和组合管理。我国企业往往缺乏前瞻性的、有效的产品规划，这导致了企业研发资源的浪费和对市场反应迟缓，丧失机会和企业发展后劲不足。
3、在开发过程中缺乏投资决策评审
研发活动占用资金量大、投资回收期长，风险往往很大，加之对企业的长期生存和发展具有重要意义，使其成为企业重大的决策之一。我国企业在研发过程中缺乏投资决策评审，为研发活动埋下了隐患，往往造成资源的巨大浪费和企业的危机。
4、职能化结构带来的协调困难
研发活动需要员工积极参入，对于员工充分授权和顺畅的沟通，这就需要企业灵活地选择研发组织结构。我们不少企业仍然采用职能化结构，部门间沟通不畅，有问题是相互推卸责任，给协调和合作带来极大的困难。今后我国企业应更多采用矩阵式、跨职能团队等组织结构，为研发活动增效。
5、不规范、不一致、接力式/串行的开发流程
我们企业研发活动往往缺乏规范性和一致性，开发流程多为接力式/串行式，这使得研发效率低下，模块可重复利用率低，对顾客需求的满足度不足。企业应更多采用并行工程，使产品开发人员从一开始就考虑到产品全生命周期（从概念形成到产品报废）内各阶段的因素(如功能、制造、装配、作业调度、质量、成本、维护与用户需求等)，并强调各部门的协调工作，通过建立各决策者之间的有效信息交流与通信机制，综合考虑各相关因素的影响，使后续环节中可能出现的问题在设计的早期阶段就被发现并得到解决，最大限度地减少开发设计的反复性，缩短设计、生产准备和制造的周期。
6、项目管理薄弱
研发多是一次性的活动，采取项目的形式，我们企业项目管理能力普遍薄弱，这给研发带来众多本可避免的风险。因此，我们企业必须加强项目管理，使研发活动围绕着明确的目标，在特定的时间、预算、资源限定内，依据要求和规范完成。
7、技术开发和产品开发未分离
在市场导向和顾客驱动的市场环境下，技术开发和产品开发应分离开。我们仍有不少企业尚存在技术研发与产品开发未分离的情况，这往往导致不能有效利用外部资源和引进技术，不能及时有效地满足用户需求，对市场变化不敏感等弊病，影响企业研发活动的成功。
8、缺乏经验教训的积累和知识共享机制
我国企业在研发活动中缺乏经验教训的积累和知识共享机制，这从企业重复犯同类错误、随人员流失而出现的技能知识短缺、不同项目中重复劳动等方面得到体现。企业应重视知识共享机制的建立和经验教训的积累与学习。
9、研发人员职业化素质不高，缺乏有效培养
我们的研发人员职业化素质还不高，并缺乏持续有效的培养，这使得企业严重缺乏可以独当一面的创新型研发人才，制约了企业的持续健康发展。今后我们企业应更加重视对优异研发人才的引进，职业化发展规划辅导与培训，以及学习型和组织的建设。
10、缺乏有效的研发考评与激励机制
缺乏有效的研发考评与激励机制也是我国企业在研发管理中存在。单一和静态的研发考评指标不足以反映研发活动的真实绩效，不能及时暴露研发过程中存在的问题，以团队为主的激励方式难免有失公平，对个人潜能的激发仍需探索更加适合的综合激励机制和方案。
延伸阅读：
二、关于重构
研发管理就意味着我们经常要接手老团队，维护老系统。老团队和老系统，都会存在很多问题。团队问题，这里先不讨论，只说系统，很大可能会出现：有人跟我说，某个系统代码太烂了，要重构。
如果有人跟我说，某个系统代码太烂了，要重构，我会问他几个问题：
1、系统的性能和稳定性怎么样？是不是一直在出问题。
2、业务方和重点客户对系统有什么核心诉求，抱怨的问题有哪些？
3、现在这个系统的研发资源和交付效率怎么样？
4、这个系统的业务方未来的规划是怎么样的，新需求多不多？按现有的条件，能不能满足？
这些问题，才是核心问题，比代码本身的问题，重要得多。如果这些问题不去面对，那么重构也不会解决这些问题。相反，重构带来的复杂性和其他问题，会把我们自己也变成问题。
有人会说：一般抱怨代码烂必然由上面说的问题，不难改谁去抱怨？
很好，如果抱怨它烂，就把烂的程度，度量出来。
没有量化就没有改进。
或者换个角度考虑，你怎么来衡量，你重构以后，能比现在好，好多少？
Judgement is cheap, show me the Fact.
很多时候，开发者不是不想把质量搞好，比如三天的活，我们要一天干完，没别的可选。这个时候，我们也不能只看到代码烂，而看不到开发者，为了按时交付而做出的努力。
以上就是关于研发管理典型问题的认识及建议的内容希望对大家有帮助。
