|
•1、测试部门依据产品需求文档(PRD)，完成测试用例的评审;发起必要的测试用例评审，产品部门必须参加，确保测试用例的全场景覆盖;training.mypm.net
诠释：参与测试部门发起的测试用例评审;项目管理论坛
•2、测试过程中反馈问题的追踪，主要是正对问题数量及问题方面的总体情况追踪，确保问题的及时解决，测试部门必须反馈当天的测试情况反馈表;项目管理者联盟
诠释：持续跟进技术部门的技术实现进程，阶段式以邮件反馈进度情况;PgMp.mypm.net
•3、测试通过，上线前必须完成产品验收，产品产出产品功能清单，逐一产品验收，主要关注有无得问题;验收通过后，才能上线;(产品验收)项目管理论坛
诠释：如实核对产品最初设计与技术实现之间的差异!
阶段五：问题反馈training.mypm.net
•1、产品上线后，各个部门需要针对上线或者生产环境发现或者用户反馈问题，做及时的反馈;该反馈直接反馈到测试部门，设计产品设计的需求，按流程又各部门需求对接人提交产品部门;(问题反馈)club.mypm.net
•2、进入正常的产品环节循环执行;(产品进入周期性迭代循环过程)blog.mypm.net
小结blog.mypm.net
以上所述的部门协作流程体现了产品经理在整个流程之中所需要担当的职责和需要完成核心工作。以产品经理的工作为轴心，衍生出与各部门之间的交互。有朋友问我：这么复杂的流程实用吗?显然，再质疑流程的可行性和价值型。口头沟通确实是最简单和直接的手段，却也是最没有保障和最不可靠的做法。当然，我并不是想表达对他人不信任的意思，而秉承的恰恰是一种对彼此负责的态度。项目管理者联盟
不忘初心，方得始终。问题还要回到：为什么需要产品工作流程?做这样一件事情的初衷是什么?项目管理者联盟
1、 产品管理过程结构化、模块化，分阶段推动产品进程，易于管理;bbs.mypm.net
2、 规避项目风险，时间、空间要素构成了项目实施过程的潜在风险;项目管理者联盟
很显然，产品流程并不是为了规范上下游的同仁，恰恰是约束产品设计环节本身，是为了规范产品经理的工作。仔细想来，规范自己本质上是为了不给别人添麻烦，而这恰恰又是职场上最宝贵的信条——尊重别人的最好方式就是不给别人添麻烦。项目管理者联盟
很喜欢自己说的这句话：规范不是目的，只是手段!只有流程才能缔造优秀的产品，而优秀产品背后也必然对应一个规范的流程!项目经理博客
项目管理者联盟www.mypm.net
|
