项目需求

出自 MBA智库百科(https://wiki.mbalib.com/)

项目需求（Project Needs/Project Demand）

　　企业要明确的需求不可单一理解为明确我要管理什么，而是我对要管理的目标怎样实现。整个过程强调的是管理的目标和管理的方法之间的关系，只有立足在这个关系的基础上，才可以保证做到真正明确需求。

　　当企业有信息化方面的项目规划时，企业经常会得到来自很多方面的意见，以指导企业在选型的初期应该怎样做。其中，肯定会有共同的一条，那就是“明确需求”。由此可见，明确自己的需求在信息化选型的初期阶段是多么重要。

　　但是，所谓的“明确需求”到底是要明确什么呢？是明确管理的目标，还是管理的方法？这却是企业很难把握的。另外，需求是怎样产生的？或者说需求应该怎样产生，才可以保证最后产生的需求是既完整又合理的？这同样也是很多企业都很难做得好的一件事。

　　一般来讲，在最初的需求调研阶段，这部分工作大都是由公司的管理部门或从事分析工作的人员来完成，而调研人员考虑问题的出发点往往只是让企业的管理水平有一个飞跃，但是却容易忽略企业的现状，或未能完整深刻地对企业的实际潜在性需求进行调研，这导致在实际应用阶段之时，很多部门觉得不太适用，甚至导致各个部门怨声载道，于是不得不宣告失败或推倒重来。所以处在这个阶段的企业，需要有一种科学的方法来指导自己确定真实准确的需求。

　　首先，企业要明白一点，现在所需要了解的不单单是企业目前的需求，而是要制定出企业长期发展的阶段性战略目标，并以此为依据，来制定各个阶段的需求和发展计划。特别是对于处在快速成长发展期的企业而言，企业会在较短的时间内经历多个成长的阶段，在不同的阶段会派生许多不同的管理需求。只有企业明白了自己需要管理什么，才可能制定对应的管理方法。这样的战略目标的确定是分阶段的,企业只有根据自己企业的特点或者行业的特点制定出阶段目标，才能够明确自己每个阶段的管理需求。

　　同时，无论是制造业还是流通行业，都强调物流和资金流这两个闭环。那么，这两个闭环中的每个环节都存在管理上的需求。在对这些环节进行定义时，不单单是要定义管理的各个环节的管理目标，更重要的是要定义各个环节之间的关系。企业只有按照这样的方法制定阶段性的发展目标，才可以完整地对各个环节进行管理方法的定义。

　　其次，当企业已经制定了企业各发展阶段的战略性目标之后，根据各阶段的目标进行管理的规划就比较简单了，因为企业已经明白了自己需要管理什么，剩下的只需要探讨管理的方法就可以了。按照既定的战略性目标制定每个环节的管理方法的时候，一定要本着立足本部门的需求，放眼整个公司的管理目标的原则来制定管理方法，只有这样才能保证本阶段的管理方法的科学性以及合理性。

　　最后，在对各个环节的管理方法进行定义的时候，不但要考虑管理的目标通过管理方法的实现，而且要注意前后两种管理方法的差异。只有注意了两种管理的方法的差异，才可能保证两种管理方法的平稳过渡。

　　同时，公司的管理部门或从事分析工作的人员在做各个部门的需求调研的时候，也要在立足企业的管理目标的前提下，充分了解各个环节实际的管理需求。了解他们日常工作实现了哪些目标，对于整个公司的管理目标，他们还缺少哪些，需要补充的是哪些。只有这样才能避免调研开始的时候“没得说”，到了应用的阶段却“说不完”的情况发生。

　　所以，在项目初期的选型阶段，企业要明确的需求不可单一理解为明确我要管理什么，而是我对要管理的目标怎样实现。整个过程强调的是管理的目标和管理的方法之间的关系，只有立足在这个关系的基础上，才可以保证做到真正明确需求。

　　大部分 IT 项目缺乏支持文档，纵然拥有商业案例（ Business Case ）或其他相关文档，也不能很明确地把项目所需的工作涵盖起来，只能建立项目的周边，对项目的实际工作量缺乏描述，这很容易导致项目过程中所产生的变动。

　　为解决这个和问题，国际上已于上世纪 80 年代末期开始采用“工作陈述”（ Statements of Work 或简称 SOW ）来固定范围，同时放弃范围定义（ Scope Definition ）的应用。因为 IT 项目有别于其他基建项目的地方在于基建项目有其他附属文档来支持范围定义，比如在基建项目的项目范围中，一般都有诸如项目的有关设计图则、用料标准等等明文规定，让范围能够非常明确地涵盖基本的工作需求。而 IT 项目的项目范围中往往没有这样的定义。

　　以商业效益来确认功能需求，再利用功能需求来建立项目范围。而在范围确认后，我们紧跟着必需建立详细的工作需求和项目计划，否则项目的工作便像橄榄球内的充气量一般，可以按照客户的要求随意变动。

　　工作需求和项目计划基本上是利用工作架构分解法（ Work Breakdown Structure ）建立。明确的工作陈述（ SOW ）让渠道商或服务商了解本身的服务承诺，有效地建立项目的成本，降低项目过程中所产生的变动。这些工作陈述应该在销售过程中建立，成为服务合约的内容一部分。万一合约中只有项目范围定义，那么交付小组必须在交付初期建立有关的项目工作陈述，避免交付期间所产生的争议。

　　IT 业内人士多未能把握WBS的实际应用技巧。而有如工作量估算，错误的工作细节将对项目计划不利。

　　每一个项目都有不同的交付物，而每一件交付物需要经过不同的里程碑才能够产生，同时每一个里程碑也需要经过不同的阶段才能够达到里程的目标。每一个阶段需要经过不同的步骤去完成，而每一个步骤需要进行不同的工作。

　　每一个步骤需要完成一系列工作才能进行第二步骤，直至同一阶段的步骤完成才开始第二阶段，而直至全部阶段完成后才能到达一个里程碑。有些里程碑内的工作可以同期进行，但有些里程碑内的工作得等另一个里程碑完成后才能够开始。到最终完成全部的里程碑内的工作后才能够交付项目中的某一件交付物。

　　利用 WBS 技巧来建立交付组合架构，为每一件交付物建立本身的工作需求，可以让我们很明确地说明每一件交付物所包含的工作。这个交付组合架构更可以让我们在同一时间为项目建立有关的工作计划。

　　项目开发的目标对软件用户来说，目标是：项目及时开发完成，达到管理要求，并成功应用于企业管理，为企业创造效益。方案的用途可以让用户在没有使用最终软件的情况下，对未来软件的使用方法和计算原理有足够的认识方案可以正确指导软件开发商进行正确的开发方案可以帮助软件测试工作正常进行方案可以指导用户去使用未来的软件方案可以作为双方认可的项目验收标准。