企业研发管理常见问题和应对

　　1.组织结构和人力资源管理 
 
　　职能型还是矩阵型，项目经理和职能经理的交叉管理和平衡。

　　多头领导，能干的人都搞管理去了（彼得原理)。

　　岗位，角色，职责不清楚，而且经常发生变动。

　　缺乏竞争和激励机制

　　营销、研发、服务没有很好衔接。(产品生命周期管理，IPD思路)

 

　　2.产品生命周期问题

 

　　不清楚“产品生命周期”和“项目生命周期”之间的关系，不清楚产品管理和项目管理的区别与联系。（项目目标也是根据商业目标和产品定义确定的，最终创造价值的是产品，项目生命周期仅仅是产品生命周期中的一个阶段) 缺乏“产品生命周期阶段划分和决策评审”的详细操作指导书，不能有效地开展决策评审和技术评审。
 
　　大型企业内部可能有一些机构在推行ISO9000, CMMI, PACE, RUP等方法，越做越复杂，难以产生广泛认同、简单有效的思想方法，难以提高管理效率。(流程，过程，规范，集成产品研发各自作用在哪里？最终都要体现到创造效益上) 不清楚“软件配置管理”、“文档管理”和“BOM表管理”的区别和联系，甚至错误地使用工具。

 

　　3.项目管理问题

 

　　3.1 立项管理问题

 

　　自主研发项目：缺乏“调研，可行性分析，立项建议，决策评审”，主要靠公司领导独断，团队只知道干活，却不了解产品的开发背景，不清楚用户期望的产品应该是什么样的。在开发过程中经常迷失方向，导致进度延误、费用超支等问题。

 

　　合同项目：需求不清晰、合同内容空洞；双方在签订合同的过程中给出了一些空头承诺（例如对进度、质量、费用的估计过于乐观），在实际执行时却难以兑现这些承诺。

 

　　3.2 结项管理问题
 
　　人们往往对财务和设备进行了详细的清算，却忽视了对知识财富、经验教训的总结。没有对项目的价值进行评估，开发人员干完活后，不知道自己的工作成果产生多大的效益，缺乏成就感。

 

　　结项后，不能对员工的业绩进行公正考核，自然不能很好地激励员工。

 

　　3.3 项目规划和监控问题

 

　　许多项目经理肩负重要的软件开发工作，他们往往把注意力集中在开发上面，很少认真考虑如何进行项目规划和监控。 没有突出项目监控的重点，项目经理要么什么都不监控（导致项目失控），要么监控得太多而陷入琐碎事务中。（分清楚粒度，频率，关键点，关键资源)

 

　　项目经理写周期性项目进展报告时，记流水帐，或者复制上次的报告，应付了事。懒得动脑筋分析项目遇到的一些问题，例如某些任务的进度延误了，不分析为什么延误了，就顺延。导致问题越积越多。(问题根源是什么，偏差是否典型)

 

　　项目实际执行情况与原定的项目计划严重脱节，领导、客户、市场人员、开发团队不了解项目真正的状况，使项目计划行同虚设。

 

　　3.4 软件配置管理问题

 

　　有些软件机构竟然不使用软件配置管理工具，用最原始的方式手工管理代码和文档，经常出现“成果丢失、版本混乱”等问题。

 

　　不少机构按照的CMM的要求制定了配置管理规范。该规范在理论上比较完善，面面俱到，但是实际操作比较麻烦，没有突出重点。久而久之，人们厌烦后就逐渐放弃了规范，按自己的习惯操作，留下了隐患。例如不少程序被 checkout 后长久没有 checkin；有些程序保留在开发者本机，根本就没有放入配置库。

 

　　维护期间修改了程序，但是没有放入配置库。

 

　　3.5 软件质量管理问题

 

　　虽然人们大都认可软件的质量很重要，但是许多软件人员并不懂得如何有效地改善软件质量属性如正确性、健壮性、可靠性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性等等。不会分析当前软件的质量要素是什么，没有把精力集中在改善对经济效益贡献最大的质量要素上面。

 

