CMMI外传--需求之九阴真经(2011版)

入我门者，先念此经

1、面对不合理的需求

     合理的要求是锻炼，不合理的要求是磨炼。据说有人以此话为名还出了一本书。

     N年之后，你会感谢给予你锻炼与磨炼机会的人；

     2011注：摆正心态之后，作为需求人员，我们要追问的是用户为什么会提这个不合理的“需求”，很多情况下用户提的不是需求，而是解决方案，因为用户只是问题专家，我们才是解决方案专家，所以用户提的解决方案不合理这是正常的。我们需要把用户“需求”后面的问题问清楚，其实不存在不合理的“问题”。

 

2、用户需求经常变

     听说过这一行当里“唯一不变的就是变”这句话吗？再说了用户已经“被上帝”了，所以时准备着吧，要不然CMMI中也不需要“需求变更管理”这一说了。

     当然了，关键是用户变了需求增加了偶们的工作量，延误了工期，偶们要把好处捞回来，别落个吃力不讨好。

     2011注：识别不稳定的需求，列入项目风险进行关注。

 

3、用户提出不需求来

     如果用户签了单给了预付款，那就有需求要上，没需求创造需求也要上；

     再说了需求收集，需求分析好象是还是你的事，老说用户提不出需求来难免有推托之嫌；

     2011注：我们要关注是不是二个都不懂的人在那里讨论需求；有一种说法是对于不明确又貌似有的需求，直接把它扔到垃圾筒里去，如果过几天用户又开始叫了，说明还有点用再捡回来，否则说明这个需求根本不存在，至少优先级到了可忽略级别。

 

4、用户提得的需求自相矛盾，叫俺怎么办

     如果用户好说话，你就掐他；掐不过，当然不能打他，因为平衡用户需求也是你的责任；

     2011注：优先级是平衡用户需求的一种手段，优先级通过二个维度来判断：是否是主营业务、使用频率有多高；说白了就是看谁得罪得起，柿子拣软的捏。当然首先要排除是需求收集错误、需求理解错误导致的的矛盾。

 

5、用户需求文档里没有明确提出那个需求点，所以我没实现

     有些需求叫做派生需求，就是人家不说，地球人也都知道该有的需求。所以，对这于这种情况，地球人只能加班去完成，要怪就怪自己太嫩。

     2011注：今年的主题是“体验创新价值”，所以如果事关用户体验，需求文档可以精益求精。苹果UI需求的水平是像素级。

 

6、需求描述的是要做什么，而不是怎么实现

   此话是对亦非对,CMMI说需求阶段要考虑备选技术方案，用户说标书里要给出技术方案。

   方案里当然会有怎么实现的描述，因为不同的实现成本不同，工作量不同，自然工期也不同，成本与工期都是老板与上帝关心的东西。

   2011注：“用户需求”文档重点澄清用户的业务问题，用户如果提出的“解决方案”,要分析用户是不是作为需求的限制项提出，还是说用户其实是隐藏了背后的业务问题。

            SRS文档，是需求收集和分析后的结果，当然可以有解决方案。

            还是那个说法，用户是问题专家，我们是解决方案专家；心理上，用户往往偏向于以“解决方案”的形式来替代他的“原生问题”，以显得他懂得多，又替你着想。

 

7、需求里可以写上那些因为做不到所以不打算做的事吗

     CMMI说写清楚限制条件也是很重要的需求内容，俗一点的说法就是"丑话要说在前头"，包括那些写进文档但可能做不到的需求，早点告诉人家这是可选需求。

    2011注：去查关于"软件需求"的原生定义，限制与约束是需求的重要内容。

 

8、要知道欲望与需求是有差别的

      肚子饿了想吃饭，这叫欲望不是需求；问清楚想吃中餐还是西餐，吃中餐的话想吃川菜还是杭帮菜，在公司食堂吃还是打个车到西湖边吃，打算花6块钱吃盒饭还是让你请客，这才是需求。

      知道讨价还价了，说明道儿毛老，老甲鱼裙边已经快拖地了。

   2011注：从需求收集角度来看，要对“问题->原因->决策”链进行系统性思考，如果用户给你描述的是“决策”，你要挖掘背后的“原因”及对应的“问题”；用户倾向于帮你作出“决策”，越是高层的用户越是这样。经典语录：“顾客不是要买钻头，顾客要买的是洞”

 

9、需求写得越直白越好，能让地球人理解一致是第一要务

     偶们的方块字博大精深，“借张三人民币一万元”不知道是欠人钱还是别人欠你钱；“完胜”与“完败”都表示赢了；

     如果你存心想在需求里搞点文字游戏，那机会是很多的，比如:可以把一些又大又空的话当作高层需求；编个惊人的性能指标，就是不写清楚是在什么样的硬件配置下达到；描述一个超炫且根本无法验证的功能；

    2011注：写文档的目的：

        一是作为交流工具，所以要见人说人话，见鬼说鬼话，人话和鬼话混在一起写，结果人也看不懂，鬼也看不懂，失去了交流的作用；让用户签字确认的需求文档，是不是用户真的看懂了？

        二是作为备忘，为了保证回过头来还能看懂，多写点背景，多写点事实背后的原因，让人知其然而知期所以然，特别是涉及到解决方案；

 

最后，附送一个恒生传说：Long long ago，我们胡希明老师年轻的时候带队进京做项目，某官提一需求，要求系统在输入后一秒钟内就有反应，胡老师据理力争认为不可能达到，未果，被迫写入需求；验收时，只见一敲回车，屏幕上每秒一个点，一个点，一个点。。。

 

2011年注：Good Good Study,Day Day Up。当有十年的经验可以炫耀时，不妨学点科学理论，科学理论的最大特点就是指导你进行系统性思考，符合恒生“SERVES”模型第一条；事情想通了，处事也就从容了，浮燥的时代更需要从容的心态，“管理学”也说管理者的最高境界就是：想得通、说得通、行得通。