大厂产品专家是怎么做项目的？

前段时间看到一个童鞋在后台留言，一个idea要怎么样才能变成线上的产品？学姐回想了下，在自己初入行的那会儿，确实会面临“idea多，结果少”的情况。相信很多来做产品经理的童鞋都是怀揣着满腔的想法，结果进公司后发现，扯皮、推锅的事儿很多，推进大项目并不是这么简单。

为啥项目推进总是不顺利？

撇开项目本身价值有问题的情况不讨论，无非是这两个原因：

1. 流程问题

做大项目的流程，平时做普通需求的流程显然不一样，很多童鞋对这部分并不熟悉，或者说熟悉但不精通。

这就让学姐想到了前几天看到的一个视频，还挺有意思的，讲的是重庆有俩大型商场要赶在圣诞节前开业，一个外国大叔实地探访开业前的36小时。只见商场里几乎空无一物，建材堆的到处都是，看上去就像一个工地，甚至要带安全帽。圣诞节当天，这俩商场就奇迹般地正常营业了，客流量还挺大，没有任何一个环节掉链子，视频的结尾大叔开始感慨“中国速度” ↓

学姐看完视频后觉得，这不就是咱上线一个产品的真实过程吗？上线前还有长长的buglist，视觉还原问题至少十几个，老板们还在那儿各种提意见～一阵手忙脚乱后，项目竟然准时上线了，甚至没有任何bug和客户投诉。要做到这种“中国互联网速度”，还是要归功于学姐这么多年梳理出来的流程，就像这个视频里外国大叔说得一样，虽然整个工地看上去杂乱无章，但其实每个人都各司其职，他称其为“orginized chaos”，在推进项目的时候，到底要怎么做到这种“有组织地混乱”呢？学姐会在后文详细介绍，先让童鞋们感受一下整个流程，一共分为五大阶段，阶段里还有不少环节↓

学姐会着重介绍每个流程的目的、方式、参与人员和产出。

2. “人设”问题，同事们对你的信任度不高

不知道童鞋们有没有遇到过这种情况，身边有些同事做项目总是顺风顺水的，然鹅一到你的项目，总有人来“找茬”，这其实就是同事们对你信任度还不够高的表现。

学姐本人曾经被一个老板形容为“非常搞得定研发”，每次转岗，都会有研发表达惋惜；即使是我现在辞职在家休息了，还经常有研发问我要不要回流。

举个例子，曾经有一个研发leader（很棒的小姐姐）在我转岗的时候拉着我说“我们这个业务自从你来了之后，就搞得风生水起嘛”，弄得我都有点不好意思了，这之后过了两年，她也转岗了，我负责的新业务正好要给她提需求，那推进可就太丝滑了～其实，这个业务的业绩真有这么好吗（毕竟我都要转岗了）？之前负责这个业务的产品难道就不给力了吗？为什么研发小姐姐就这么愿意做我的需求呢？

这就是建立人设、提升信任度的功劳了。虽然大家平时做项目的流程看上去都差不多，但在这个过程中，还是有很多细节可以帮助你“打造人设”，成为大家心中靠谱的产品经理。

所以，学姐今天这篇文章会“软硬结合”，在帮助童鞋们优化做项目的流程，也会告诉大家该怎么打造人设，让同事们爱上（？）做你的需求。

01

需求调研阶段

目的

需求的来源是多种多样的，可以来自于数据分析、用户调研、客户调研、竞品分析等等，可能是某个老板或者同事提出的，也可能是你哪天洗澡的时候就灵光乍现了（之前某大佬和我说TA在洗澡的时候会琢磨业务）。但从idea到项目真的启动，还需要进一步调研。有些童鞋可能把“找需求”和“做需求”的调研混为一谈，但其实两者是不一样的，前者主要是为了发现问题，后者主要是去调研怎么解决这个问题，对于一个比较大型的项目来说，后者肯定是不能省略的。

方式

调研的形式不限，和“找需求”类似，可以是问卷、访谈，也可以是数据分析、竞品调研，只是会更针对你想解决的问题。

至少要调研哪种用户（who）、在什么场景下（where）、为什么原因（why）产生这个需求，越细越好，比如who就要具体到这类用户的画像等等（性别、年龄、收入、爱好、恩格尔……）。有点类似于大家喜欢玩的“沉浸式剧本杀”，有人物的背景，也有布景搭建，甚至可以找到这个人物做每一件事儿的动机。只有这样，在需求设计阶段（第三阶段），我们才能找到“代入感”，在两个方案中纠结的时候作出更好的判断，也方便我们对每个功能排优先级。

