IT项目质量管理

        再项目需求阶段，使用界面快速原型法，能够准确快速的挖掘客户需求。但这仅仅是开始，经常看到开发人员抱怨：项目需求变更频繁；有许多潜在的需求，只有到产品开发出来后，需求人员才意识到，不知道早干什么去了；这个需求根本不合理，我们系统支持不了；需求人员太有想象力，客户会这样做吗。 如果使用快速原型——我们采用Axcure进行快速原型——会解决一部分问题。

        我们要求需求人员使用Axcure 进行快速原型，这样的原型与真实的产品几乎没有区别，只不过所有的页面都是静态的。客户与评审人员看了以后，马上就会提出要求，这就如果我们开发了一个小版本展现给用户，用户有特别好的直观感觉；原型就是一个“产品”，而且是项目需求调研阶段就与客户会面了，项目有这样一个好的开始，至少成功一半。 于此同时，需求人员在画界面时也会不知不觉的深入思考 

        用户利用快速原型准确全面获取 需求后，就要进行需求分析了。我认为再这一方面需求做的不够，不懂技术的需求也不是好需求。许多需求人员沟通能力很好，无形中做了客户传声筒，至于客户为什么这么做，客户的潜在意图是什么，没有弄明白。所以需求必须懂业务，需求应该是一个业务专家，做到以上两点呢，需求可以利用自己的业务知识结合我们的现有系统给客户提出解决方案，可以说达到第二个 层面面。其实到这里只能算合格，需求应该懂技术，我说的不是开发技术，而且基本的需求分析技术与建模技术，最好需求还要有学习与创新意识。许多需求人员停留在第二个层面，难以进一步进展了。我碰到好的需求人员，能够进行UML建模，从全局给出业务模型，挖掘出客户潜在的需求，可以帮助用户梳理业务流程，甚至告诉用户那些业务可以做的更好，给开发人员业务模型，理解系统下一步应该如何完善，同一个需求给出多个解决方案，对每个方案给出综合评价

        按照敏捷开发的思想，不主张过度设计，其实现在许多行业产品开发设计与需求逐渐模糊。对一些架构框架需要设计，对技术难点要进行设计，业务应用难题要进行设计（应用设计），选择最优业务方案。大多数行业需求仅仅进行简单的数据库设计就可以了。

        接下来要进行开发了，我特别推荐scrum敏捷软件开发，传统的软件开发方式过于重视过程与工具，尤其强调有良好文档与过程管理。但是从来没有见过一个项目完全按照规划丝毫不差的执行下来，尤其是现在需求变化频繁，客户要求多种多样，各种风险难以完全预测。scrum应用而生了，其实自己体会scrum的流程，它更加始终以客户为中心，强调沟通与灵活应变。scrum每一次迭代，都交付潜在可用的系统给需求或者是客户 ，时时刻刻围绕客户转，对客户核心价值给予最大程度的满足。在质量监控方面，计划会议可以保开发正确的产品，演示会议可以保证及时反馈与跟踪，并且督促开发人员保证产品质量，反思会可以保证持续改进与完善。