产品研发杂谈(GJB5000A)

引子

这几年主要是做产品，时间从2012年初到2015年初，这几年做产品的经历，对产品研发流程也是比较熟悉了，对于一个技术人员来说，好些内容值得说一说。

产品研发流程是一个做事情的思路，每个人都有自己做事情的思路，但是体系呢相当于把前人的，经过实践确认的思路约定出来，我们按照体系做事情，能够把事情保质保量的完成。简单说就是软件工程。

一般公司的产品研发，通常是市场部负责产品定位、功能、市场宣传等，相当于合同的甲方，技术部门成立产品项目组，实际做事情，按照GJB5000A的说法都是利益相关方。流程一般是市场部出任务书，然后评审修改，进而确认需求，之后是项目启动会，需各种总监、负责人等等参加，项目经理出开发计划，配置管理员处配置管理计划，质量出质量保证计划。当然这样一些流程的事情，各个公司可能不一样。但是产品研发一定要确认输入，即使公司内部、部门内部，一定要确认输入，即产品做哪些东西、指标、新增的功能等等，约定一个范围。

任务书的评审是很重要的一环，即使公司内部，也要认真对待，每一句话都要确认，各种性能指标、软硬件环境，属性要求（可靠性、安全性、可测试性、可维修性）等等。

GJB5000A

三大计划

三大计划的开发计划，我的看法是整个项目活动过程中，最重要的一个文档，开发计划会知道整个项目活动。

根据5000A的思路，确定软件开发模型（瀑布型、螺旋型）、阶段、里程碑、WPS任务分解表、利益相关方、风险表等等。软件开发模型是如何选取的，有什么证据呢。

要有需求跟踪矩阵，并且一直跟踪。项目执行过程中，要有周报、月报、里程碑，里程碑的输入包括：相关的评审结论报告、单据等。

里程碑

里程碑是项目非常重要的一环，确认里程碑的方式是叫上利益相关方开评审会，有评审记录有签到表。评审的内容呢，就是你这个阶段的输出，例如：需求文档完毕就是入库单据、第一轮配置项测试就是测试报告，如果是交付验收就是相关记录。

月度例会

月度例会通常是项目组内部，成员汇报自己的工作，有问题提问题，资源协调等等。跟踪《风险跟踪表》，是不是有新的风险，有没有风险转成问题。需求跟踪，是不是有新的需求，新需求怎么办，跟踪《需求跟踪表格》。

需求跟踪表

我们的一个总监一直强调《需求跟踪表》的重要性，说各个项目要是都有一个需求跟踪表跟踪下去，不会各个项目一团糟，我也秉承这个观点。《需求跟踪表》确实是值得真个项目周期一直维护下去的。需求跟踪表包括，需求来源，需求描述，需求规格说明书，概要设计，测试文档，测试用例等等项目内容。之前我认为需求跟踪表并不能描述用户需求，但是呢用户提供的文件是可以跟踪到《需求跟踪表》的，需要保证与用户确认的需求文件（任务书、技术要求），细节的可以在需求规格说明中明确软件的具体功能。

说到需求，这个是个大话题，针对我们的行业貌似需求比较明确。

GJB5000A

5000A一套质量体系，我更喜欢把它说是一套做事情的思路，一个项目要做那些事情、怎么做这些等等。GJB5000A约定的几个过程域，每个过程域的公共实践和私有实践，实践的证明文件等等。但是呢执行5000A要执行大量体系约定事情，要写大量的报告、评审记录、闭环、各种体系文件，必定增加很多体系的成本。

5000A将项目活动分为若干个过程域，CMMI二级包括六个过程域，我们成为"六个核桃"，即：需求管理（ReqM）、项目策划（PP）、过程和产品质量保证（PPQA）、项目监控（PMC）、测量与分析（MA）、配置管理（CM）。

项目策划过程域

项目策划中的一个实践是成本估算，成本估算也是一个复杂的话题，估算成本有很多方法，我们常用的是拍脑袋，估计大部分项目都是拍脑袋了。也可能是预估代码量、文档页数，根据代码量文档页数估计时间。

感想

之前某同事说过，5000A是建立在对人的不信任基础上的，我也秉承这个观点，人是不可靠的，或者可靠的人太少，而且可靠的人也是会范错误的。大部分公司对研发项目是按照质量等级确定，不同的等级是可以裁剪的，经过裁剪是可以降低一些研发成本的。

整篇文章想记录的是之前的产品研发过程，大部分是严格执行5000A来的，所以产品研发的流程也便是GJB5000A的了。

写篇文章做一个记录。