关于研发中心引入项目管理思维的分析
目录：
1、现状及原因分析
2、项目管理思维
3、远期目标：流程化、规范化、制度化
4、近期目标及具体措施
一、 现状及原因分析
目前的研发中心，以我有限的视角，能观察到的问题，简述如下：
1、产品质量难以保证
为什么说难以保证呢？以近期5月底完成的原计划在6月11号对外发布的网管版本为例，今天我查了一下bugfree系统，尚未解决的问题单还有37个，其中还有不少致命和严重的问题单，而这些问题单并不是最近一周提出的。还有这么多问题单没有解决的版本，怎么能保证其质量？怎么可能放心往外发呢？
造成这种现象的原因我觉得有两个：
一是没有人专门来盯问题单这件事，也就没有人来推动问题单的原因分析和解决。
二是缺乏流程或制度的保障，也许以前制定过一些流程，包括过点评审等，但没有去执行。如果有流程来保证的话，还有这么多问题单（注：也有可能是问题解决了但没有走单）的版本绝不可能被通过。
质量问题还在其它方面有表现，比如一些基本功能在提交到张三那都还有问题等，这些从张三的测试报告中也能看到，原因暂不过多探讨。
2、开发进度没有保障，无人跟踪
我举一个例子，张三在6.11日的邮件中问道：log文件就这些了吗？6.12日的邮件中又问了第2遍，邮件没有人回复。我来说一下：提供log导出功能，应该是在4月份的会议上确定的5月底要交付的功能。这个功能涉及我、A和C，现在能够导出的就是我这部分的log。具体A和C这两部分的log为什么没有实现导出，好象是他们俩之间的接口没定义好，具体我不太清楚。但就这样明显缺失的功能，却没有人认识到，也没有推动去完成。这反映了我们在开发进度的安排和跟踪上的不到位。
3、开发计划不尽合理
开发计划的制定，应该是一个很严谨的事情。在什么时间点，提供具有什么功能的产品，是要根据市场的情况及内部研发能力的状况去仔细衡量的，这些涉及很多具体事情上的轻重缓急的平衡以及对目前研发队伍的能力的准确评估。而目前的开发计划，只是简单的以自然月为里程碑，很显然是不科学的，因为有些大的功能项的实现保证不了正好在一个月的周期内完成。
4、开发节奏不符合客观规律
开发节奏的问题，目前是以一周为一个小迭代，其实这对目前我们的研发队伍是不太适合的。这样的节奏对开发团队的要求其实是很高的。今天我看到一个关于碗豆夹开发团队的介绍，他们用了半年的时间才从一个月的迭代逐渐跑顺到两周、一周的节奏。以跑100米的速度去跑1000米，很显然难以为继，会造成很多问题。就象上周6月9号的每周迭代版本就没有出，还是在5月份的分支上出的版本。
5、对各种技术风险缺少识别，更缺少应对措施
整个开发过程中的风险包含很多方面。我目前能看到的有：比如大的方面，在目前的网管架构设计中，主要的逻辑及并发压力都集中在管理层（A负责的部分），而这部分完全是我们自己写的，而非借助一些成熟的框架，这是有很大风险的，这个风险是系统级别的，而且也许在小规模设备的情况下不会有明显体现。还有，在做定位功能时引入使用NoSQL的mongodb来存储而舍弃使用以前已经在项目中使用的mysql，虽然不一定马上出现问题，其实是一种风险。还有其它一些技术决策，不是说一定会有问题，而是可能会造成问题，包括引起成本的增加及进度的滞后等。在常规的IT项目实践中，一般的技术策略是宁肯保守，也要规避不能预见的风险。
上面是我看到的一些问题，有的也许分析的不一定对，但各种问题肯定是存在的。这些问题总的原因我觉得一个是缺少完善的制度和成熟的流程去规范和保证整个产品研发的全过程，目前很多具体事情是靠人去临时决策如何做，这属于研发的初级阶段。二是具体的事情缺少相对专业的人去专职负责，也就是缺少执行和对过程的监督控制。
二、 项目管理思维
项目管理目前在很多高校有专门的系和项目管理专业，象清华，有专门的项目管理研究院（给我们上课的是该院的副院长）。也就是说，项目管理是一个专门的学科，也涵盖很多的知识领域。在国内外的许多项目上都有专门的项目管理人员来掌控整个项目，比如国内的三峡工程。项目管理用书上的话讲就是包括十大知识领域（包括整合、质量、风险、成本、干系人等）和5个过程的47项具体活动。
对于我们公司来讲，符合目前现状的做法，我觉得就是引入项目管理思维，部分的采用项目管理中的具体活动，而不必全盘照搬。然后在具体的实施过程中再不断的完善、优化及增减。也就是说在整个项目的全周期中，即使不引入项目管理中要求的具体措施（比如成本估算、挣值分析等），也要用项目管理的理念去思考和做事。项目管理思维狭义化、具体化的描述，我觉得就是在项目的各个阶段去定义大家都要遵守的规则、在项目的过程的各个阶段中不断的监控、度量和纠正，最终使项目目标实现。不同的项目有不同的场景，实际情况可能会千差万别，但项目管理的核心思想是一致的，只要建立和具备了项目管理思维，不同的项目中都可以灵活运用。同时，不同的项目中形成的经验、教训及规范等，也可以形成组织级的过程资产，从而对其它项目形成借鉴和参考。
三、 远期目标：流程化、规范化、制度化
引入项目管理思维的远期目标我想就是让整个的研发过程都有章可循，每一项研发活动都有制度来约束和规范，打造一个公司级别的软实力，从而也能锻炼出一支能协调一致、高效成熟的研发队伍。这些都是远期目标，甚至是一些愿景，不过多描述，但目标和方向我觉得应该是这样。
四、 近期目标及具体措施
近期的目标我觉得就是针对目前的已发现的问题，给出解决办法和思路，并能够对问题进行分析提炼后，举一反三，给出共性的解决方案，从而形成规范和制度。下面谈一下，目前我觉得应该实施的一些措施：
1、落实软件产品外发标准及流程，如果以前没有标准则制定标准，如果以前没有流程则制定流程。如果以前有，则落实到人，推动具体执行（可参照过点评审）。
2、健全以问题单为体现的质量保障体系。目前产品的质量，主要从问题单的数量及严重程度来体现，那么，抓好问题单的推动解决及追责与根因分析，就是目前保障质量的一个基本手段。另外，最好能建立一套与问题单相关的奖惩机制（比如出现一个严重单扣10块钱作为水果基金等）。目前还可做一套问题单的每日统计日报，内容包括每个人头上的各种严重程度的问题单的汇总。对于有争议的问题单，最好能建立类似CCB（变更控制委员会）的小组来裁决。对于测试的提单，最好也能规范（比如致命和严重单要和测试经理确认）及建立奖励机制。
3、合理制定开发计划
开发计划不能仅仅是什么时间实现什么功能的简单的时间进度计划。开发计划应该得到项目干系人的认可，项目干系人包括研发团队、测试团队及市场人员。开发计划应充分考虑市场上的要求和研发团队的实力。
开发计划一定要具有可执行性，开发计划中要包含对已知和未知的风险的应急储备时间。
4、健全更直观的项目进度展示及汇报机制
最好能让项目的进度更清晰可见，比如引入其它项目管理工具中的甘特图等，让项目进度对所有的干系人包括对领导层都随时可见并能清楚识别。这样做的其它好处是也可以清楚的看到谁提前了谁落后了，并可以具体分析原因从而及时调整和改进。
5、调整开发节奏，加强单元测试
目前一个实际的问题是研发完成功能后几乎没有多少单元测试就提交给测试部门了。我们知道，问题发现的越早越好，解决的成本越低。所以除了在开发计划中安排一定的时间用于联调和单位测试外，我觉得安排开发团队的成员轮流做单元测试也是一个方法。
更多的具体措施，我想不继续列举了，对照项目管理的指导原则，结合我们目前的现状和问题，我想会找到更多的改进点。项目中的各种情况都会出现，有许多都需要在遵循项目管理思维的基础上具体分析、灵活应对。
总之，我觉得在研发中心引入项目管理的理念，设立专职的角色和职位，对提升公司的整体研发能力是非常必要和有益的。
关于研发中心引入项目管理思维的分析