从需求来源说起

需求，客户的要求，有合理的，也有不合理的，对于纷繁复杂的需求，怎么样找到客户的关键性需求，就显得尤为重要。

 

去年在公司接手一个项目，受某地省厅的委托，我们开发了一个针对全省范围内的县级版的一个管理信息系统，开发完成后，省厅负责给各县市进行推荐。历经半年的开发，终于完成了系统的开发，并经省厅测评验收合格。本以为收取果实的时节到了，结果事实并非如此。按省厅要求开发的系统仅仅是能满足省厅的一些基本要求，最后落实到各县市，并不能满足各地的具体实际需要，结果就是，我们不停的根据各地搜集的需求继续返工，重构，成本急剧上升。

 

现在想想，当时也真是够傻够天真的，竟然盲目的完全按照省厅提出的需求来做一个给县市级用户用的管理信息系统。

 

现在看来，需求来源大致可以分为两大类，一个是需求的提出方，另一个就是系统的具体使用方，在这个项目中，由于这种情况真是让我们吃尽了苦头。起初，所有的需求都是由省厅提出，但是落实到使用的时候，又是县市级用户，明显，具体的各个县市级用户肯定也会有自己针对本地具体业务的一些更实际的需求。由于开始压根就没想到会有这种情况的出现，直接导致系统在后续的升级上出现很多限制，很多情况都没考虑，改来改去，原本还条理挺清楚的一个系统，就慢慢的改的面目全非了。慢慢的就出现恶性循环，一个个天坑就慢慢的开始形成了……

 

现在，如果时间、成本允许，我真想把系统全部重构一次，如果再有类似的情况，结果肯定也不会再是这个样子。

 

只是这样代价确实太大了点。