CSPO培训后的新认知

几年前错过了CSPO，以为这一辈子就错过了，没想到就像秘密而言，只要你需要和意念强，它终究会来。机缘还是那么巧合，还是吕毅，这位带我进入Scrum世界的领路人，当年师从于他在上海学习什么是ScrumMaster，如今在杭州再次拜师门下学习什么是ProductOwner。还是在Scrum的管理框架下，还是做那些事情，以前是以SM的视角在看，现在换成了PO的视角，惊喜地发现了不一样的风景，

1. 加法容易，做减法难。加一个新功能？加吧，只要资源够，但是要删繁就简，这就需要勇气了，沉没成本往往会让你束手束脚。对于功能如此，对于流程也是如此（以前RCA的结果往往是处理异常的Checklist满天飞），对于人也是如此，学会说No！

2.项目管理层面的度量都是线性，如工作量、完成的功能点，但是业务层面可以度量已经发生的但是没法预测，因为业务层面的实现是非线性的。把功能点都完成，从业务层面Outcome这个产品就成功了，未免太天真了。

3.Product Backlog是线性的表，而业务层面的非线性就会让你觉得仅仅用这个backlog来管理业务是不够的，怪不得以前觉得怪怪的、有点难受，原来根源于此。

4.敏捷宣言中，Customer Collaboration，不仅仅限于和客户的沟通，还有PO和团队的沟通。

5.不要囿于Tool，思维方式先到位，再考虑用什么工具，Jira、禅道、Agilefant、redmine，其实对于增量式需求的管理，业界更多的实践是白板+Excel，这是用了就扔的，不用保留。而基线需求，还是得要一个需求说明文档，有的是落地到测试用例。

6. PD的角色定义，其实没有统一的，各个公司不一样，每个公司的岗位其实是组织需要的角色。

7. Scrum的理想解实施，需要从组织层面的改进，包括绩效考评的方式。比如说，自组织团队可以自己认领任务。刚开始分工尚未形成时这是可以的，但是做到后面，你之前做了这块默认还是你来做，别人不会来抢，这是人性，同时站在部门经理角度，他想要自己的资源在某一块领域的深钻，怎肯让你随便派他的人去别的领域瞎逛呢？虽然实现不了理想的Scrum，但是世界是有弹性的，在一定范围内还是灵活的，这就转换成如何在上下文中把握度的问题。

8. 最后一点，也是最重要的一点，context，上下文。这个词在学操作系统时迷糊了半天——中断需要保存上下文。上下文真的很重要，工具很多，适用于什么场合要自行判断，牛刀杀鸡、削足适履的生搬硬套反而适得其反，在MBA课上被传诵的一个笑话是一个小老板学了MBA后反而把公司搞死了。而从另一个角度来说，学习工具要守破离，先知道有这样的约书亚树，试着用起来，再改变，也是把握灵活的度。Flexibility at context !

如上，零碎地总结了被刷新的认知，这是一个delta的过程，也是敏捷的过程，记录这些点滴在这里，经历几年PO的风雨之后再来看应该有不一样的感受吧，期待着那一天。