剖析进销存管理系统软件需求管理重要性



软件进销存软件系统是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的进销存软件系统具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的进销存软件系统，是有形的、客观的、可描述的、可检测的，软件进销存软件系统是软件项目最难把握的问题，他的复杂性体现在以下方面：进销存软件系统的描述问题笔者曾经被紧急委派主管一个已经进入了编码后期阶段的项目，该项目已经换过2次项目经理了，这是第3次更换项目经理，用户方的IT部经理找笔者抱怨："我已经是第3次来给你们讲补货申请的处理规则了！".我只能表示抱歉，因为我无法找到原来的进销存软件系统描述，这是一个变更的进销存软件系统，前任的项目经理讲他只是将当时与用户交流的进销存软件系统记到2页草稿纸上，不幸的是，那2页珍贵的手稿现在已经找不到了！更不幸的是，该IT部经理是在转述业务部门的进销存软件系统，当软件开发完毕后，业务部门讲"这不是我们最初给IT部反映的进销存软件系统，我们说的不是这样的！".缺少正式的完整的进销存软件系统文档浪费了大量的人力物力，但是有了进销存软件系统文档又出现了新的问题。曾经有多个项目经理向我抱怨，在用户方进行的进销存软件系统评审会完全是走形式，因为用户根本不去听他读那上百页的进销存软件系统文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为进销存软件系统专家是不现实的。

    进销存软件系统的完备程度问题进销存软件系统如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举进销存软件系统几乎是不可能的，每次开进销存软件系统评审会时，总会冒出新的进销存软件系统，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。

    进销存软件系统开发的工期问题在进销存软件系统上花费了大量的时间（而不是人*工时，因为进销存软件系统阶段人多了也没有作用），客户、软件公司是否能够忍受？为了确保进销存软件系统的正确性，完备性，项目经理往往坚持要在进销存软件系统阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的进销存软件系统折腾的筋疲力尽，他们也希望尽快结束此阶段。

    进销存软件系统的细致程度问题进销存软件系统到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，进销存软件系统的周期越长，可能的变化越多，对设计的限制越严格，对进销存软件系统的共性提取要求越高，所以只要大家（客户、用户、进销存软件系统分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。

    进销存软件系统的变化问题在软件开发过程中如果只有一条真理的话，那一定是：进销存软件系统的变化是永恒的，进销存软件系统不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，进销存软件系统的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从进销存软件系统的变化中发现市场机会。

    进销存软件系统变化的原因很多，如：一开始没有识别全，需要增加进销存软件系统；业务发生了变化，进销存软件系统必须变化；进销存软件系统错误；进销存软件系统不清楚；进销存软件系统的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了进销存软件系统变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，进销存软件系统的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使进销存软件系统在受控的状态下发生变化，而不是随意变化，进销存软件系统管理就是要按照标准的流程来控制进销存软件系统的变化。

    难题随之而来，进销存软件系统中的变化一般不是突发的革命性的变化，最常见的是"项目进销存软件系统的渐变"（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。控制进销存软件系统渐变需要注意以下几点：（1）进销存软件系统一定要与投入有显示的联系，否则如果进销存软件系统变更的成本由开发方来承担，则项目进销存软件系统的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的进销存软件系统变更。但是，接受进销存软件系统变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：进销存软件系统变，软件开发的投入也要变。

    （2）进销存软件系统的变更要经过出资者的认可，进销存软件系统的变更引起投入的变化，所以要通过出资者的认可，这样才会对进销存软件系统的变更有成本的概念，能够慎重地对待进销存软件系统的变更。笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量？quot；小"的进销存软件系统变更，当开发人员按此进销存软件系统变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的进销存软件系统为圣旨，却忽略了进销存软件系统是否经过了客户方真正有决策权的人员的认可。

    （3）小的进销存软件系统变更也要经过正规的进销存软件系统管理流程，否则会积少成多。在实践中，人们往往不愿意为小的进销存软件系统变更去执行正规的进销存软件系统管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使进销存软件系统的渐变不可控，最终导致项目的失败。

    （4）精确的进销存软件系统与范围定义并不会阻止进销存软件系统的变更。并非对进销存软件系统定义的越细，越能避免进销存软件系统的渐变，这是2个层面的问题。太细的进销存软件系统定义对进销存软件系统渐变没有任何效果。因为进销存软件系统的变化是永恒的，并非由于进销存软件系统写细了，它就不会变化了。

    注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于进销存软件系统的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为进销存软件系统的变更付出更多的投资，开发方有可能是主动的变更了进销存软件系统，他们的目的可能是使软件做的更"精致"，于是作为进销存软件系统管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。

    软件进销存软件系统的复用问题笔者曾经遇到过一位领域专家，他在有20多年的领域工程经验，积累了大量的领域进销存软件系统，可是在其每进行一次产品开发时，他总是感到他所理解的进销存软件系统无法为与他配合的分析人员、设计人员所接受。当我们一起来讨论这个问题的时候，共同的一个观点就是：没有对进销存软件系统进行有效的管理，已经形成的进销存软件系统文档没有很好的复用。所以进销存软件系统管理一个很重要的目标应是提高软件进销存软件系统的复用率。

    基于上述的问题，必须对进销存软件系统进行管理，使进销存软件系统能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件进销存软件系统保持一致，使进销存软件系统可以复用。