项目和产品相关性较强，所以在分析两者的范围和需求的之前一定要先弄清楚两者的关联关系。

项目在签订之初是已经规范了项目的范围，之后交付的内容也会在这个范围之内，而产品作为交付项目中最核心的一块是一定要符合项目范围的，产品是为项目服务的。

1.项目的范围和需求

2.产品与项目的范围

一个产品发布到项目，如果之后在产品端发生了功能变更势必会影响到项目，所以在做产品前是要去与项目沟通，或者去做市场调研。

从上图可以看到产品与项目之间是互相影响的。

3.项目的需求收集

4.编写物流项目的范围说明书

5.WBS工作分解结构

图上的规范周期需要说明一下，这个是指工作细化到什么程度，比如规范周期是2天，一个工作规划3天那就继续放下拆分，直到拆解的小任务2天内做完为止。

状态标记是：开发、未开始、延期等。

6.WBS拆分维度

拆分维度一般有两种：

• 按照项目的阶段去分解
• 按照项目的结果去分解

一般在编制WBS的时候可以使用一些工具来做，比如windows环境下的project工具，mac下可以使用merlin project，下面的图就是merlin project这个工具的实例图：

我们可以在这个甘特图上根据原型需求来编排工作拆分任务，然后可以分配给成员，并设置前后置的关系以及工作时间。

7.需求变更

在前期一旦去定好的需求，后面但凡是有需求的变更就需要走流程，让相关领导去签字，下面是整个需求变更的流程，大家可以根据自己项目的实际情况有所变通，但是最终最好是有需求变更流程的纸质或者邮件文档，以免后面项目交付双方争议。我个人就遇到过，一个功能点反反复复的变来变去，或者就是开始变更没有记录好，后面翻脸不认，所以不要觉得麻烦或者不好意思，丑话在前面说好以免后面尴尬或给自己挖坑。

如果确定需要变更，那么就得走流程，向高层提出变更请求，说明变更内容，原因，影响，需要时间，方案等信息。

8.项目变更请求表

流程走完之后就可以去着手做需求变更的事情了，文档或者相关邮件要做好保存以备不时之需。