对软件项目中产生的需求进行分级管理

1/11/2010 7:40:40 PM 客户的需求是否应该得到满足？软件工程是否目的就是满足客户的需求？这个问题看来是无法加以回答的，因为，它没有提供两个基本的解释，其一：客户的需求即算从客户的利益立场出发，是不是合理的？其次，客户的需求有多大程度上是必要的？还是只是一种个人的喜好？ 如果说对于商业客户来说，在项目开始前，还存在着做与不做；以及多少价钱来做的选择的话，那么，在许多情况下，工程人员如果不对此有明确的立场，唯一的结果就是累死自已，而软件项目永远不令人满意，也永远不能完成。对于商业性客户来说，客户的需求是否合理是客户自已的事情，客户永远是对的，这句口号的台下词是：只要客户肯掏钱，那怕他要跳海，那也是他自已的事！但如果项目是已经签署定的合同单，那么就存在着是否按原合同继续，还是中止，还是变更付款条件的的问题。而对于内部项目，所谓的成本就是工程人员有多累和什么时侯累死的问题。这时侯，软件工程从业人员最好能够明白，在自已累死以前，老板，以及那些不学无术对技术一窍不通却自以为是行里大家的同事，都不会对你有任何怜惜的。 所以这时侯那种无条件满足客户需求的工程需求管理就不适用了，这时侯，软件工程人员只能根据自已能够承受的工作强度对各种需求进行取舍，而不是无条件地牵就“客户”的需求，更不是迁就无知的需求。客户是上帝这句话这时侯完全不适用，因为客户不会为朝改晚改的需求付钱，付帐的是程序员自已——让自已早点累死。 把种种需求明列并分级是唯一的办法；自已就按步就班一点点地完成，这是唯一的办法。事实上，对于商业客户这也是适用的，因为收钱的毕竟是公司老板而不是项目组的程序员，公司老板收了钱就不管实际项目成本是多少而让程序员无条件接受客户的需求也是常见的事情。所以把需求明列，既是让老板明白眼前项目的成本到底是多少（老板通常是技术盲），也有了与客户讨价还价的根据。 我把需求分成五个等级。五分等级也是工程技术上的常用方式，如同大学的五分制。 一级需求（或改变）是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这是必须满足的，否则就意味着否定程序员自已。所以定为Urgent.； 这通常是属于补救性的debug类型，要救火。 二级需求（或改变）是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续。所以是NECESSARY；一般新模块关键性的基础组件，属于这个级别。 三级需求是后续重要的需求，它不能满足会令整体工作价值下降，为了体现项目价值，也是程度员自已的技术价值的证明，所以定为NEEDED；一般性的重大的有价值的全新模块开发，属于这个级别。 以上三个等级是应该实施的，但时间性上可以作优先级的排列。 四级需求是改良性需求，没有它并不影响已有功能的使用，但实现了，有可信的根据可以是BETTER.界面和使用方式的要求，一般在这个档次。 五级需求是可选性需求，没有它没有谁会活不下去，有了它，没有根据一定带来好处，更多是一种设想，以及一种可能；通常只是需求代理人员的一种个人喜好。所以是MAYBE。 对于四级需求，工程人员项目有空，不妨做下去；对于五级需求，有兴趣有余力就做，没有兴趣或者没有余力，管他需求不需求，除非额外付大钱，就让提这些外行需求的家为一边凉快去。