在多数公司中，开始做一个项目前都需要准备一份项目可行性报告，告诉领导项目的机会、风险如何，同时需要哪些资源。那这个报告由哪些部分组成，如何准备？来看看作者的分享。

如何写好一份项目可行性报告？（如何写好一份项目可行性报告范文）

一、为何要写项目可行性报告

项目可行性报告，相信各位日常工作中听得不少，写得更多。在讲如何写好这样一份报告之前，我们先来搞搞清楚，为什么要写这么个项目可行性报告？

到底是形式主义还是真有必要？

至少在笔者看来，是真有必要。

首先，我们来明确一下，项目可行性报告是项目可行性分析这项工作完结时所要交付的一个结果性文件，它的内容直接指向经过分析最终形成的结论。那么，一般在什么时候会开启“项目可行性分析”这项工作呢？

没错，当企业或某个团队有一些想法，甚至一个念头，需要全方位科学地判断某件事该不该干、可不可干的时候。

至此，我们就可以明确，项目可行性分析是为了获得一个问题的答案而存在的，这个问题是：某件事该不该干、可不可干？

而要得到该问题的答案，不是拍脑袋定的，而是需要经过一系列科学严谨的业务分析活动，包括：信息收集、内外部调研、信息整合与分析等。

接下来，这项工作的重点便可以翻译为：为了科学准确地判断出项目可行性，如何设计和开展调研工作，需要拿到什么关键结果？如何拿到？

二、业务调研

要知道一个项目/业务该不该干，须得先摸清楚业务的现状、目标、可行性和投产比等一系列事宜，也就是先做好业务调研。那么，开展业务调研工作是不是一个猛子扎进去，直接找到相关业务方做沟通访谈，干就完了呢？不是的。

业务调研也是要有章法的，所谓谋定而后动。在开展具体的业务调研工作之前，需要先制定业务调研的计划，明确业务调研目标(包括内外部目标要区分开来)，被调研对象，时间计划等。此外，整个业务调研需要基于方法论先搭建框架，再通过具体的调研过程填充血肉，带着目的和问题去调研，在调研过程中捋清事实找答案，最终形成可以回答目标问题的结论。

1. 业务调研核心成果——业务流图

完成业务调研后绘制的业务流图一定可以被称为整个调研工作成果的灵魂，亦是整个项目可行性报告的“报眼”之一。

以B端产品经理的工作为例，开展业务调研是做某个业务系统产品规划和方案设计的必备前置工作项，通过业务调研梳理出完整的业务流，才可以对应得出应规划哪几个模块，每个模块承载什么工作及各模块间的关系，用户主操作流/异常信息流等关键性信息用以指导产品设计。

再以数据产品经理的工作为例，最为关键的数据流同样要依赖业务流才能整理出来。并且从站位更高的视角来看，数据价值的体现必然要从业务流和管理流中寻找可落地融合的场景和机会点，因此，即使是不直接操刀业务系统设计的数据产品经理，对业务流有完整而深入的认知也是项目成功的助推器。

2. 如何搭建业务调研框架？

接下来，我们来讲讲搭建业务调研框架的方法论。换句话说，一个完整的业务调研框架需要哪几个要件？请往下看。

业务现状

属于对内调研的范畴，摸排清楚自己要做的业务线->企业->生态的业务现状是必不可少的，但对于这三个不同层级对象的摸排工作细致程度的要求也是依次降低的。

对于业务现状，我们需要通过调研结果了解到关键业务和期望获取的关键业务结果是什么，以及目前业务是如何跑起来的。

比如某视频平台会员事业部的关键业务就是会员管理，期望获取的关键业务结果有三个：1.新会员增速上升20%以上；2.老会员续费率不低于70%以下；3.会员粘性日均提升0.1h。会员管理手段主要是引流、提供优质会员内容和做会员权益成长体系。

痛点问题

摸排清楚业务现状之后，我们就需要分析并梳理出现状中存在的痛点和问题，并明确这是当下亟待解决的问题还是当下并不凸显但可能在未来带来不利甚至致命打击的问题。

我们也需要对痛点问题进行分类，比如哪些是组织缺位，哪些是能力缺失，哪些是流程规范性滞后或不匹配等。不同类型的问题有不同的最优解法。不宜一概而论，宜分类讨论，各个击破。

业界做法

属于外部调研的范畴，在搞清楚自己企业的相关业务领域现状和痛点问题后，也先别急着一股脑输出需求索要排期接着直接开干，这样做是体现了极强的执行力，但可能用的是蛮力，也可能不是全局最优解决方案，最终一算投产比，不划算。对于已经明确的痛点问题清单，除了根据业务上的紧急程度和价值来评定优先级外，还可以同时采用的办法就是外部调研。

