Agile Alliance 质量提升-产品要提升思维层次-京东云开发者社区

产品的职责并不是为了完成业务或运营的一个个需求，要什么给什么即可，OKR达成就万事大吉；而是要将自己负责的系统看做一个完整的产品，对本系统负责的同时，对整个业务条线及相关系统均要负责，更大一点说，要对所有系统负责；这种负责，并非要去指挥设计其他系统，而是在设计本系统的同时，要更全面的了解兼顾到整体框架结构，以及本系统与相关系统今后的长期发展方向。

产品的思维在何种层次，某种程度决定了系统呈现出来的质量。格局是个很重要的概念，无论是价值观（不是我的系统不care）还是具体到需求点的设计（能满足需求即可，以后再说以后的），在头脑里都应一直存在。

**对于产品侧来提升系统质量的方法，大致总结了以下几点：**
- 多与业务沟通，了解业务侧长期规划及公司发展方向；
- 增加现场调研频次，本系统相关、非本系统相关、其他物流公司等；了解运营共性、差异及痛点；
- 多与业务侧探讨要解决什么问题，而非直接讨论如何解决；
- 产品线内各产品间要增加沟通，同步需求方案，统一思路，防止各自为战；
- 定期复盘总结；针对发生的系统问题，思考如何形成解决问题的规范，防止再次出现；例如非bug类的问题解决方案的汇总整理
- 定期培训：产品定期给研发及测试进行培训，讲解系统流程、系统变动、外围系统交互、整体规划等等；提高研发测试同事对业务的理解程度，有助于及早发现设计问题、以及开发时更好的通盘设计实施方案；
- 预见问题：根据上述复盘总结等，提升预见问题能力，将此反哺至需求及规划阶段；
- 优先级：业务侧有优先级，产品侧也该有自己的优先级，将相互制约影响的需求排出后统一规划设计；（问题点：倒排期导致的临时方案频出）
① 能否通盘考虑，而非单个需求；是否可以整合需求；
② 尽量减少临时及短期方案；
③ 输出临时方案时需确定好长期方案；临时方案不能与长期方案背离；
- 产品方案输出后，产品要与研发及测试进行需求沟通，而非必须按产品设计方案开发；
- 测试更早进入：在产品方案确定后，即进入评审并输出相关测试功能点，同时需产、研、测同时评审；
- 关于共建：由于研发资源有限，共建是个无法避免的推进方式；但共建对于系统来说，是存在质量降低及运维成本提升风险的；从产品侧来讲，如发生共建，则本系统产品必须全程跟进，而不能只是上线前研发侧的代码评审；
- 目前涉及多系统项目，在发布至UAT环境后，业务侧无法跑通流程的情况非常普遍；建议产品协助测试人员在预发环境做连通性测试，调通后再由业务侧进入测试，保证质量及体验。

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：供应链技术部 胡浩