项目管理日志一：如何写好《软件需求规格书》

（一）出师不利
在没有多少项目管理经验，仅仅是编过一些程序，学习了一下微软项目管理的课程，就被公司推到项目经理的位置上。内心惶恐，能不能做好自己心里都没有底，另外有赶上公司要过CMM，我们项目组恰恰是三个试点项目之一。以往直接进入编码的不良习惯，使得在CMM试点期间创作诸多文档成了一件头疼的事，相信这也是许多初为项目经理的人常碰到的问题。

首当其冲的就是《软件需求规格书》，规格书是软件需求分析的最终成果，是沟通客户、项目经理、开发小组、测试人员和公司高层的基础，是获取各干系人承诺的法律依据。我们项目组是负责开发一个大系统中的一个模块。在没有什么经验的情况下，我们把和用户签订的技术协议书中规定的软件功能提出来罗列到需求规格书内，再费尽心思的把技术协议中的对软件性能和质量属性的要求挖出来，自然作为规格书中的非技术类需求，然后费了九牛二虎之力配上界面草图，然后根据测试人员的要求根据界面中进行的功能操作罗列了若干条激励响应序列，最后，看着几十页的规格书，自己也觉的相当满意。但是，评审的时候评委们给了我们当头一棒，测试人员竟然说他们看不懂这些功能是怎么实现的，最后给我们提出了几条罪状：
1、功能划分的颗粒度不一致，有的大，有的小。
2、功能之间的相互联系没有很好的表现出来，通过什么样的操作能够由一个功能过渡到另外一个功能不明确。
3、激励响应和功能的对应关系不清晰，不知道那条激励响应对应那一个功能。
4、许多输入输出都不可测。
《软件需求规格书》失败了，事情就是这样，自己写的东西自己觉得非常明确，可别人就是看不懂，更谈不上什么沟通和承诺了，如何站在不同的角度上写作规格书是一个值得考虑探讨的问题。不得已，只好重新策划软件规格书，又是一个轮回，不仅慨叹项目经理的滋味不好受呀。
PS：如果你恨一个人，就让他当项目经理！如果你爱一个人，也让他当项目经理！待续
（二）