大话需求分析中的方法论（2）

        用户在通常情况下有两部份人与软件公司的开发人员接触，这时其实项目需求的风险有时会更大；因为业务的决策者通常会将重要的沟通任务交给了用户单位的信息管理人员，而这些岗位上的人员由于种种原因有一种职业优势，更容易出现生物工程的需求。
        先举一例（首先说明，在这里的例子虽然是从实际工程中提练出来的，由于可以理解的原因，需求是被修订了的），我们的用户需要上OA系统，而我们正好有OA产品；但由于用户需求的差异，每个用户的OA都是需要进行一些小的修正以适应用户在习惯上的差别。当客户单位的信息中心技术人员向我们的项目经理描述需求时，他头脑中有完整的OA产品功能与性能，因为在这之前他已经了解了许多OA产品，于是他就找了一家他认可的公司产品做为需求向我们提了出来。
        当我们的产品经过两周的调整后，布置到了用户的系统中，这时客户信息中心的技术人员很认可系统的功能，我们的项目经理也很轻松，可当领导来认真的考察一番后，对产品非常失望，因为重要功能与他们的要求相差很远。

        为什么会出现这类问题？其实到现在我还没有说出这是什么客户，我想有经验的项目经理早就在心里问了吧，对了这与用户的业务有着很重要的关系，这是人大办公厅，在通常的政府办公厅（室），公文流转是OA中的核心内容，可在人大办公系统，领导最关心的不是公文流转，而是会议系统，并且是相对比较复杂的会议管理，其实这与人大的核心业务有着很大的关系，不论是提案还是协调，都是在不同的会议中进行处理，而且每年都有重要的会议需要管理。我们的项目经理在并没有认真分析客户业务的情况下，轻信了所谓需求与方案，做了个小小的“生物工程”。

        当然要避免这类问题并不难，难的是能有一些方法及时发现这类，能在不同的项目中识别用户真正的需求，确实需要一些技巧。

《待续》