编辑导语：项目汇报对于产品专家来说十分重要，那么做项目汇报有哪些好用的方法策略呢？本篇文章作者分析了有关项目汇报的内容，干货满满，一起来学习一下吧，希望对你有帮助。
不知道大家平时在工作的时候会不会去做一些项目汇报？
某些比较大的项目，特别是那些跨部门、对资源有一定要求的，大老板们往往会比较重视“第一印象”，所以项目的生（预）死（算）基本就指望第一次正式汇报了，当然，后面的几次汇报也不能马虎。
回顾学姐的职业生涯，也有那么几个大项目让我记忆犹新。
还记得有一个在订单上加几块服务费的项目，听上去虽然真的很简单，但是做起来却涉及到各个产品部门，比如搜索、订单、结算、优惠、客服等等，大厂的中台化都做得比较好，学姐所在的业务部门本身能研发的部分并没有这么多，更多的是要提需求给这些中台。
这些设计产品研发相关的倒还不算什么，毕竟学姐在这方面也是专业的，但这个项目还因为涉及到交易流程，还需要法务、财务去审批，而且还需要销售运营去通知销售，让商家去签署协议之类的。
总之，一个看起来很简单的项目，做起来还挺复杂的，好在当时我考虑得还挺全面的，每一次的汇报都还挺顺利的，上线之后并没有造成什么BUG或者客服投诉，整体的数据也还不错，
一、汇报大纲不同阶段的汇报肯定会有不同的侧重点，比如项目跑起来之后，肯定是汇报项目进展、试点的数据结果之类的比较重要，不过学姐这次就聚焦在比较重要的项目汇报——也就是第一次正式汇报了。
这篇文章会着重讲汇报大纲、格式和内容，还是比较实用的。
大家可以先看一下概览，整个汇报分为三个部分，第一部分是项目背景，第二部分是项目方案&所需资源，第三部分是预计项目进度。
这么汇报的好处是，先讲清楚为什么要做，包括项目价值和指标的提升，等于给老板画个饼，引TA上钩之后再去讲具体的方案，基于合理的方案去申请资（预）源（算），最后根据方案把整个项目的时间计划汇报清楚。
这样汇报整体的逻辑线会非常清晰，循序渐进，把想要的资源在合适的时间很顺溜地带出来，避免老板觉得你一上来啥都不说，就要钱要人。
这其实和谈恋爱也是同理嘛，总不能刚见面就求婚咯。
二、项目背景项目背景其实就是讲述为什么要做这个项目，在第一次正式汇报的时候，如果不是从上至下的项目，这部分是最重要的，甚至会比后面的具体方案更重要。
因为你需要先说服老板，让TA认可做这个项目的价值，才能讲到后面的方案。
我们一般会采用从大到小、从抽象到具体的方法去讲述，也就是先讲整个行业的大背景，再讲具体到项目的价值，最后预计一下这个项目能带来多少指标提升，这样既不会显得太空洞，又不会显得没有格局。
三、行业分析怎么去做行业调研，学姐在，感兴趣的可以先看下。
如果已经做完行业调研的童鞋就可以直接开始这部分了，因为是某个具体项目的汇报，这部分我们就可以稍微简化一些，用一两页PPT去描述整个行业的发展趋势和宏观环境就行了。
1. 发展趋势一般会看近5～10年的市场规模，查询的网站学姐在上一篇文章里面有介绍过，不了解的童鞋可以看一下。如果市场规模逐年增加，甚至复合增长率超过10%，那肯定是朝阳行业了，我们先告诉老板这个行业是有搞头的，增加TA的兴趣，下面是一个医疗行业的例子。
如果市场规模是逐年下降的，学姐觉得最好谨慎考虑下投入资源是否值得，或者也可以用下面提到的方法来判断一下整个行业是否有转机或者突破口。
2. 宏观环境行业的宏观环境我们也介绍过很多次啦，用PEST分析就行了，这个方法可以帮助你看到现有数据之外的东西，预测整个行业未来的趋势，总体来说就是四个方面去判断：
P，Political-政治环境。包括国际局势、国内/业内政策；E，Economic-经济环境。包括居民消费水平、产业结构；S，Social-社会环境。包括人口结构、风俗习惯；T，Technological-技术环境。包括硬件、载体、平台。从以上这四个方面可以去判断整个行业未来的发展，当然，既然是某个项目汇报，肯定是往有利于项目的方面去包装嘛，不一定要把PEST里面的每一个小点都写出来，着重强调一下和你项目有关的那些点就行了。
比如如果你做的是宠物行业，宠物食品相关的项目，就可以着重强调下E、S、T三个方面，比如城镇居民人均可支配收入提升，大家更愿意在宠物上花钱（经济），老龄化和出生人口不断降低，更多人选择宠物的陪伴（社会），新的社交媒体比如抖音、小红书等催生了一批宠物KOL，让大家云吸宠更方面了（技术）等等。
当然，除此这四个方面之外，其他利好你这个项目的信息，也可以都放上去。
3. 产品价值吹完大市场，就可以具体聊聊你的项目到底有什么价值了。
如果大老板是第一次听到这个项目，我建议先给项目起一个通俗易懂的名字，让别人一看就能理解的。
那些花里胡哨看都看不懂的黑话可以让老板这个层面的人去考虑，我们汇报的时候先要把TA争取到我们这一边才行，所以第一要务是要让大老板理解你这个项目到底是干啥的。
有了合适的名字之后，再用几句话简单描述下项目的概况，这里不需要涉及到太具体的方案，避免过早就陷入一些细节。
然后，我们就可以开始讲项目价值了，学姐之前也教过两种描述项目价值的方法，之前学姐也介绍过，一种是负向表述，一种是正向表述。
第一种就是欲扬先抑型的，先说一下用户的痛点以及论据和解决方案；第二种就是直接描述项目到底帮助了用户哪方面，以及论据和解决方案。以下是两个小例子：
【负向表述】如果你想做一个新功能，比如发视频支持存草稿，可以这样去描述价值：目前发视频的失败率为40%，调研后发现这些用户有一半以上是因为被打断而没有继续编辑（论据），因此我们通过草稿箱（解决方案）来节省用户重新编辑视频的重复工作（用户痛点）。【正向表述】如果你想做一个新功能，比如列表页新增一个广告位，可以这样去描述价值：调研显示50%的客户有在平台投放广告的需求（论据），为了帮助这些客户获取更多目标用户（帮助用户），我们会通过算法匹配在合适的列表页展示广告位（解决方案）。当然，这里的论据肯定是多多益善的，有数字的一定要放数字，且多放数字肯定比少放数字好。
4. 预计提升指标项目价值要结合具体的数字，看起来才会更诱人，大老板一看这个项目能给公司带来利益，多少都会有那么点心动的～
怎么选择指标，学姐也在这篇文章中有介绍过，原则有这几个：
确保选择的指标和这个项目的价值能匹配上；排除其他因素的干扰；选择合适的benchmark来对比。选完指标之后可以开始预估指标的提升，学姐在数据分析宝典里面也有详细介绍，感兴趣的可以看下，有三个方法：
看行业标准，比如参考行业报告或者竞品的数据；类比，比如参考其他部门、类似的行业或者类似页面的数据；调研分析，通过抽样和分析对上面两个数据进行微调。不管用什么方法去预估，尽量可以把你的推导过程描述一下，增加一些可信度，避免大老板觉得你是随便拍脑袋得出的，当然大老板可以拍脑袋，然鹅你还没有到可以拍脑袋的地步。
四、项目方案&所需资源到了这一部分，很多童鞋可能觉得自己非常得心应手了。特别是项目方案，直接啪啪地把设计稿贴上去就行了！
这么做对于某些公司、老板或者项目来说，确实行得通，但并不是万能的，学姐在这里还是教给大家一个更完整的汇报框架，除了让汇报更顺利，也能利于大家更全面地去思考整个项目，而不仅仅是停留在产品层面。
1. 产品这部分在汇报的时候大家要注意从整体到局部去汇报，先讲整个产品的功能架构，再去讲具体的交互（或者线框图）和视觉设计，这样才可以让老板先对整个产品有一个直观的感受，再去看具体的某一些重点功能的设计。
1）产品概览
学姐在之前竞品分析的文章里面也介绍过产品架构图，有两种比较好的表达形式。
第一种是树形结构的产品架构图，大家把产品的大模块，每个模块下的功能点，每个功能点里的细节层层展开就行了，比如下面是一个微信公众号后台的例子，公众号后台的内容部分，分为创作，发送和素材库三大模块，创作下面又有不同类型的内容和存草稿的功能等等。
第二种是系统架构图：
图片摘自ProcessOn
系统架构图更强调不同系统之间的关系，如果大家设计的是多系统之间有交互的产品，不同系统可能属于不同的部门或者供应商，那么可以用后者，否则的话用产品架构图就够了。
当然，如果你这次设计的产品不太复杂，或功能点还没想得很全，就用一个表格去把功能列表写出来也是可以的。
2）功能点介绍
汇报的时候我们当然不会把所有的功能点都过一遍，特别是第一次汇报，挑重点功能就行了。
可以采用功能流程图结合设计稿的形式去汇报，线框图当然也可以（但是不好看）。
在项目初期，产品方案还没有完全确定的情况下，设计的童鞋往往还没有完全介入到这个项目，不一定能帮把完整的交互稿和视觉稿都完整的输出，我们可以挑一些重点页面让设计童鞋输出，作为demo就可以，这样可以避免方案在汇报过后要调整，浪费设计童鞋的精力（不用请奶茶也能和设计童鞋搞好关系的小技巧get）。
当然，如果此时产品方案已经非常确定了，也可以直接把重点功能的流程图或者设计稿直接挑一些重点贴在ppt里面。
学姐之前在教PRD的文章里面有讲过，如果是这个功能是比较重后端逻辑的，可以主要放流程图；如果是比较重前端页面的，可以主要贴设计稿。
另外，大家也别忘了汇报之前最好把方案给研发的leader看一下，避免汇报了之后才发现可行性存在问题。
2. 其他资源很多童鞋汇报完产品方案之后，就觉得整个方案汇报完了，但其实一个大项目，仅考虑产品这部分是远远不够的。我们应该更进一步，思考以下几部分：
是否需要配套的运营方案和运营人员；是否需要调整客服系统，配备客服人员；是否涉及到销售售卖和提成；是否涉及到财务流程；是否涉及到法务审批；新产品上线后，是否需要营销或者推广。大家挑你们项目里面比较需要资源的部分去汇报一些大致方案，具体格式就不一一介绍了，主要目的是为了让老板清晰地知晓这个项目还需要哪些产品研发之外的资源。
五、预计项目进度汇报完项目背景和方案之后，如果老板对你画的饼有兴趣，那么接下来TA可能就会期望这个项目立马上线了！
但是，我们也要打消TA完全不切实际的想法！汇报一下我们觉得项目的预计上线时间点了，当然如果直接讲，会很容易被挑战，为什么不能项目不能提前上线？
所以，在这一部分我们需要讲清楚三个“点”，第一是时间点，第二个是风险点，第三是检查点。
1. 时间点虽说是时间点，实际上我们并不能只去汇报上线时间这一个点，更好的表达方式是“时间线”或者“时间表”。时间线适用于比较还没有把项目的进度拆很细的童鞋，比较适合在前期汇报一个“大致”的时间，里面的时间是“X月X旬”这种形式。
如果你的项目进度已经比较明确了，那么就可以用时间表的形式，把项目拆得更详细一点，时间表上的单位，一般精确到“周”。
2. 风险点不管用时间线还是时间表的形式，都是我们预估的项目进度，在实际操作中，经常会出现一些风险点，导致项目Delay。
作为一个合格的产品经理，我们要事先就把这些风险点。可以先自己尝试解决，如果解决不了，就可以去要求老板协助解决，不管哪种解决方式，我们都要在前期就给老板“提个醒”，把风险点充分暴露出来，避免等到下次汇报的时候发现进展缓慢。
学姐个人总结下来，风险点一般有这么几种：
设计的工作量大，比如可能涉及到新的设计规范等，而设计的资源又比较饱和；项目依赖其他部门配合开发，比如需要提需求给其他部门，平台、中台、客服等等；项目需要多工种之间配合，比如运营、销售、市场、BI等；项目需要法务、财务等部门进行审批；项目需要和其他供应商的系统进行对接；项目的某些方面依赖第三方/其他公司。童鞋们可以自行检查下你们的项目是否有这种情况，有的话一定要及时标注，并写清楚风险的解决方案，如果没有很好的解决方案，也可以让老板协助解决。
3. 检查点一个比较大的项目，如果涉及的工种、部门，甚至公司比较多，往往需要设计一些合理的检查点，给大家聚在一起充分地沟通，暴露并解决问题。所以很多大厂会采用“项目（双）周会”的形式，周会就是一个检查点，让大家在每周留出固定的时间来参加会议，避免每次开会人都召不齐。
当然，在汇报的时候这部分带一嘴就行了，更重要的是要给老板一个下次预计汇报的时间，让老板检查项目的进度。在下个检查点，我们除了汇报项目最新的时间表，还要汇报一些具体的进展，比如：
我们可以在产品的设计稿输出（并向相关部门确认过之后）之后，进行一次汇报；在运营方案确定了之后，让运营童鞋，进行一次汇报；在产品上线或者有一部分试点数据之后，进行一次汇报；有了完整的数据，汇报一次项目整体复盘。如果你们给老板汇报是以月会、双月会这种固定时间的形式，那么在开会之前如果你的项目有了以上进展，也可以整理到月报中。
#专栏作家#海贝学姐，公众号：海贝学姐，人人都是产品经理专栏作家。十年大厂产品经验，精通产品方法论和产品知识。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。