项目过程中项目需求管控实际问题总结

为什么80%的码农都做不了架构师？>>>   

1. 项目需求管控

2.  1.1 需求之前提

第一注意事项．

客户对于产品未来什么样是没有概念的，在项目开发过程中，客户也会因不断学习而产生心的想法，导致会追加需求。也就是说，客户确切来说，并不能确定需要什么，因此需要我们去给予他们什么，减少他们思考的过程，也就是说我们提供好方案，让客户去选择，而不是让客户去思考，让客户提需求。

即需求的过程，是以我们为主导。这样主动权在手，需求就好把握。一旦主动权被对方掌握，就会一直被动接受需求，且这个状态很难改变。

在客户需求过程中，客户的不同群体有不同的要求，有的合理，有的不合理，

这时候，在需求讨论过程中，需要我们去指出不合理的，予以说服。说服对方放弃其提的需求。

说服客户，是我们必须要做的，因为我们要比用户专业，用户才会听我们的。以后即使有需求增加，也会减少。

第二需求范围

首先分析提出需求的客户方的各个方面的诉求。

         技术部门关心的是技术架构，实现，BOM单，设备采购，安全。

         各个业务部门各自的诉求也不同，企业部 关心把所有企业的功能搬到客户端。

         个人的关心个人业务， 业务部关注增值业务带来收入。

         项目部门关心的是人员，时间，技术力量。

也就是说，需求不仅仅是功能，包括上面多个方面。从多个方面照顾到，并可以利用互相之间的需求冲突，减少某一方的需求。比如某个需求，技术实现不了。

1.  1.2 建立需求原型

         和客户沟通需求的首先要先自己设计好方案，然后让客户去选择和提意见，而不是让用户去自己思考。

         首先，根据网银的业务，设计手机客户端的原型Demo，原型的要求一定要和

实际后的效果保持一致，效果界面，流程保持逼真。

           让用户开始就知道，以后做出的效果是怎样的。

         其次，基于这个基础上，和客户展开需求讨论。每讨论一次，就修改一次原型。

      在讨论过程中，需要有个教育过程，即客户提出的需求，有的不符合移动规范或手机客户端规范，就需要说服教育，告诉他们应该是怎样的。

   原型敲定的期间，美工要先跟上，确定好页面和效果。

1.  1.3 确定原型和接口要求

原型确定好后，再确定技术接口，BOM单，并形成需求文档，开始进行评审。

原型截图放在需求里。

文档包括：需求记录，需求文档，原型

1.  1.4 定稿并约定原则

需求确定好后，约定好，如果有新的需求，超过多少时间的，必须走需求变更评审。

低于这个时间的，比如几分钟可以改的，可以只记录就改变。

也就是说，不是所有的需求都拒绝，而是在可控成本和时间的情况下避重就轻，让用户感受我们做的很多了。

大领导提出的需求一定要改，需要给领导面子，多数领导一般提的是界面问题，比较容易改。

 给客户做了一个，但要让用户的感受是我们做了10个。

  一旦约定好，那么就不容易随客户随便改动。

1.  1.5 需求增加和变更

开发过程中会有需求增加，原则：客户领导提的要求，改动不大的话，可以改动，这种事要高调做，让客户感到，我们为他们多做了，而且做的很多。

      改动大的话，提请需求变更，或延到二期处理。

转载于:https://my.oschina.net/mellen/blog/192805