如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。

如何认识自己的需求？

    99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。

    把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧.

    也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案，依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？

    我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？

    请不要轻率地回答这个问题，你说用公文？别逗了，公文只有组织中不到10%经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？

    所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，对本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫协同。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果，无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。

所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！

    另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。