完成一份好的项目立项文档，需要在开始编写文件前需要明确文档的目的和阅读对象；在项目概况和产品设计环节中注意项目背景、用户画像、用户需求、市场价值、竞品和产品设计以及财务；在项目落地实施阶段给出产品的简要原型、项目的里程碑和资源需求。
各位产品同学，在产品工作中，或多或少都会有这样的场景。你老大给你一个任务，我们要做个XXX产品，计划在XXX时间上会讨论，我们产品和XXX类似，你在周五前给我一份文件，我们去报项目。
有类似经历的产品同学都知道，领导是要一份立项文件。其实这个比较玄乎，正常来说，要做一个什么业务，首先要做市场调研，出个MRD文件，然后再出BRD文件，最后细化成我们的PRD文件。但是除了PRD，大概其他的都是可以根据实际情况进行裁剪的。所以也没有那么绝对。我们今天要讨论的就是这个立项文件怎么写。
以下是我们本文的框架：
1、开始编写文件前需要明确的事情
A、文档的目的
B、文档的阅读或说服对象
2、项目的概况
A、项目背景
B、用户画像
C、用户需求评估
D、市场价值评估
E、竞品分析
F、产品设计与财务测算
3、项目交付物
A、产品原型
B、粗略的项目里程碑
C、项目的资源需求
我们日常产品立项文件大概就是以上的套路，需要根据实际的情况，比如领导的喜好，评审委员的喜好，公司内部的约定模板，立项流程等情况对顺序，内容，各模块详尽程度做适合的裁剪。
裁剪的原则要时刻牢记，以项目成功立项为目标。总之，让人非常失望的是，这件事没有标准答案（我也想有，就没有那么费头发了….）。
下面我们来聊聊每一项具体包含了哪些东西。
一、开始编写文件前需要明确的事情
还记得我前文说，我们对模块裁剪的原则么。我们要以项目成功立项为目标，这是我们编制这份文件的首要需求。这部分内容是不体现在文件里面的，但确实是我们的整个工作的指导思想。
1. 文档的目的
我们是介绍如何编制立项文件，隐含的逻辑是，你已经对你要做的事情有了初步评估，觉得可行，业务能够获得回报，无论是战略意义还是经济利益。
在此之后，你才会系统的去编制这份文件，用来向组织要钱要人要资源。所以没得说，这份文件要达到的目的就是说服组织，通过立项，拿到许可，对你赋予使用组织资源的权力。
2. 文档的阅读或说服对象
文档的使用对象也同样重要，对象不同，其关注的重点也就大不相同。
- 面对财务老大，你需要的是投产比；
- 面对法务老大，你需要的是合规性；
- 面对开发老大，你需要讲明里程碑和预估资源；
- 面对组织CEO以上几个你都需要说明，甚至的补充一些他关心的内容。
从我们组织的实践来看，参与项目立项评审的有CEO、财务、法务、IT老大等。所以我们提供的内容一般比较全，但是我们会尽量控制在20分钟之内讲完，然后就是答疑和讨论时间。
二、项目概况和产品设计
关于项目概况这个环节，我们要回答以下几个问题。我们要为谁的什么需求做一个什么样的产品去服务他？市场上有没有同类的玩家？对用户需求的满足是什么程度？我们现在开发的这个产品还有没有空间？我们来做，对于我们有什么样的好处？
这些问题，在实践中，我们也是放在这个模块来做的。但是仍然要注意“裁剪”。
1. 项目背景
其实主要的是讲这个商业机会形成的背景逻辑。就是他为什么会存在、基于什么业务模式存在。
比如说，我们有些产品是因为有了一个比较好的渠道，有了一批客群。我们针对这部分客群去设计产品，去满足他们的需求。当然了，我们的产品比较特殊，所以这块无法广泛套用。但是基本的背景介绍却是需要的。
2. 用户画像
简单的说，就是我们打算向哪些用户提供服务。在实践中，我们常常去定义这个用户的年龄，性别，职业，收入，所处地域。
当然，更多的维度，还是需要以拟提供的服务来定。由于我们是强客群依赖的产品，经常去评估一个流量渠道是否能做，所以我们会向渠道方要一些数据，与我们既有的用户数据做对比。确定为该客群开发产品的可行性。
在这个过程中，我们也不会只是依赖渠道方提供的数据，我们会找一些行业报告用于佐证。
3. 用户需求分析
在对用户进行画像之后，我们会对用户的需求进行分析，以便确定提供的产品属性。
比如说你是信贷产品，如果你的客群是普通的小职员，那么可能他需要的产品属性是等额本息的小额信用贷产品。
但如果你的客群是企业主，只是用于临时资金周转的，那么他的资金需求就是短，小，急。可能需要设计一款随借随还，循环用信，全线上审批的产品。
当然了，用户需求是可以归类的，行业中也有许多用研报告很明确的揭示了什么类型的用户可能有什么样的需求，适合什么样的产品。从这个角度看，信贷产品的设计是相对简单的。但也许其他产品和信贷需求不一样，不会有这么简单。
4. 市场价值评估
这个模块主要描述我们看准的这个市场，有多大的量级。并且给出一个预估的数值，以便作为后续财务测算模型的输入数据。我们在实践中，主要是去评估这个渠道能够带来多少用户量。
5. 竞品分析
我们对经营同类产品的竞争对手进行分析。例如对于信贷产品来说，无非就是额度，期限，利率，件均，通过率，日均或月均放款量等比较量化的指标数据和还款方式等少数的组合。
通常，一个流量渠道不会只为一家产品导流。我们会参考该流量渠道对接的所有产品，分析所有产品以上几个要素的组合，尽量确定一个或多个产品方案，这些产品方案决定了后续财务模型如何构建。
6. 产品设计与财务测算
在这个模块我们首先会基于以上对用户，需求，市场价值，竞品的综合考量设计几个不同要素的组合产品。对不同产品构建财务测算模型，然后确定一个或多个要素组合。
当然，确定的标准无非就是两方面：一个是财务价值，一个是战略价值。财务价值是我们能够从这个项目中赚多少钱，投入产出比大概是怎么样的；战略价值包含的东西就比较多了。比如说为了与某个合作方绑定合作，或者为了快速扩大规模等等。
由于是自下而上发起的项目，所以我们需要有足够的理由说服评审委员会。最后我们在立项文件里面引用到前文关于市场，用户，需求，竞品，财务测算的分析为方案设计提供有力的支撑。
三、项目落地与实施
根据前文的分析，我们已经确定我们要做什么样的产品，为什么要做这个产品。接下来就需要给出一个产品的初步形态，以及我们期望在什么时间节点完成这个产品，并且提出一些我们能够预估到的资源需求。
1. 产品原型
我们要给出产品的简要原型，通过原型的方式去描述产品形态。也为IT领导评估提供一些依据。通常不需要太详细，能够体现业务主流程即可，也可以另附文件说明。
2. 粗略的项目里程碑
里程碑就是项目生命周期的关键时间节点，简单的说就是分别在什么时间节点启动、规划、实施、测试、上线。
当然，也有更细的里程碑，一般我们按照下图对项目进度做一个简单的估计，立项通过之后，由开发部门进行更加精细的里程碑和进度计划的输出。
3. 项目资源需求
在立项的时候，我们要初步给出一个资源预估，目前我们实践是给出所需资源的类别，但并没有给出数量，这实际是一种耍流氓的做法。
但是作为业务需求方来说，对于开发内部的工作量预估，也难以做出。若要精细化一点，那就提前找对应的开发同学做个简单的预估，这个对于能否通过立项，影响还是比较大。
下图是目前我们给出的材料，其颗粒度可以更细一点。
最后，不同的组织的项目立项有不同的要求。还是需要根据不同的因素进行相应的调整和裁剪。
总之，没有放之四海皆准的模板。仔细思考一下编制文档的目的与受众，对文件的编制有莫大的益处。
另外关于前文提到的用户画像，需求分析，市场价值评估，竞品分析等，每一个单独拿出来都可以写一大篇，可以去看下对应的分享。后续有空，也可以和大家唠叨一下。
作者：安安安强啊