　　有些软件机构没有软件质量管理的措施，开发人员把完成功能当成终极目标。用户在使用软件的过程中发现许多Bug，导致开发方的纠错性维护代价很高。

 

　　有些软件机构虽然很重视软件质量，按照ISO,CMM 的要求建立了管理规范，但是效果不明显。人们搞不清楚软件测试、技术评审、质量保证的作用和关系。不懂得内建质量，主要靠修补错误的方式提升质量，代价比较高。

 

　　很多人误以为提高软件质量是质量保证人员和测试人员的责任，没有意识到任何开发人员、管理人员都会对质量产生影响，都要对质量负责。另外，质量保证人员的权力比较小，很难推动质量改进措施。(质量不是检验出来的，质量管理要树立全民意识)

 

　　3.6 变更管理问题(CCB,变更流程，变更影响分析)

 

　　经常随意变更需求、设计、代码等，严重影响项目的正常开发进程。 无法拒绝客户的不合理变更。
　　
　　4.开发问题

 

　　开发团队不能熟练应用“增量－迭代”的开发模式。(RUP，迭代和增量分清楚)

 

　　需求分析能力欠缺，不能很好地抓住用户真正的需求、清晰地阐述需求。(需求分析的重点是挖掘潜在需求，从用户需求到软件需求的抽取和提炼)

 

　　系统设计能力欠缺，不能综合考虑产品的功能、性能、可扩展、可复用等。(任何软件生命周期和开发方法论，系统总体设计阶段必不可少)

　　软件用户界面设计能力欠缺，易用性不够好。

　　开发团队各成员的编程质量差异比较大。(人员角色分工，外科手术队伍)

　　测试和改错的效率不高，不能在比较短的时间内发现缺陷，并很快消除缺陷。

 

　　5.跨部门协作问题(沟通，出入口准则，知识库，评审, 队词汇表) 
 
　　上下游人员相互不熟悉对方的工作流程和规范，沟通比较费劲，沟通效率比较低。

　　上游不能及时了解下游工作进展情况和负荷，不断传达新的任务，下游忙不过来。

　　上下游人员在沟通的时候，没有及时记录沟通的结论和建议。

　　上下游人员的工作成果分散在各自的计算机里，难以积累和共享知识财富。

　　上游传达给下游的需求不清楚，各方理解有偏差，导致需求和工作成果经常变更。

　　(过程和流程定义中，各中间阶段和中间产出物必须有严格的出入口准则)

 

 

 

　　6.工具问题

 

　　企业使用管理工具可以提升管理效率，积累知识财富，例如代码和文档版本管理、任务进度管理、缺陷管理等等。国内IT企业管理工具的主要问题不是“工具太少 了”，而是“工具太多了，杂乱无章，缺乏整体规划和管理”。工具之间各不兼容，没有办法整合数据。有些工具很老了、不好用，但是有数据，不能淘汰，又不能 更新。结果这么多杂乱的工具非但成不了财富，反倒成了包袱，十分头痛。示例：

 

　　7.互联网企业研发问题

 

　　技术积累和规范化程度较弱，心态浮躁.

　　有些互联网业务带有很强的时效性，项目开发周期通常较短，甚至可能只有几天或几周时间。所以互联网企业的研发讲究一个“快”字。人们留传一句话：互联网企 业的3个月，相当于传统IT公司的1年。绝大多数人并未真正领悟这句话的含义，并被严重误导。这句话的正确理解应该是：“互联网产品与服务的成败，在3个 月内就可以看到其他IT企业通常需要1年才能看到的效果”。

 

　　8.流程改进方法论

 

　　所谓流程就是工作的步骤和制度（规范），流程规定了“谁”“在什么时候”“怎么做事情”“产生什么成果”。流程一般有6个要素：目的和适用范围、角色职责、工作步骤和流程图、输入和输出、成果模板、度量和评价。

 

　　流程改进是指分析企业的强项和弱项，改正缺点、发挥优点，制定更合理的流程，使广大员工依据流程开展工作。

 

　　超过百人的研发队伍，公司应该设立专门的流程改进机构，不断发现企业自身的研发管理问题，并在公司层面进行持续改进，为各业务部门提供有效的研发管理方法论和工具支持。