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

7 评论 36997 浏览 300 收藏 7 分钟

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

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

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

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

A.做这个产品,想要达到什么目的?

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

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

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

2.如何实现这个产品?

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

A.规划第一版本

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

B.排定版本周期

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

C.需求梳理和底层设计

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

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

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

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

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

3.完成交付

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

如上,每个项目中,至少应维护的文档有:

  • 产品规划书:交代清楚产品的定位;为谁提供什么功能?如何赚钱?
  • 需求说明书:交代产品的全部功能点,及每个功能点是干什么的;简单几句话描述清楚这个功能点是干什么的?
  • 需求列表:正在做和将来要做的需求集合,每周维护一次;
  • 原型版PRD:提交开发和测试的指导性文档,按版本维护;应注意交代:操作、状态、条件、功能。某个功能包含哪些操作,什么条件下才可触发某个操作。
  • 版本计划:每个迭代的周期排定、及现有进度,按版本出具,每周维护;
  • 其他:测试用例、操作手册、培训资料、系统使用情况等;即时维护。

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

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

 

本文由 @李晓霞 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 提个问题:产品需求还没出的阶段,技术怎么做系统框架和数据库底层设计?

    来自北京 回复
  2. 非常感谢您的分享 很赞 没有水话 都是干货 提纲挈领 简单明了 赞赞赞!!!

    来自上海 回复
    1. 😆 谢谢肯定

      来自广东 回复
  3. 厉害,

    来自重庆 回复
    1. 🙂 谢谢~

      来自广东 回复
  4. 靠谱

    来自北京 回复
  5. 😉

    来自北京 回复