大部分新人刚走上产品岗的日常工作是熟悉业务、收集需求、竞品分析、后期跟进等工作，时间长了，怀抱一腔热血的产品新人会觉得所做的事情并不是产品工作。他们渴望画原型、写PRD、带领团队进行需求评审、项目上线、然后改变世界。

其实对于每一个产品新人来说，最渴望的事就是自己独立负责项目。这不仅是公司整体项目向前推动的一小步，也是个人产品生涯的一大步。但第一次独立负责项目也会遇到很多问题，任何一个细节没有关注到，都会容易使项目发生意外。

那产品新人应该怎么做才能最大程度的hold住整个项目呢?

今天就跟大家分享一下我的复盘感想。

首先看一张项目的流程图，这个流程基本上就是一个完整的项目流程。在前期，产品的工作量是比较大的，所以产品人员需要多花时间去进行需求分析和方案确定。

1、收集需求

PRD不仅只有原型和批注，还会需要项目说明、需求分析、竞品分析、功能框架、功能清单等项目相关的东西，这些可以让项目相关人员更了解项目的背景和相关的业务。

所以在接到任务或需求后，产品首先要做的是针对该项目进行用户、需求、背景、目的等方面的分析。先要了解该项目是给谁用，用户目前面临的问题是什么，做出来后作用是什么，满足了用户什么需求。向任务安排者了解了这些后，就可以开始进行用户调研了。

当然作为新人，手头上没有什么用户，但是可以先找到了解用户、业务的人。公司的老员工对业务也会很熟悉，那么这个时候就需要尽可能地去和同事沟通。

首先向身边经验丰富的产品经理了解过往的业务情况和目前产品的不足，再去找业务或者销售去了解客户对该模块的需求。最后找到现有同事手上有的用户资源，这个时候，大家都会很乐意把用户都推送给你的。

当然，在沟通的过程中要抱着求学好问、认真思考的态度，不然的话，“傻白甜”似的发问会让再有耐心的人都不耐烦。

拿到了用户的联系方式后，就可以进行用户调研了，不管是电话调研还是当面调研都可以。在和用户联系前，最好列出自己想要了解的问题，这样不仅有助于自己在提问用户的时候，能够尽快地问道自己想要了解的事情，还能让用户觉得你是有备而来，是有专业态度的。

同时在调研时，不要光顾着问，还要对用户的回答记笔记，毕竟“好记性不如烂笔头”。

用户调研之后，还可以对竞品进行分析。查看同类型竞品的方案，看看竞品是怎么做的，总结竞品的优势和劣势。竞品看多了，也就有“胸有成竹”的感觉了。此时的竞品分析不需要像报告那么详细，只需要列出一下重要的东西。

下面是我当时做的竞品对比，主要是将几大竞品的优缺点做了对比。看了几天的竞品，心里对方案就大概有了方向。

2、确定方案

收集到需求后，这时候就可以进入到规划方案、画原型、写PRD的阶段了。

首先可以用功能框架图去梳理自己的方案，功能框架图不仅能够帮助自己细化方案，同时还能让别人快速了解方案的架构。

新人在写PRD的时候，要注意按照页面，详细地描述自己的原型。不管是名词的定义、页面的交互、计算方法，都应该事无巨细地描写清楚。

我第一次负责项目的时候，是一个报表类的需求，内容不多，也没有什么负责的功能。当时我写PRD的时候就没有写仔细，想着“这个这么明显，这么简单，开发和测试肯定知道”。

但是在后来开发测试阶段，不断有开发和测试来跟我确认原型上的定义和功能。尤其是测试，开发在开发的时候可能会按照自己的理解去实现，但是到测试的时候，测试同事会严格按照PRD来对页面进行测试。

一旦发现页面的的样式和功能和PRD有什么不一样，就一定会找产品确认。如果开发的理解和产品的理解一致，那还好说。但实际情况一般都是，如果PRD没有写清楚，开发做出来的东西是会和产品大相径庭的。

