用户需求和系统需求

lsekfe

需求阶段的工作是项目经理最繁忙的一个阶段，也是项目能否做好的一个重要分水岭。通常此阶段要完成系统需求的编写，工作思路的整理，工作计划的制定，人员工作的分工，并且伴有大量的评审。如果稍有不慎就很容易被拉入到漩涡中，失去了自己，不停的被别人推着走，心情苦闷不说，还会为整个项目埋下层层地雷，才是真正的悲剧。
因为用户需求是由主管/产品经理编写，系统需求有项目组编写，因两个需求工作有着一定程度的并行，因此合在一章写。
按项目管理的五要素分解如下：

1、干系人期望-目标
用户需求：
用户需求通常由主管或产品经理进行编写，主要目的站是在客户的角度上描述遇到的问题，并将其抽象为客户的使用场景及对应我们项目能够提供的解决方案。
用户需求文档在解决方案的描述通常粒度比较粗，因为在评审中解决方案的思路有可能被变更，过多的细化解决方案，工作量返工的成本会比较高。
用户需求的主要干系人：
1) 上级领导：评估该项目的价值，投入产出比是否合适
2) 行销部：评估该项目如何宣传，宣传的成本
3) 项目组：以用户需求为基础细化系统需求，并理解项目意义
系统需求：
系统需求通常由项目组提供，将用户需求评审过的解决方案具体化，此文档的主要干系人：
1) 主管/产品经理：系统需求是否能完全符合用户需求，是否有足够好的用户体验
2) 客服部门：技术支持是否便捷，成本如何
3) 开发人员：项目具体做成什么样子
4) 测试人员：项目如何验收，怎样算通过
文档要描述清，UI界面（及界面上约束）、关联功能影响，已知缺陷，异常场景，非功能性影响（性能，稳定性...）等。
2、沙盘-思路
1）项目团队参加评审
在用户需求和系统需求阶段中，项目团队成员应该都参与评审，虽然评审过程中不一定发言，但是会有两个重要作用：
a、强烈的项目参与感
b、对项目原始需求的理解程度
c、对各干系人的期望的了解
2）需求质量保证
需求质量保证有两个很好的实践可以采用：
a、由下一阶段的模块作者编写需求文档
这样可以保证作者对需求的理解程度，同时在评审过程中能够纠正错误理解。由于下一阶段的作者通常来说更加熟悉改动或新增的模块，因此关联改动、已知缺陷发现比较容易被他们发现。
b、测试进行需求验收
记得前几年参加IBM的管理论坛，当时听到一个观点，深有感触。大概意思是：“只有可验收的需求才是完整的需求”。需求很难通过描述的粒度来判断是否完整，清晰，有看过篇幅特别长的需求文档，写了N多废话，但是仔细一推敲就能发现其中的很多遗漏点。
只有当测试的同事拿到需求文档后，能够清晰的知道如何来验收这些需求，没有任何二义性和模糊的地方，这样的需求才是完整，清晰的。
测试同事的项目全阶段的缺陷预防工作在我们公司推行已久，当目前为止还是需求阶段的缺陷预防产出最大。
3）制定项目沙盘
项目沙盘有两个重要部分
a、干系人期望分析与落实方法
例：一个项目组为了更好的体验，翻新了系统的所有页面。那此时产品经理/主管的期望是很明确的，就是为了客户体验。
此时项目组应该在需求讨论时（DEMO），界面已经初步完成时，功能都已经调通时，分别各安排一次体验，以此达成产品经理的期望。
b、项目成功的关键因素分析

项目的成功关键因素可以使用鱼骨图进行分析，对于研发项目而言主要由3根大骨刺构成：人，流程，技术
例1：一个项目组主要都是有新员工组成，项目组面临的技术难度不大，这时候新员工的工作质量就会成为关键因素，此时可以做进一步分析。

例2：一个项目组性能方法改动和提升技术是最主要的瓶颈，进一步分析如下：

