大厂产品专家是怎么做项目的（附流程）？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

要把想法变成切实的产品总是很难的，这篇文章讨论了项目推进总是不顺利的两个原因，将项目分为五大阶段和各个小环节，帮助大家优化做项目的流程，不妨来看看。

全文共 6527 字，阅读需要 13 分钟

——————/ BEGIN /——————

相信很多来做产品经理的童鞋都是怀揣着满腔的想法，结果进公司后发现，扯皮、推锅的事儿很多，推进大项目并不是这么简单。

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

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

1. 流程问题

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

这就让学姐想到了前几天看到的一个视频，还挺有意思的：

讲的是重庆有俩大型商场要赶在圣诞节前开业，一个外国大叔实地探访开业前的36小时。

只见商场里几乎空无一物，建材堆的到处都是，看上去就像一个工地，甚至要带安全帽。

圣诞节当天，这俩商场就奇迹般地正常营业了，客流量还挺大，没有任何一个环节掉链子，视频的结尾大叔开始感慨“中国速度” ↓

学姐看完视频后觉得，这不就是咱上线一个产品的真实过程吗？——上线前还有长长的bug list，视觉还原问题至少十几个，老板们还在那儿各种提意见～

一阵手忙脚乱后，项目竟然准时上线了，甚至没有任何bug和客户投诉。

要做到这种“中国互联网速度”，还是要归功于学姐这么多年梳理出来的流程。

就像这个视频里外国大叔说得一样，虽然整个工地看上去杂乱无章，但其实每个人都各司其职，他称其为“organized chaos”。

在推进项目的时候，到底要怎么做到这种“有组织地混乱”呢？学姐会在后文详细介绍，先让童鞋们感受一下整个流程，一共分为五大阶段，阶段里还有不少环节↓

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

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

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

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

举个例子：

曾经有一个研发leader（很棒的小姐姐）在我转岗的时候拉着我说“我们这个业务自从你来了之后，就搞得风生水起嘛”，弄得我都有点不好意思了。

这之后过了两年，她也转岗了，我负责的新业务正好要给她提需求，那推进可就太丝滑了～

其实，这个业务的业绩真有这么好吗（毕竟我都要转岗了）？之前负责这个业务的产品难道就不给力了吗？为什么研发小姐姐就这么愿意做我的需求呢？

这就是建立人设、提升信任度的功劳了。

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

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

需求调研阶段

1. 目的

需求的来源是多种多样的，可以来自于数据分析、用户调研、客户调研、竞品分析等等，可能是某个老板或者同事提出的，也可能是你哪天洗澡的时候就灵光乍现了（之前某大佬和我说TA在洗澡的时候会琢磨业务）。

但从idea到项目真的启动，还需要进一步调研。

有些童鞋可能把“找需求”和“做需求”的调研混为一谈，但其实两者是不一样的：前者主要是为了发现问题，后者主要是去调研怎么解决这个问题，对于一个比较大型的项目来说，后者肯定是不能省略的。

2. 方式

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

至少要调研哪种用户（who）、在什么场景下（where）、为什么原因（why）产生这个需求，越细越好。

比如who就要具体到这类用户的画像等等（性别、年龄、收入、爱好、恩格尔……）。有点类似于大家喜欢玩的“沉浸式剧本杀”，有人物的背景，也有布景搭建，甚至可以找到这个人物做每一件事儿的动机。

只有这样，在需求设计阶段（第三阶段），我们才能找到“代入感”，在两个方案中纠结的时候作出更好的判断，也方便我们对每个功能排优先级。

3. 参与人员

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

将心比心，如果有一个人天天动动嘴就让你帮他干活，你是不是会有点不乐意？

所以，我们最好不要直接拿着已经敲定的需求去通知大家干活，能尽量提升大家的参与感是最好的，既方便以后拉他们一起“上船”做项目，也可以打造靠谱的产品人设。

4. 产出

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

项目启动阶段

调研完，是不是可以开始写需求文档了？

当然不是啦，咱是做大项目的，要有个正式启动的阶段。

环节1：组内 Kick off

项目启动肯定要先让内部的同事（特别是老板）和你想法一致吧，别到时候开kick off会的时候被老板怼，这就很难看了，也会让其他部门的人对你的信任度大打折扣。

这部分就不赘述了，大家根据自己平时的习惯的方式来就好。

环节2：Kick off会

自己老板这过关了之后，就可以开Kick off会了。

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

1）目的

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

2）方式

怎么样保证以上两点？

① 阐述背景、价值、指标

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

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

② 明确项目时间点

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

③ 设置讨论环节

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

如果会上讨论不清楚，也可以会后给同事们一俩周时间提建议（言下之意，过期不侯～）。

3）参与人员

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

4）输出

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

项目设计阶段

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

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

环节1：提设计需求

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

1）目的

让设计充分了解需求。

2）方式

设计需求我们一般用文档的形式去提，并附上之前的Kick off的ppt。

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

3）参与人员

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

4）输出

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

环节2：设计评审

1）目的

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

2）方式

设计评审也会分成两种情况：

一些交互比较重的需求，可以先拉上大家一起过交互稿，交互确定了之后再进行视觉设计；

如果是轻交互重视觉的项目，可以在群里发下交互稿，如果大家问题不大那么可以等到有视觉稿了再开会评审；如果你觉得拿不准，可以和设计讨论之后再决定在哪一步拉会过稿子。