参与人员

学姐觉得吧，如果是比较大的项目，邀请对业务感兴趣或者比较有想法的运营、设计、研发甚至销售，一定程度参与前期的调研，会大幅提升他们后续参与项目的积极性，也方便后续和他们在这个需求上的想法和你一致。如果他们比较忙的话，你也可以只是把问卷或者数据分析的结果分享给他们。

将心比心，如果有一个人天天动动嘴就让你帮他干活，你是不是会有点不乐意？所以，我们最好不要直接拿着已经敲定的需求去通知大家干活，能尽量提升大家的参与感是最好的，既方便以后拉他们一起“上船”做项目，也可以打造靠谱的产品人设。

产出

下阶段Kick off的ppt或者文档，演讲形式的ppt最佳，必须包含需求的背景和价值、指标提升、功能的优先级、项目上线的大致时间点，最好可以附上调研过程。

02

项目启动阶段

调研完，是不是可以开始写需求文档了？当然不是啦，咱是做大项目的，要有个正式启动的阶段。

环节1：组内 Kick off

项目启动肯定要先让内部的同事（特别是老板）和你想法一致吧，别到时候开kick off会的时候被老板怼，这就很难看了，也会让其他部门的人对你的信任度大打折扣。这部分学姐就不赘述了，大家根据自己平时的习惯的方式来就好。

环节2：Kick off会

自己老板这过关了之后，就可以开Kick off会了，Kick off就是足球比赛中开球的意思（学姐刚百度的），现在引申为项目启动的意思。做大项目可不能偷偷摸摸的，要有仪式感，这就得有一个正大光明的启动会～

目的

这个会的目的说白了也很简单，就是把大家都“拉上（你的贼）船”。首先是要保证相干人员都认可你这个项目的价值愿意为这个项目出力，其次是要保证大家在沟通项目的时候都在一个频道上，能更快达成共识。

方式

怎么样保证以上两点？

1. 阐述背景、价值、指标

学姐在上一部分也说到了，调研后产出的ppt一定要包含需求的背景和价值，如果同事们对这些东西都无感的话，就把对预计能对指标的提升写出来。

如果这些实际的东西都还不能打动同事，那咱就只能用态度去感化他们了～拿出第一阶段辛辛苦苦做的用户调研或者数据分析给他们讲解一遍，让他们感受到你是在很认真地做项目，并不是动动嘴皮子就想指挥他们干活，这也能打造是靠谱人设。

2.  明确项目时间点

我们需要把自己对这个项目中不同功能的优先级列出来，并把对项目上线时间点的大致预期和原因写清楚，保证大家对这个时间点都有印象，给大家一些些紧迫感～别让别人觉得你这个项目完全不急。

3．设置讨论环节

最后，我们还要给大家充分的时间讨论，认真的记录下他们的提问和建议，这样的好处是可以让你考虑地更全面，也可以避免项目做到一半某个同事突然跳出来发表修改意见。如果会上讨论不清楚，也可以会后给同事们一俩周时间提建议（言下之意，过期不侯～）。

参与人员

学姐建议把能想到的所有可能相干的同事都邀请进来，不同部门（业务、平台、中台等）、不同工种（运营、研发、设计、法务、财务、客服……）一定要保证都邀请到，并且尽量保证每个部门和工种都至少要派一个代表过来。

输出

输出的形式是会议纪要，必须包含时间、参与人员、大家提出的问题和你的next step（包括时间点），附件里要有Kick off的PPT↓

03

项目设计阶段

调研、启动阶段之后，我们可以启动设计了，如果时间比较赶的话，在启动阶段的同时就进行设计也可以，但是这样设计容易返工，因为启动会上可能还是会有不少同事提出建议的。

这个阶段的有4个环节，1是提设计需求，2是设计评审，3是细化需求文档，当中会穿插技术调研。

环节1：提设计需求

相信在经过第一阶段和第二阶段后，设计师或者设计师的leader已经对这个项目有了不少了解（被你拉上贼船了），这时候再提需求就比较稳了，做起来肯定会比他们接的那些个临时提的需求要更有积极性嘛～

目的

让设计充分了解需求

方式

