作为一个新项目的产品经理，该如何入手新工作？

万变不离其宗，一个产品的诞生，需要搞清楚的问题和需要做的工作总是那么些，否则，项目必然会走很多弯路甚至夭折。

假如，你是一个新项目的产品经理，你应该从哪些方面入手开始你的工作？或者说，在一个项目中，产品经理需要做的工作有哪些？

1.这个产品是干什么的？

即给产品定好位，界定好边界。为此，需要回答如下问题：

A.做这个产品，想要达到什么目的？

通常是比较宏观的，如降低XXX成本、提高XXX效率、通过XX方式赚取利润等。千万不要认为，宏观的都是虚的，这些虚的东西，是评判产品功能设计好坏的标准。如公司建设一个ERP系统，目的是想要通过电子化办公，提高工作效率。结果设计出来的系统，线下一步可以完成的工作，系统上要流转七八次。没错，是实现了电子化，但目的达到了吗？回答完这个问题，可输出对产品定位的描述（给谁用来做什么？），输出对产品商业模式的描述（怎样赚钱？）。

B.谁会在这个系统上做什么事？

回答这个问题，就需要搞清楚，这个系统上需要进行操作的业务是什么？业务从开始到结束经历的流程是什么？什么人在什么场景下会做什么事？确定业务边界，明确业务细节。产出业务流程、角色分析、用例模型等文档。搞清楚这些，你就知道：哦，我的产品是给这些人（分析获得的用户）用的，是让他做XXX事情的（功能）。

2.如何实现这个产品？

知道了产品要满足的功能、需求点（story级），就可进行分版本迭代的工作了。
每个版本迭代中，应该完成如下工作：

A.规划第一版本

确定版本的边界，输出版本功能列表，并与业务部门、项目组成员就此列表进行评审，达成共识。

B.排定版本周期

根据功能列表，排定版本开发的周期，包括什么节点出需求、什么节点由谁完成什么功能（明确任务分配和里程碑）、什么时候测试、什么时候上线。

C.需求梳理和底层设计

需求是每个迭代的第一步，产品在梳理需求时，技术人员同步进行技术架构（整体架构大多在产品规划时就完成了），数据库等底层设计。在梳理需求的过程中，应该时刻考虑：如何设计功能才能让用户用更方便快速的方式完成他们想要做的事，并且达到了产品的目的（赚钱）。

D.评审需求，提交下一流程

需求梳理完了，与业务、项目组、产品部评审，评审完，修修补补，确认后，就可以交付给下一步，如交互、UI等。

E.跟踪研发，规划下一版本

通过站会、里程碑追踪等方式，跟踪项目进度，早日识别风险，如某一节点的里程碑延迟，那是不是考虑安排加班？除了进程跟踪外，应着手准备下一版本的工作，确定版本需求、梳理版本规划等。需求管理是迭代过程中很重要的工作，应做好真需求的识别，需求优先级的排定。

3.完成交付

经过多次版本迭代，完成项目边界内的功能，系统即可交付或进入成熟期。这个项目的研发工作基本完结。

如上，每个项目中，

产品规划书：交代清楚产品的定位；为谁提供什么功能？如何赚钱？

需求说明书：交代产品的全部功能点，及每个功能点是干什么的；简单几句话描述清楚这个功能点是干什么的？

需求列表：正在做和将来要做的需求集合，每周维护一次；

原型版PRD：提交开发和测试的指导性文档，按版本维护；应注意交代：操作、状态、条件、功能。某个功能包含哪些操作，什么条件下才可触发某个操作。

版本计划：每个迭代的周期排定、及现有进度，按版本出具，每周维护；

其他：测试用例、操作手册、培训资料、系统使用情况等；即时维护。

诚然，每个公司、每个项目都有特殊和不同，以上所说流程和步骤并非所有项目皆如此。但万变不离其宗，一个产品的诞生，需要搞清楚的问题和需要做的工作总是那么些，否则，项目必然会走很多弯路甚至夭折。

此外，以上只简单介绍了项目中应该关注的问题，至于如何搞清楚这些问题，每个人、每个项目的方法有很大差异，如业务导向性的需求获取方法更多是向业务部门进行调研；toC产品更多是竞品分析，情景假设等

