如何定义自己的OA需求

（一）需求陷阱------贪大求全
　　内部需求的采集一般都是把一叠白纸发给各个业务部门，一段时间后收集上来汇总；然后从各个OA厂商的产品文档中各抽取部分，然后整理出一个大而全，缺乏整体性考虑的需求。作为招标文件，让各个OA厂家去做方案。你还坚持这些需求是客观合理的，而且必须100%满足，如是这样，你离失败不远了。为什么这样说呢？

我们来看看，首先你搜集上来的各个业务部门的需求，很多是站在部门角度去考虑需求，普遍的情况是这些需求充满着本来应该归纳到业务范畴的应用需求。依照这种需求，世上没有一套现成的软件能够100%满足。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。

其次，你的需求要集各个OA软件厂商之所长，而且要100%满足。任何一家OA软件产品，都有自己的特色，亮点。要一个集所有厂家之所长的产品几无可能。如果一定要有的话，代价是实施周期无限期的延长，资金投入成倍的加大。直到开发出一个你认为集各个OA软件厂商之所长的产品来。实施周期无限期的延长与需求的不断变化，永远没有止境，最后项目只有不了了之，以失败告终，这样的前车之鉴还少吗？

（二）需求建议
　　所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，本位主义一概放到后面，先找到一个组织共性的需求———协同，然后才是关键部门的需求，最后才是重要角色的需求。另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。