3、计划制定
1）使用估算清单
项目里总有一些例行工作，项目组在估算开始前应该整理出此清单，避免项目组成员遗漏估算项。
一些例行工作例如：环境搭建，每日构建环境的维护，迁入代码审核，评审时间，测试案例评审时间等
如果当前部门或公司已经提供估算清单，那只需要根据项目特点做下修改就可以了。
2）落实沙盘
想法和计划最大区别在于后者已经准备开始执行，不准备实施的想法终究只是想法。经过各种分析、各种集思广益得出的沙盘是智慧的结晶，需要将他们做到计划中。通常落实沙盘得到的计划就是项目组的缺陷预防计划。
3）自下向上估算，专家核对
估算的方法有很多，这是我所推崇的一种方法。
估算结束后应该产生项目的详细project及明确的里程碑。
4、风险管理
1） 复杂系统里的关联影响考虑不周
对于在现有系统新增或修改模块的项目，如果当前系统非常复杂，那么关联性问题将很有可能在此阶段被大量引入。针对这种情况可行的两种方法：
a、召集专家会诊
b、模块负责人提前分析（需要项目组给予时间）
2）估算项遗漏
估算项遗漏会直接导致工作量不准，这里常见的方法如：
a、使用估算清单检查例行工作是否有遗漏
b、使用需求根据矩阵核对需求是否有遗漏
c、专家把关估算表
3）需求评审变化，导致新增预研项
最令项目经理苦恼的问题之一就是需求的变化，其实有些时候变化的不是需求而是大家对于需求的理解。避免需求变化的带来的影响，需要做好两方面的工作：
a、需求缺陷预防，项目经理向组员传递良好的客户导向意识，将一些项目组自己能发现的不合理处尽量在前期提出，避免拖拉到后期带来更大的影响。
b、当需求变化不可避免时，要及时评估是否要进行补充预研，我看过很多心急的项目经理通常急于按计划推进阶段，结果在这上面吃了大亏。
4）团队的组织架构，不利于及时发现风险
每当我听到项目经理说“项目质量要等到转测试后才能知道到底怎么样”时，我都会给这个项目打上“高风险”“失控”的标签。打个形象的比喻，项目是开发团队的孩子，测试团队是医生，要想生个健康的宝宝，怀孕前期及期间的工作是最重要的。当一个孩子已经出生时，孩子的体制和健康情况已经有了基本定论，如果这时医生才检查出有严重缺陷（例如，某个模块的代码写得很差），那么已经很难补救了。因此项目组必须要时刻对项目的质量、进度有很准确的把握。
对项目的质量，进度的准确把控，对于大团队可能有多个选择，例如：
a、成立不同小组，由组长兼顾管理和技术。
b、独立出兼职的技术专家团队负责技术，项目经理负责管理
c、独立出全职的技术经理负责技术，项目经理负责管理
等...
组织结构的方法可以多种多样但是一个原则是要能够及时有效的发现风险。
在这方面我和我的搭档尝试过一种方法，可以作为一个实践供大家参考，我们当时制作了一个项目模块质量跟踪表，以及时发现风险。
跟踪表里的第一部分是：项目组的所有模块、负责人，涉及的专家名单
第二部分是：对模块复杂度，难易程度的自评、专家评定
第三部分是：对模块设计情况的自评和专家评定
第四部分是：对于编码阶段的代码质量自评，专家审核评定
...
5、团队管理
1）团队分工及成长计划
团队分工是项目需要和组员自身需求的平衡体，完全以项目为导向的团队会缺乏向心力和持续的战斗力。例如：
a、一个很优秀的组员，最近妻子怀孕临盆在即，那么项目组不应该给其安排工作量特别大的分工。
b、一个做技术很好的专家想转型为管理人员，那么继续安排他写代码也是不合适的。
好的项目经理应该了解项目组员的工作背景，家庭背景，工作诉求。团队分工时能够考虑大多数或是优秀人员的诉求，并同他们制定成长计划，这种激励是长期的。如德鲁克所说：“管理的本质是获得追随的人”
2）言路畅达（尊重）
发言权涉及到尊重他人的话题。
3）团队的口号、文化
团队的口号决定团队的文化，口号可以由大家一起讨论制定出来，好的口号往往是项目成功的最关键的心态因素的简写。我经历过两个项目组的口号如下：
a、细心，细心，我们再细心一些 （这个项目的特点是将近10个分支的代码合并到一起）
b、担起自己的责任  （这个项目的特点是模块关联性不高的新模块）
4）奖罚项
口号毕竟是虚的，设立了明确的奖惩措施后，比较容易让文化落地。奖罚项可以针对个人，也可以针对小组。例如：
a、强调细心的项目组，在编译打包出问题时需要犯错误那个人给整个团队买王老吉。
同样对于代码互审阶段做得最好的人，要给予奖励
b、强调担责任的项目组，在项目模块没有按期完成的情况下，模块负责人应该安排加班，优先自己搞定。
另外奖罚要做到对团队有更大的影响，需要做到短期，及时通报当前情况。
a、短期，就是奖罚的结果不能拉得过长，不能在项目结束时在评定，这时候木已成舟，对项目本身已经起不到作用。
b、及时通报，就是要按周或按天通报当前的数据统计情况，以便更大程度的影响大家的日常的工作心态
5）里程碑庆祝点
里程碑庆祝的重要性
6）项目团队的例行日程
尽量将项目组能例行化的工作时间表明确下来，这样避免大家工作总是无规律的打断，影响工作效率。
例如：
a、项目组总是周五打包，打完包后验证基本功能，如果基本功能有问题，责任人需要当天排除出来，否则周末加班搞定。
b、每周日自动使用上周五的新包，升级所有测试环境
c、每周一项目周会，项目经理讲述项目当前情况
d、每天下班前，需要发送当天的日报给组长，组长在第二天早上10:00批复

lsekfe

需求分析相关课程推荐：
软件测试轻松学之测试需求分析  点击进入 >>>
基于用户故事的需求分析与任务设计 —— JAVA电子消费账单应用程序实战  点击进入 >>>
软件需求精讲 点击进入 >>>
软件测试轻松入门之测试执行篇 点击进入 >>>
软件测试基础教程 点击进入 >>>
自动化测试管理 点击进入 >>>
软件测试用例设计项目实战 点击进入 >>>