有句话叫做，太阳底下没有新鲜事。我们要知道，当前我们所面临的问题，很可能不是独一份的。可能别的公司早已出现过并解决了。那么我们就可以站在巨人的肩上来寻找最有效最省力的办法。

磨刀不误砍柴功，多研究相似业务场景和问题背景下的业界做法，仔细分析其中的差异点，能够起到很好的方向指引和借鉴作用。

理想架构

在了解清楚业务现状和目标后，针对梳理好的反映现状的业务流图，可以改一版理想中的业务流图出来，对照来看，分析目前差距在哪里，是否能补齐等。

比如，在发票单据管理这个场景下，业界最优并且也是目前理想的做法是，对接订单系统拉取必要信息自动化生成单据，并执行每日自动化校验，对于不一致单据或有漏掉的单据缺失等情况做纠正或告警。而业务现状中的做法是人工拍照上传纸质单据再手动绑定订单。

需求分析

基于痛点和问题转化为需求，将提取出来的需求整理成清单，进行相应的分析，包括初步解决思路、需求价值、优先级等。

对于需求价值可以专门提出来说一说，可以用四象限法来辅助判定需求价值。X轴可设定为紧急程度，Y轴可设定为重要程度，业务层面亟待解决但也仅仅针对当下业务情境，而不具有长远可持续性的问题可以归类为紧急不重要需求；而对于当下问题未凸显不尖锐但随着业务规模高速增长，在可预见的未来会产生巨大价值和前瞻性红利的需求，依据时间窗口特性、实际资源及项目周期等情况，可归类为紧急且重要或重要不紧急需求。

解决方案分析

统合需求清单，站在整体解决方案的角度对需求进行合并同类项、依赖关系识别绑定、不可行需求剔除等处理，形成有限几个整体性解决方案(如A、B、C)，明确每一种解决方案的技术目标。

可行性结论

对每一种解决方案的技术目标和最终提供的功能与业务目标进行对标匹配，得出是否具有整体可行性的结论。

路径推荐

对于具备可行性的解决方案，再基于实现难度、项目周期、成本投入(人员及资金投入)和项目长短期收益(如解决当前业务痛点问题/完成初级智能算法能力建设等)，给出带有优先级和优劣势说明的路径(解决方案)推荐，目的在于陈清利弊，便于决策。

三、技术调研

要知道一个项目/业务可不可干，即是否在实现上具备可行性，则是要做好技术调研。技术调研的最终成果要能够回答两个问题：

这个项目在技术实现上是否可行？什么时候可行？
要落地该项目，并实现技术目标，需要多大投入？最小可行性版本如何？高含金量版本又如何？

要弄清楚以上两个问题，不同角色的人开展技术调研，方式和侧重点也会有所不同。

1. 产品经理做技术调研

产品经理做技术调研，目的主要在于通过了解在目前已较为成熟的技术领域是否有先行案例来判断技术上的可行性。通常包括研究业界实践案例和现成的商业化产品白皮书等方式开展工作。对于有外采意向的项目，产品经理要做的技术调研其实就更类似于选型分析了，不仅需要仔细研究意向商业化产品的功能、与需求的匹配度、用户上手难度等，还需与供应商沟通如报价、培训、定制化开发等事宜，从而完成综合评估。

2. 研发人员做技术调研

而研发人员去做技术调研，更多地是出于实现需求的目的，比如可能会去开源社区寻找可用/可改造的“轮子(单元性程序代码)”等。

四、碎片化信息整合

1. 过程性文档管理

不管是针对内部开展的问卷式、访谈(座谈)式调研，还是带着问题在外部阅读各种资料寻求经验与答案，都应该有过程性文档的沉淀。而这些过程性文档就可以视为碎片化信息，是非常重要的。但又不是都重要，这就需要我们对信息进行去伪存真，重点标注，前后联系等工作，将碎片化信息进一步消化后形成信息精华，用于最终的报告编写。

2. 有逻辑地重构串联

最后，必须要强调的是，项目可行性报告绝对不可以是碎片信息的拼凑堆砌，而应该是以符合认知习惯的、强逻辑性的方式组织串联并呈现出来，类似于上学时写的议论文，但又要结合金字塔原理，做到：结论先行，论点分明，论据充分合理。

五、结语

不管是项目可行性报告的撰写还是项目可行性调研工作的规划与开展，都是一门很深且很有意思的学问，值得我们职场打工人不断精进，在实干中钻研，钻研成果继续服务于实干，愿各位都能成为项目领域的逻辑专家，表达能手。

本文由 @maggieC 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。