在大部分人的认知里，产品经理都是与需求、原型和功能打交道的人。这样理解确实也没错，不过，作者分享的这个案例模版，对产品经理来说更能看到自己的价值所在。
本周我去了趟香港换证，刚好和香港网聊许久的一位老读者，也是某咨询公司的零售解决方案线的TL进行了一次简短“面基”，在沟通中他们的团队工作管理方式让我非常有启发，在这分享给大家。
在他们咨询公司中也有产品经理的类似岗位，但是他们对于产品经理的工作，定义为三个部分：需求管理，需求制作与需求实施。
每一项的详细流程如下：
动作1：将问题反馈给研发团队。例如，用户反馈当前缺少导出报表某字段功能，产品经理需找到研发同学解决。
动作2：接收需求，与相关项目产品经理沟通。例如，用户提出增加某功能，产品经理与研发团队讨论可行性。
示例：某出行APP用户反馈导航不准确，产品经理与地图供应商沟通，寻求解决方案。
动作1：将需求内容加入需求池。例如，用户建议优化搜索功能，产品经理将其加入需求池。
动作2：对需求进行排期管理。例如，一个季度的需求排期/月排期等。
这里我仔细沟通了一下，在他们团队对于排期的管理是严格按照排期日历去进行的。如划定了一个月是两个周一个迭代，那么所有的需求都是按照这两个周迭代去进行排期的，出现了任何问题都是顺延，以保证发版日期不变，例如出现了业务需要临时导出数据等这种临时插入性需求，也是等到最近的一个发版日期去进行解决和处理。
这样的好处是最大程度上保证了产研的节奏的稳定，这对于平稳输出来说是非常有帮助的。
动作3： 需求制作流程：双周/三周迭代/月迭代
完整流程：BRD提交时间-需求时间-评审时间-测试时间-UAT时间-上线时间
这里的流程和绝大多数产品经理工作不太一样的是会要求需求提出方提交一个清晰且明确的BRD，也就是业务规则说明手册，详细的描述这个需求的范畴和范围。
该文档的最大的一个作用就是帮助产品经理去框定业务天马行空的想法，同时更重要一点是有了这样的一个文档在日后上线之后，也可以杜绝业务在上线测试的环节再漫天要价，临时加需求等等一系列不合流程的情况。
动作4：项目管理软件录入
创建迭代文件，将多个产品文档放入该文件夹。
示例：某团队采用meego协作工具，产品经理创建迭代号文件夹，将需求文档、设计稿等放入其中。
动作5：周会同步
每周与团队同步需求进度，确保各环节顺利进行。
示例：某团队每周一召开需求同步会，产品经理汇报本周需求进展，协调资源。
在需求制作环节分为如下的五步。
动作1：BRD评审
通过的BRD纳入制作，未通过的BRD不纳入需求制作。
动作2：撰写PRD
在团队内部PRD形成固定模板（如：需求背景/用例图/UML/原型），方便团队理解和撰写。
动作3：PRD自查表
通过将往期需求评审中常见被开发挑战的问题如字段联动，正逆向流程等问题收集归纳，形成一份标准的自查表用于团队的产品经理去进行需求评审前自测回答这些问题，从而提升质量内部评审。
动作4：正式评审
组织相关团队进行正式评审。
动作5：复盘
评审完成后，产品经理组织复盘记录修改点和问题点，将共性点加入自查表，提高后续需求制作质量。
在项目实施阶段，这个团队中的产品经理还需要确保各环节顺利进行，以下为具体流程：
确保新旧系统数据无缝对接。例如，在迁移用户数据时，需保证用户信息、交易记录等完整性。
示例：某电商平台进行系统升级，产品经理协调数据团队，提前制定数据迁移计划，确保用户在迁移过程中无感知。
组织用户进行UAT测试，验证系统是否符合用户需求。例如，邀请典型用户进行测试，收集反馈。
在UAT测试通过后，进行数据验收，确保迁移后的数据准确无误。
在用户迁移过程中，解答用户疑问，定义相关流程。例如，制定迁移过程中的应急预案。
通知用户当前版本可能存在的问题及后续迭代计划，管理用户预期。例如主动告知用户批量功能的错误提示还未完成优化，将在下个月上线优化，提前在产品交付时就将产品可能问题告知用户，避免后续用户反馈时的激烈“吐槽” 。
我们回想一下这样的工作安排与流程，其实也有它内部的道理在里面。
我们都知道在很多公司里面分工其实是非常细的，这点尤其在大场中非常常见，但是这种过分的细分工作也在某种意义上造成了工作的灰色地带的空白。
最明显的情况就是大家变成了只为自己的KPI去奋斗，而对整个产品的整体一致性好与坏漠不关心。
但是这一点对每一个公司产品都是非常致命的。
那么为了避免这种情况的存在，这样的一种团队工作流程的安排，其实也就是要求每一位产品经理提供两个价值：
价值1：管生还要管养
做一个产品就像生一个孩子，很多时候不是产品不好而是业务流程没有改变，那么如何发现，或者如何帮助业务流程去进行调整？
就需要产品经理深入介入到产品上线后的实施运营过程中去进行产品运营，去不断地修正业务的实际使用情况，去调整业务流程，从而让业务流程与软件功能相匹配
价值2：产品可持续迭代力
软件急着上线，导致为了赶工做各种简化很常见，但是软件产品是可以迭代的，我们允许适量的问题存在，但是一定要在后续的版本中去将问题迭代掉。
那么这就需要产品具备可持续迭代能力，怎么具备这样的能力呢？就需要产品经理不断的优化需求制作的能力。例如需求自查表，以提升整体的迭代效率。但是这还不够，还需要业务同时去约束自己的。地球提出那这就需要业务去提供对应的BRD，来管理自己的需求及预期等。
而只有这样在技术册与业务侧两者紧密配合，同时去进行自我迭代的情况下，这整个产品才会具备可持续迭代的能力。
最后我想来一个灵魂拷问：在你当前的公司内产品经理有提供这两个价值吗？
本文由人人都是产品经理作者【三爷茶馆】，微信公众号：【三爷茶馆】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。