到了测试的时候，要不就是产品冒着被骂的风险让开发重新改，要不就是产品随着开发来改PRD。非常惭愧的是，我第一次负责项目的时候，不太强硬，然后也意识到自己在写PRD的时候没有写清楚，所以大部分无关紧要的东西都是顺着开发改PRD了。

当然，产品在思考方案的时候，也不能随心所欲，强加那种非常炫酷的方案，例如：“根据手机壳改变手机主题颜色”，这样很容易被打。

完成原型页面后，可根据原型页面产出一份功能列表清单，提供给开发人员。这样开发人员能够提前了解详细的功能点，便于评估工作量。

3、注重团队沟通

从某种程度上来说，产品是一个团队的“主心骨”。或许做助理的时候，大家都习惯了听命令执行。但是当你独立负责一个项目的时候，没有人在乎你是经理还是助理，他们只需要你把PRD定义好，站出来跟大家解释这个问题，遇到问题的时候确定解决方案。

这个时候新人的心态一定要及时转化，不然的话，太过于畏畏缩缩，不仅会延误项目进度，还会被大家质疑你的专业能力的。

但这并不意味着在负责项目的时候，态度一定是要强硬的、坚决的。当你确信自己的方案是最好的方案的时候，这样当然是可以的。但是当你不确信这一点的时候，你就需要态度谦虚一些，多听听大家的意见。

和团队成员沟通的时候，一定要态度良好，语气礼貌。尤其是需要改功能、加功能、指出问题的时候，不要一上来就是“唉，那个谁，我要在那加个东西”、“这个你写的不行，完全和我的PRD不符”、“这个页面太丑了，难看到爆了”这种过分的话。很多产品和程序员的冲突就是由这些话而引起的，谁听了这些话都不高兴。尤其是辛辛苦苦写代码的开发人员，本来工作就很累了，还要被一个产品，还是产品新人来质疑。

其实遇到些问题，可以换种说法，“X哥，这块可能要麻烦你加个功能，这个也是业务这边临时要求加的，我本来要放到迭代里去的，但是业务那要求一定要加在这个版本里，麻烦你了”、“X哥，这一块的东西好像和我PRD有一些不一样，这个会导致一些问题的。比如：“X哥，这个页面的配色可能有点太乱了，大红大绿，不够清爽，和我们系统的整体风格不符合”。

其实大家知道一个产品新人做项目的不安和谨慎，所以并不会过多地去为难你。只要是合理的需求，大家都会愿意听你的。

当然按照惯例，上线之后，产品给大家点奶茶也是需要的啦。虽然这次合作结束了，但是为下次合作拉拉好感嘛。

4、上线时，测试，进行验收

产品开发完成后，这意味着离项目成功结束靠近了一大步。虽然后续主要是测试工作，但产品也不能闲着。测试人员会给到你测试用例，你需要看一看测试用例的编写是否正确，里面对页面、功能的描述是否符合你自己的定义。

之后，还需要和测试同事一起，对即将上线的功能进行测试。当然，产品不需要照着测试用例去测，只需要看看页面样式是否正确，再点一点看看有没有什么bug。

5、快速想出后期迭代方案

产品终于上线了，如果没有什么大问题，团队人员都能够歇一口气了。但是产品还需要继续工作。这个时候产品应该快速整理这一版本有什么不足或来不及做的功能，快速整理好解决方案，放在最近一次迭代计划中进行优化。然后迅速和迭代的开发人员进行沟通，确认需要优化的方案。

总而言之，第一次负责项目是会非常累的。由于自己各项经验不够、对业务也不太理解，而且由于是初到公司，和同事也很陌生。在工作的时候，只能通过良好的态度和好学的精神去打动大家。被各方同事找到需要确认PRD的阶段，整天都是跑来跑去的，头都晕乎乎的。

但是经历了这一个完整的流程后，自己学到的东西是非常多的，不管是写PRD还是和大家沟通，自己心里大概都有了方向。而且最重要的是，在整个过程中，和同事明细熟悉起来。这在后续你的产品学习、工作过程中都会是非常顺畅的。当前前提得是你是一个好相处的人。

希望大家在项目过程中，少些撕逼和冲突，多些成长。

关键词： 公司 项目