产品负责人如何思考日常工作制度化——（产品需求发布篇）

如果产品团队没有能力或者意愿去改进现有的流程，那么就会持续饱受眼前问题的困扰和折磨，而且痛苦指数还会与日俱增，Mike Rother在《丰田套路》一书中指出，就算不去优化现状，流程也不会是一成不变的——由于混乱和无序，流程会随着时间的失推移持续恶化。

作为产品负责人可以使用下列问题来帮助团队不断可持续的优化与改进战术与打法
●  上一步做了什么？发生了什么？
●  你从中学到了什么？
●  现在如何？
●  下一个目标条件是什么
●  当前工作有什么阻碍？
●  下一步做什么？
●  期望的结果是什么？
●  期望的结果是什么？
●  什么时候能进行复盘？

产品负责人帮助团队在日常工作中发现并解决问题，这种方式实际上就是丰田生产系统的核心，也是学习型组织、改善套路和高可靠性组织的核心。Mike Rother指出：丰田之所以是优秀的组织，根本原因在于他们不断地向员工传授这种独特的行为准则。在团队作战中，这种实验和迭代改进的方法，不但能指导我们改进内部流程，而且还能指导我们不断地进行实验，保证构建的产品能为内部和外部客户带来价值。

将产品日常工作的改进制度化
1.1 需求分类
如可以将XX项目需求分为3类需求，分别为【门户平台能力需求】、【门户产品接入需求】、【运营管理后台需求】

1.2需求产出
规范产品经理须将各类需求对应需求所属归类，转化为【需求原型】及【需求文档】作为交付物，需求原型统一为RP、需求文档统一为WORD文档进行输出。

1.3 需求命名
原型分类+时间编号+Sprint编号，如：门户平台能力需求_PM2020_Sprint18如下图示例

1.4 需求存放
每个迭代需求统一上传至团队内部线上文档协作工具-【需求文档&原型】文件夹处，分别存放需求原型与需求文档文件夹中。

每个迭代版本需求原型，需按迭代版本编号单独存放方便查找，如下图示例：

当前迭代版如有涉及所属分类的原型，需上传把需求原型的原型按要求上传至文件夹中，注意文件命名规范，如下图示例：

需求文档存放需注意两个动作，分为“多方需求评审或内部需求讨论前”与“项目需求排期当天”进行需求存放，需求性质为“多方需求评审或内部需求讨论”存放在迭代版本外，需求性质为“项目需求排期当天”需在项目排期确认当天将存放在迭代版本外的需求移至当前迭代版本中，如下图【迭代需求18】

1.5 需求文档维护
需求文档由产品经理各自维护更新及时上传发布至内部文件协作工具

1.6 需求原型维护
【门户平台能力类需求】、【门户运营管理后台需求】由XX同学统一负责汇总与发布更新，【门户产品接入需求】由XX同学统一负责汇总与发布更新。