万变不离其宗，一个产品的诞生，需要搞清楚的问题和需要做的工作总是那么些，否则，项目必然会走很多弯路甚至夭折。

假如，你是一个新项目的产品经理，你应该从哪些方面入手开始你的工作？或者说，在一个项目中，产品经理需要做的工作有哪些？

1.这个产品是干什么的？

即给产品定好位，界定好边界。为此，需要回答如下问题：

A.做这个产品，想要达到什么目的？

通常是比较宏观的，如降低XXX成本、提高XXX效率、通过XX方式赚取利润等。千万不要认为，宏观的都是虚的，这些虚的东西，是评判产品功能设计好坏的标准。如公司建设一个ERP系统，目的是想要通过电子化办公，提高工作效率。结果设计出来的系统，线下一步可以完成的工作，系统上要流转七八次。没错，是实现了电子化，但目的达到了吗？回答完这个问题，可输出对产品定位的描述（给谁用来做什么？），输出对产品商业模式的描述（怎样赚钱？）。

B.谁会在这个系统上做什么事？

回答这个问题，就需要搞清楚，这个系统上需要进行操作的业务是什么？业务从开始到结束经历的流程是什么？什么人在什么场景下会做什么事？确定业务边界，明确业务细节。产出业务流程、角色分析、用例模型等文档。搞清楚这些，你就知道：哦，我的产品是给这些人（分析获得的用户）用的，是让他做XXX事情的（功能）。

2.如何实现这个产品？

知道了产品要满足的功能、需求点（story级），就可进行分版本迭代的工作了。
每个版本迭代中，应该完成如下工作：

A.规划第一版本

确定版本的边界，输出版本功能列表，并与业务部门、项目组成员就此列表进行评审，达成共识。

B.排定版本周期

根据功能列表，排定版本开发的周期，包括什么节点出需求、什么节点由谁完成什么功能（明确任务分配和里程碑）、什么时候测试、什么时候上线。

C.需求梳理和底层设计

需求是每个迭代的第一步，产品在梳理需求时，技术人员同步进行技术架构（整体架构大多在产品规划时就完成了），数据库等底层设计。在梳理需求的过程中，应该时刻考虑：如何设计功能才能让用户用更方便快速的方式完成他们想要做的事，并且达到了产品的目的（赚钱）。

D.评审需求，提交下一流程

需求梳理完了，与业务、项目组、产品部评审，评审完，修修补补，确认后，就可以交付给下一步，如交互、UI等。

E.跟踪研发，规划下一版本

通过站会、里程碑追踪等方式，跟踪项目进度，早日识别风险，如某一节点的里程碑延迟，那是不是考虑安排加班？除了进程跟踪外，应着手准备下一版本的工作，确定版本需求、梳理版本规划等。需求管理是迭代过程中很重要的工作，应做好真需求的识别，需求优先级的排定。

3.完成交付

经过多次版本迭代，完成项目边界内的功能，系统即可交付或进入成熟期。这个项目的研发工作基本完结。

如上，每个项目中，

产品规划书：交代清楚产品的定位；为谁提供什么功能？如何赚钱？

需求说明书：交代产品的全部功能点，及每个功能点是干什么的；简单几句话描述清楚这个功能点是干什么的？

需求列表：正在做和将来要做的需求集合，每周维护一次；

原型版PRD：提交开发和测试的指导性文档，按版本维护；应注意交代：操作、状态、条件、功能。某个功能包含哪些操作，什么条件下才可触发某个操作。

版本计划：每个迭代的周期排定、及现有进度，按版本出具，每周维护；

其他：测试用例、操作手册、培训资料、系统使用情况等；即时维护。

诚然，每个公司、每个项目都有特殊和不同，以上所说流程和步骤并非所有项目皆如此。但万变不离其宗，一个产品的诞生，需要搞清楚的问题和需要做的工作总是那么些，否则，项目必然会走很多弯路甚至夭折。

此外，以上只简单介绍了项目中应该关注的问题，至于如何搞清楚这些问题，每个人、每个项目的方法有很大差异，如业务导向性的需求获取方法更多是向业务部门进行调研；toC产品更多是竞品分析，情景假设等

欢迎投稿 职场/创业方向. 邮箱wangfzcom(AT)163.com：王夫子社区 » 作为一个新项目的产品经理，该如何入手新工作？

标签：