软件项目怎么快速响应用户需求

做IT项目管理的朋友都知道，时间、范围和成本是项目管控的三要素，但是对于用户来讲，他们通常更关注三要素里面的时间，即项目进度问题，因此如何快速满足需求就成为了一件很重要的事。

 

 

日常工作中，相信很多项目经理都有被需求方催进度的情况，有时候需求方领导一个简单的想法，经常会要求快速地做出来上线，极端的情况是今天提了需求明天就要实现。

 

项目管理不是一件容易的事情，很多时候要平衡多方的利益，哪一边没照顾好，很快投诉就过来了。但不管怎么说，凡事都有优先级，关键干系人如用户高层和公司高层的需求通常是要最先需要去做的，那么对于软件项目的交付，从公司层面如何更好地响应需求提出方的需求呢？

 

见过很多面向政府也面向企业的项目，很多公司的交付无外乎分这两类模式：

 

第一类是产品化交付：

 

比如结合在行业多年的经验，打磨出一套所谓标准化的产品，直接在需求方提供的服务器换做快速化部署，或者把自家的云端软件开账户给用户进行使用。

 

这种模式的好处是能快速铺开市场，哪怕软件卖便宜点也没关系，量一上去了也能赚钱。缺点是当面向需求方定制化需求的时候，会缺少一些灵活性，一般会尽量说服需求方用自己的标准化产品，比如早期的金蝶和用友产品系统就是这种模式。

 

但如今面向企业和政府端的系统，这种模式越来越走不通了，现在的用户都需要有自己特色的定制化系统，要有能出去吹牛B的亮点。

 

第二类是定制化交付：

 

很多刚进入到某个行业的企业，通常来讲都是采取定制化软件来和做产品化软件交付的企业来进行竞争。

 

从用户的角度，他们当然是欢迎做定制的，但对于软件供应商，定制通常意味着需要较长的开发周期和较高的开发成本，一旦控制不好或者研发能力不足，亏本赚吆喝是常有的事情。

 

以上两种模式各有各的优势和劣势，但无论你是产品化交付还是定制开发交付，假如需求方提出的功能在你的产品或过往项目中没有做过，那么快速响应的核心就是组件化设计和开发，可以说没有比这更好的解决方案了。

 

如何理解组件化？

 

简单说就是当我们接到一项新的需求时，在原型、UI设计和开发层面都有一套组件库（或者叫模块库），能够快速的完成需求的设计开发落地。

 

单个的组件是通过一个一个的行业项目沉淀出来的可复用资源，组件本身经过了反复的质量稳定性验证，需求落地过程中通过组件和组件的快速拼装，从而达到快速响应软件新需求的实现。

 

那么组件的设计由谁来做合适？最好是熟悉业务和技术的架构师，这样做出来才会更合理、能比较接地气地应用到不同的项目中去。

 

END

 

招投标软件项目管理实战分享