一个人的小型网站项目当然不需要和拥有300人，1000万美金的容错操作系统项目使用同样的计划流程。一般来说，参加人员越多，越复杂的项目所需要的计划就越复杂。但是，即使是一个人的项目也会从良好的计划中受益。计划可以使你有机会检查你的决策，暴露你的假设以及明确你和公司之间的协议等等。计划可以使你发现许多愚蠢的决定，因为在计划中，你需要考虑很多重要的问题，而且在计划阶段，你也有时间去考虑其他可选择的方案。就像穆罕默德林肯说的那样，“如果我需要6个小时去砍一棵树的话，那么我就需要4个小时去磨我的斧头”。这句话意味着精心的准备可以减少你许多的工作量。
项目计划回答了两个问题。第一个是我们需要做什么，也可以称之为需求分析，另外一个问题是我们怎样做，也可称之为设计或者详细说明。需求可以看作是一个被详细书写的文档，通过它可以保证项目朝着正确的方向发展（例如，准备丰盛的一餐就要保证便宜，好吃并且营养丰富）。好的需求应该容易理解，并且很少产生歧义。虽然实现需求可能有很多种方法，但是当某一部分工作完成的时候，你要确认这一部分的需求是否真的被满足了。式样书也可以简化那些满足需求的计划。
上图中的3个活动，包括需求收集，设计/说明以及实现都是很值得研究的问题，在这方面也有许多值得阅读的书籍。在接下来的章节，我将从项目的角度来阐述前两个活动，而实现则在第14和15章来讨论。
3.1.1 不同类型的项目
关于需求分析和设计的工作，有几个标准可以参照。我会用3个不同的例子来阐述这些标准：
（1） 超人。在最简单的项目里面，所有的工作都由一个人来完成。代码，市场以及商业计划，一个人完成所有的事情，当然项目的奖金也属于这个超人的。
（2） 小的团队。客户雇用5到10个程序员和一个项目经理来完成网站的建设或者应用程序的构造。他们之间是一种契约关系。一旦合同结束，他们之间的这种契约关系也就结束了，除非他们又签了一个新的合同。
（3） 大团队。一个被公司雇用的超过一百人的团队，他们的工作可能是开发一个新产品，或者为公众提供相关的服务。
这三种类型的项目在团队大小，组织结构以及契约关系都存在着很大的不同，这些不同点决定了其管理方法的不同。因此，当你的项目和这几个例子都不同的时候，那么你的项目会成为一种很重要的参考。
3.1.2 你的公司如何影响你的计划
通过以上三种类型的项目，我们可以验证一下项目计划最基本的原则。在任何一个项目里面，都有一些项目成员必须了解的问题。你可能不太喜欢这些问题的答案，但是你和你的团队必须清楚的了解它们是什么。许多项目计划的失败都是由于在这些基本问题上没有达成一致或者根本忽视了这些问题。
（1） 谁负责需求 有些人需要定义需求并且使这些需求能够得到承认（客户或者VIP）。在超人的例子里面，这很简单，他可以做完所有的事情，当然也包括需求定义。而在一个小的团队中，客户会对需求甚至设计都进行严格的控制。最后轮到大团队了，这种情况下，公司内部可能会有专门的组织或者部门来完成这项工作，在这样的团队中，有些人可能专注于上层的需求（这是一辆运动型的卡车），而另外一些人会关注底层的需求（它的速度应该达到20英里/加仑，并且应该是四轮驱动的）。
（2） 谁负责设计 和需求类似，有些人会负责设计的工作。设计和需求不同的地方在于，针对一种需求你可能有几种不同的设计。设计和需求相同的地方在于设计的过程中，你也需要和几个不同的组织或者部门进行沟通协商。可能会有一个人或者一个小组来负责推进设计的过程，而另外一些人则负责对第一组人的工作进行指导和反馈。但是要注意设计的技能包罗万象，所以往往负责设计的人并不一定具有这方面的天分。
（3） 谁负责技术 技术责任者被定义为那些确定项目所要使用的工程方法的人，包括编程语言，开发工具以及技术架构。许多关于技术的决定会影响到需求，设计和预算。设计和技术之间存在着很微妙的差别：用什么去实现一件事情往往和怎么去实现这件事情密不可分。在某些公司里面，负责技术的人往往也负责需求和设计。而在另外一些公司，负责技术的人是一个辅助的角色。当然最理想的状态是，各个角色之间是平等的合作关系。
（4） 谁负责预算 向一个项目添加或者删除资源可以和其他的角色分开。例如，在团队比较小的情况下，虽然团队可以决定需求和设计，但是他们想要更多的预算的话，就需要和客户商量确定。
（5） 需求和设计多久被检查一次，以及如果确定检查之后的修改 这个问题的答案主要依赖于前面的问题。参与需求，设计和预算的人越多，我们就需要耗费更多的精力来使这些相关者保持一致。按照惯例，你拥有的权力越小，那么你就需要花费更多的时间检查和确认你的决策，当然这其中也包括如果修正的你需求和设计。
虽然我定义了几种不同的角色，但是一个人也可能同时担当其中的一个或者多个角色。但是，大多数情况下，这些角色会分配给那些小组的领导者。当然如果这些角色分配的越复杂，你就需要更多的努力来使你的计划行之有效。在第16章，我会阐述如何处理过多的角色分工的情况。但是目前，你只需要认识到计划需要包含这么多的角色就可以了。
3.1.3 一般的计划支付
想要获得准确的需求，你必须把它们记录下来。虽然有许多方法可以完成这件事情，但是在这里我不会指定特定的方法。最重要的是捕获正确的信息，正确的人员可以轻松地讨论它，以及明确的分工。如果你记录的需求能够完成这些要求，那很好。如果不行的话，那就需要考虑其他的方法来记录你的需求了。
作为参考，我会提及一些普遍使用的记录需求和计划的方法。一般情况下，为了表达同一种意思，不同的公司可能会使用不同的词语，如果你能掌握其中的本质含义的话，那么这些将不会成为你的障碍。有时候，你会发现一些不太正式的需求文档，譬如“这个地方，你去问弗雷德好了”之类的话。而另外一些人可能会把这些需求分割成许许多多的部分。
（1） 市场需求文档（MRD） 这是由商业或者市场小组作出的分析文档。目的是为了捕获商机以及项目如何实现这些商机。在一些公司，这些文档是决策者身边的一份参考文档。而在另外一些公司，这些文档是项目定义的核心，项目的所有事情都是围绕这些资料来完成的。MRDS为项目内容的定义提供了帮助。
（2） 目标/范围文档 目标文档就是把一个项目的内容包装成一个单一的整体。如果有MRD的话，那么目标文档将会延续MRD中的内容。目标文档定义了项目的目标，项目的意义，以及项目的高级特性，需求以及期限（见第四章）。目标文档直接定义了项目的内容。
（3） 式样书 这些文档定义了项目可能带来的成果。好的式样书是按照需求做出来的。通过反复的设计，也就是通过不断的修改和改进那些需求来完成式样书。当你的式样书提供一个可行的计划来满足项目需求的话，那么你的式样书可以说已经完成了。式样书可以说继承了目标文档，它定义如果做一个项目。
（4） WBS 当一个式样书定义了工作的细节的时候，那么WBS则定义了如何完成这些工作细节的问题，诸如先做什么工作，谁去做，如果去跟踪那些细小的工作。WBS可以非常简单，同时也可能非常复杂，这主要决定于项目需求。（第7章和第13章）会给出一些WBS的类型。WBS从一个团队的角度定义了如果实现一个项目。
扫一扫
2626
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