3）参与人员

原则是先和内部的人过，先叫上自己的老板、设计师老板、同部门的产品、运营，再去找外部的人过，比如客服、法务、其他部门的产品等（当然这个环节暂时不会叫到研发）。

同理，这也是避免在外人面前窝里反，造成人设崩塌。

当然，在你们根据外部同事的建议修改了稿子之后，也别忘了及时知会到内部人员。

环节3：细化需求文档

设计稿确定之后，需求文档就可以写得比较详细了，这部分学姐之前有专门的文章介绍，不赘述了。

环节0：技术调研

1）目的

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

所以，这个环节的目的主要是确保可行性没有大的问题。

2）方式

技术调研一定要穿插在设计阶段进行。

但设计评审的时候又不方便叫上研发，毕竟那时候设计还没定稿，如果让研发参与，他们可能会对设计稿提出一些很“研发”的要求（也就是偷懒）。

解决方法也很简单：找到研发的负责人看一下稿子的可行性，如果他没空，就让他给这个项目指定一个前端、一个后端，有稿子了之后私他们一下康康～

3）输出

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

项目开发阶段

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

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

1）方式&参与人员

需求评审会大家应该都很熟了，做任何需求都要经历这一步，拿着文档、叫上研发、设计师、测试一起。

同理，也是先找内部的研发（自己部门的）看，再问他们需要拉上哪些外部的研发再开一次评审会。

2）产出

首先，是研发对需求的修改建议和你对这些建议的next step，比如何时进一步调研、优化方案等，形式不限，可以在写在文档里，也可以用会议纪要的形式。

写完并不是就这么算了，一定要及时给研发们反馈，这样才能让别人感受到你对这个项目是很上心的，也是进一步打造靠谱的人设～

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

环节3：技术评审

本环节一般不需要产品参与，大家了解一下即可。

主要是技术讨论这个方案怎么实现，需要多久，会上会讨论出一些对需求的修改建议和工作量的评估，然后进行排期。

环节4：测试评审

本环节一般不需要产品参与，大家了解一下即可。

主要是测试人员根据技术实现方案输出测试用例、工作量，并进行排期，一般会后测试会把用例共享给产品看一下，确认是否覆盖全。

环节0：方案优化

调整方案是避免不了的，一定会穿插在整个需求开发阶段，大家就不要梦想着一次定稿了。

调整方案之后一定要知会相干人员，如果是比较小的调整可以在群里沟通，大调整最好再发上一封邮件。

另外，学姐在介绍需求文档的时候也提到过，需求的变更最好要在文档上留下详细的记录。

需求上线阶段

环节1：测试/配置

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

环节2：产品&设计验收

1）目的

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

2）方式

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

① 产品测试

有些童鞋可能会觉得“公司不给测试发工资的吗，为啥还要产品再测一遍？”

其实最了解这个项目的还是产品本人，毕竟需求是你写的，测试人员在理解需求的时候不一定能完全get你的想法，也可能会有一些在文档上并没有提到的细节。

所以任何项目，产品一定要测一遍主流程，这也是打造靠谱人设的一个环节。

② 视觉还原

视觉还原也很重要，一定要叫上相关的设计童鞋一起验收。

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

③ 打点验收

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

3）输出

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

环节3：其他同事验收

1）目的

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

2）方式

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

3）参与人员

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

4）输出

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

环节4：上线

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

1）方式

我们可以根据项目的影响面来评估是否要先灰度上线。

之前在大厂的时候，涉及到核心页面的调整会切一小部分流量灰度发布（比如3%、5%），确认没有用户投诉和技术指标的异常之后再切全量，避免造成太大的损失，小心使得万年船嘛。

2）参与人员

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

（3）输出

上线邮件。

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

上线后阶段

环节1：数据监控

1）目的

在项目上线之后2-3天，一定要看一下数据。

一是确保项目没有明显的技术问题（如果有的话，数据会出现很大的波动），二是如果你对自己的项目数据漠不关心的话，其他同事就会觉得你不够负责。

2）参与人员

产品、BI等。

3）输出

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

环节2：项目复盘

有了数据分析之后，我们要开一个项目的复盘会，咱可不能让别的同事觉得，利用完他们就抛弃他们了吖～一定要有始有终。

如果数据好的话，也可以考虑写邮件发一封喜报，感谢一下大家，这样下次他们再接你的需求，才能更有劲儿。

所以学姐之前在大厂的时候，也会定期把一些需求（不管是大项目还是小优化）的结果，通过分享会的形式告知大家；让大家在嗑瓜子、喝奶茶之余，可以对项目再提提建议，那项目的2期不就顺理成章了吗？

总之，做项目还是挺考验产品经理的硬实力和软实力的，硬实力就是你对项目流程的把控，软实力就是打造靠谱的人设。

前者跟着流程来就行，后者要求你在整个流程的中尽量体现自己的积极性和严谨度，另外就是将心比心，更公开透明地去和同事们沟通。

学姐相信这样做项目，冰山都会被感动滴（谈恋爱同理）～

—————— / END / ——————

产品经理培训｜产品运营培训｜企业内训服务

请在公众号后台回复「培训」了解更多

▼ 喜欢请分享&收藏，满意点个赞，最后点「在看」 ▼