设计需求我们一般用文档的形式去提，并附上之前的Kick off的ppt。文档会比Kick off的ppt更落实一些，首先要有一个表格写上这个需求的基本情况，比如平台、用户群、使用场景、功能列表、优先级、是否需要视觉等，其次是功能的框架图、流程图和线框图（如果你有的话），最后是一些相关竞品的页面截图↓

参与人员

一般是先把设计需求提给交互，等交互定稿了再由交互把需求提给视觉。不过如果有一些视觉设计比较重的项目，举个例子，可能会用到新组件或者新的视觉规范的项目，也可以在提交互需求的时候就把视觉拉上一起参与讨论，避免后期视觉让交互返工。

输出

如果是较大的项目，至少准备2套不同方向的交互稿/视觉稿。

环节2：设计评审

目的

让老板和其他相干同事认可设计方案。

方式

设计评审也会分成两种情况：一些交互比较重的需求，可以先拉上大家一起过交互稿，交互确定了之后再进行视觉设计；如果是轻交互重视觉的项目，可以在群里发下交互稿，如果大家问题不大那么可以等到有视觉稿了再开会评审。如果你觉得拿不准，可以和设计讨论之后再决定在哪一步拉会过稿子。

参与人员

原则是先和内部的人过，先叫上自己的老板、设计师老板、同部门的产品、运营，再去找外部的人过，比如客服、法务、其他部门的产品等（当然这个环节暂时不会叫到研发）。同理，这也是避免在外人面前窝里反，造成人设崩塌。当然，在你们根据外部同事的建议修改了稿子之后，也别忘了及时知会到内部人员。

环节3: 细化需求文档

设计稿确定之后，需求文档就可以写得比较详细了。

环节0：技术调研

目的

很多童鞋可能前3个环节都做得挺好了，甚至哼哧哼哧写了几十页需求文档，但是到了下个阶段——也就是需求评审之后，发现研发提了一些可行性的问题，导致设计稿全部推翻重来，一夜回到解放前。所以，这个环节的目的主要是确保可行性没有大的问题。

方式

技术调研一定要穿插在设计阶段进行。但设计评审的时候又不方便叫上研发，毕竟那时候设计还没定稿，如果让研发参与，他们可能会对设计稿提出一些很“研发”的要求（也就是偷懒）。解决方法也很简单，找到研发的负责人看一下稿子的可行性，如果他没空，就让他给这个项目指定一个前端、一个后端，有稿子了之后私他们一下康康～

输出

能得到研发小哥哥/小姐姐的一个微笑肯定就行了（这样咱就当是能做的）。

04

项目开发阶段

终于终于，项目可以正式开搞了～

环节1&环节2：内部需求评审会&外部需求评审会

方式&参与人员

需求评审会大家应该都很熟了，做任何需求都要经历这一步，拿着文档、叫上研发、设计师、测试一起。同理，也是先找内部的研发（自己部门的）看，再问他们需要拉上哪些外部的研发再开一次评审会。

产出

首先，是研发对需求的修改建议和你对这些建议的next step，比如何时进一步调研、优化方案等，形式不限，可以在写在文档里，也可以用会议纪要的形式。写完并不是就这么算了，一定要及时给研发们反馈，这样才能让别人感受到你对这个项目是很上心的，也是进一步打造靠谱的人设～

其次，要明确大概在什么时间点会进行技术评审和测试评审，毕竟那时候才能知道项目的工作量和排期，还有我们最关心的上线时间点。

环节3:技术评审

本环节一般不需要产品参与，大家了解一下即可。主要是技术讨论这个方案怎么实现，需要多久，会上会讨论出一些对需求的修改建议和工作量的评估，然后进行排期。

环节4:测试评审

本环节一般不需要产品参与，大家了解一下即可。主要是测试人员根据技术实现方案输出测试用例、工作量，并进行排期，一般会后测试会把用例共享给产品看一下，确认是否覆盖全。

环节0：方案优化

调整方案是避免不了的，一定会穿插在整个需求开发阶段，大家就不要梦想着一次定稿了。调整方案之后一定要知会相干人员，如果是比较小的调整可以在群里沟通，大调整最好再发上一封邮件。另外，学姐在介绍需求文档的时候也提到过，需求的变更最好要在文档上留下详细的记录。

05

需求上线阶段

环节1：测试/配置

