一个接口需求的曲折路

 

客户这边有个FileNet应用接口的需求，基于已有应用改造，原本开发不是多费事儿的问题，但就是一个简单的问题，达到客户期望值也不是很容易。

 

开始需求人员（基本经理代劳了）与客户经理那边商定，并形成了需求文档。但需求文档中有诸多可选项和需要开发人员抉择或思考需求的地方，不管如何一一确认好后开发了一版。大概文档本身和需求有一定距离，加之开发过程的抉择则相去更远了。

 

而后经理连同开发人员到现场，与客户经理演示项目成果，客户经理对部分功能给予肯定，对另一部分提出修改建议，并同时邀请来第三方使用者协商接口调用情况。但客户经理是按照自己的理解方式提出的修改，加之第三方应用提供商只是来了一家，实际有多家，还是不能全面了解全部真实需求（这一点当时只是有所模糊的认识）

 

在第二次建议基础上进行修改，客户经理认可后，到年底了，客户那边更高层需要确认项目情况，大概还有项目结算的问题。公司部分高层，项目经理，开发者一同与客户开会演示。但软件效果并不满足客户高层需要。除了追究了些细节，更重要的是初步真实的得到了客户所需要的，是为多个应用提供一个文档接口，使客户应用程序只需调用该接口，传入单据号，即可查看该单据号下的文档，并能对其进行操作，及日志查看。而之所以要该接口是由于原诸多应用对文档的操作管理不够完善，需要借助FileNet平台统一管理，如客户需要在多个应用间的不同业务场景下使用单据号和对应的文档，除此外单据的其他内容在不同应用间的业务场景下都不一致。

 

依据上面的信息，又进行了一次修改，之后同上次一样进行了规模性会议（除此问题还要讨论另一个项目问题），但这次仍旧不满足客户高层的认识。不过这次较为具体的说接口中要有什么，要去除什么，要什么形式的等等内容。

 

这次修改正在进行中，碍于工作多人短缺还有些收尾工作要暂放一放，大概还会有下次修正，不过基本可以说满足了客户高层对这块的要求。但该功能仍旧隐藏着一个问题，就是项目最原先虽然和客户高层要求的相距较远，但它却满足了一些业务部门的需求，如检索等，而当前版本的在客户回访时是不满足的，但这些客户也是默许以高层为主，后续功能再议的。

 

 

上述问题是多种因素（开发人员、项目经理、客户经理、业务部门、客户高层）导致的，也许跟客户与公司这种开发模式（两边经理碰头）有关、也许跟公司开发方式有关（团队构成不成熟，需求确认不明确等等）。不管是由于哪种原因，但深陷其中后应该考虑，如何减少甚至防止双方的误导或误解，如果改善目前的需求调研、开发、测试等等过程模式和方法，如何了解到其他公司更为优秀的方式。也许这些问题仅限于此公司的这种环境，但不能让其多次重复。