本环节主要是测试人员进行的，包括后续的压力测试/渗透测试等等，学姐就不一一介绍了。另外，项目如果涉及到需要运营配置的，也要提前通知运营，切忌临时抱佛脚。

环节2：产品&设计验收

目的

确保产品没有bug，优化体验

方式

一般在测试让研发把P0、P1的bug修完之后，产品就可以参与一起测试和视觉还原了。

1. 产品测试

有些童鞋可能会觉得“公司不给测试发工资的吗，为啥还要产品再测一遍？”其实最了解这个项目的还是产品本人，毕竟需求是你写的，测试人员在理解需求的时候不一定能完全get你的想法，也可能会有一些在文档上并没有提到的细节。所以任何项目，产品一定要测一遍主流程，这也是打造靠谱人设的一个环节。

2. 视觉还原

视觉还原也很重要，一定要叫上相关的设计童鞋一起验收，学姐多年的经验，再优秀的研发，眼神也可能会飘，做出来的东西他们自己觉得和稿子一摸一样，可在学姐眼里那就是毫不相关了～设计师最讨厌的就是上线的产品和自己的稿子不一样了，这会很败他们对你的印象的。

3. 打点验收

打点也是比较容易遗漏的地方，测试和研发一般都会更顾及整个产品的流程是否能走通，对数据采集不会这么敏感，所以产品要验证一下打点是否正确。毕竟一个项目上线之后数据有遗漏或者数据有错，那最终倒霉的还是产品。

输出

Bug list或者视觉修复list，最好包含截图和优先级，方便研发和测试进行追踪。

环节3：其他同事验收

目的

这部分的官方目的和环节2类似，但真实目的其实还是让这些同事们高抬贵手，不要等项目上线了再来给你提意见，那时候就真来不及了。

方式

IM、邮件通知大家自行验收或者开会集中验收，在基本没有bug和视觉还原问题的时候再进行，避免同事们觉得你这个项目的体验太垃圾。

参与人员

这部分一定要带上所有项目相关方，也就是kick off的那些人。

输出

Bug list或者视觉修复list，最好包含截图和优先级，方便研发和测试进行追踪。

环节4：上线

激动人心的时候到了，咱的项目终于可以上线了。

方式

我们可以根据项目的影响面来评估是否要先灰度上线，学姐之前在大厂的时候，涉及到核心页面的调整会切一小部分流量灰度发布（比如3%、5%），确认没有用户投诉和技术指标的异常之后再切全量，避免造成太大的损失，小心使得万年船嘛。

参与人员

产品、测试、研发、运维等

输出

上线邮件。一般会再简单介绍一下需求背景，附上设计方案、感谢名单，感谢下对项目有贡献的人，这部分也是可以拉到一些些好感度的，毕竟谁不希望自己的工作被认可嘛～

06

上线后阶段

环节1：数据监控

目的

在项目上线之后2-3天，一定要看一下数据。一是确保项目没有明显的技术问题（如果有的话，数据会出现很大的波动），二是如果你对自己的项目数据漠不关心的话，其他同事就会觉得你不够负责。

参与人员

产品，BI等

输出

在项目上线两周～一个月（只要能累积到足够多的数据），大家就可以输出数据分析报告啦。

环节2：项目复盘

有了数据分析之后，我们要开一个项目的复盘会，咱可不能让别的同事觉得，利用完他们就抛弃他们了吖～一定要有始有终。如果数据好的话，也可以考虑写邮件发一封喜报，感谢一下大家，这样下次他们再接你的需求，才能更有劲儿。所以学姐之前在大厂的时候，也会定期把一些需求（不管是大项目还是小优化）的结果，通过分享会的形式告知大家，让大家在嗑瓜子、喝奶茶之余，可以对项目再提提建议，那项目的2期不就顺理成章了吗。

当然，项目复盘展开写又是一篇文章，哪天有空学姐再起一篇咯。 

总之，做项目还是挺考验产品经理的硬实力和软实力的，硬实力就是你对项目流程的把控，软实力就是打造靠谱的人设。前者跟着流程来就行，后者要求你在整个流程的中尽量体现自己的积极性和严谨度，另外就是将心比心，更公开透明地去和同事们沟通，学姐相信这样做项目，冰山都会被感动滴（谈恋爱同理）～

↘好文推荐：

所有人问「贴吧之父」俞军

产品经理的思考利器——UML
新晋管理者容易犯的3种管理错误

👇欢迎关注：

点个“在看”