敏捷团队里的 [点菜人] 和 [厨子们]
2018-11-16
来源： 麒麟敏捷社区 罗琼
在以往传统的产品研发组织中，产品经理（需求负责人）负责提需求，项目团队接收产品需求并实现功能开发。项目的团队组织和实施由项目经理（PM）进行管控，当项目完成之后，产品经理对整个需求进行确认。在此过程中，产品经理和研发团队的交流集中在需求提出和需求完成阶段，在研发过程其他阶段交集甚微。
在敏捷团队中，产品负责人（PO：Product Owner）就是有权对产品方向和交付内容做决定的人。他负责的是权衡产品的资源投入与产生影响，而不仅仅是实现功能、特性或是文档，他与整个产品相关。他和团队的关系比以往更紧密，产品负责人（PO）和团队（Team）的关系就像中餐厅里吃饭时的“点菜人”和“厨子们”。
“点菜人”（PO）和“厨子们”（团队）在每次点菜（迭代）的开发过程中需要不断互相磨合、碰撞，才能给客户/用户(一起吃饭的人)带来一桌满意的饭菜。
"点菜人"要懂“厨子们”做菜工序
首先，“点菜人”需要懂菜，还需要知道做菜的过程，了解“厨子们”理解的“菜”，这样才能点出高效而合适的菜品。引用电视剧《纸牌屋》中的一句话“你得先学会划船，再去学掌舵”。作为船长，可以不去做水手的工作，但不能不理解水手的工作。即PO需要懂技术，以方便设计出更合适的产品。
“点菜人”需了解“厨子”团队
敏捷团队中PO和团队的职责有了很大的不同，作为PO了解团队，了解团队和团队的边界。“点菜人”需要清楚的知道“厨子”团队可以做什么？是做西餐还是中餐，是粤菜还是川菜等等？了解“厨子”团队之后，“点菜人”能知道“厨子们”是否能提供好的菜品给客户;如果不能，“点菜人”需要极力的打造“厨子”团队。“点菜人”和“厨子们”在不断的碰撞过程中加深了解，实现在满足客户需求的情况下保证“厨子们”有能力做出预期的菜。即PO需要知道团队的技术和能力边界，还要知道需要怎样的团队。
“点菜人”负责点合适的菜
“点菜人”面向用户选择合适的菜品，根据客户的需求，引导客户点合适的菜。同时“点菜人”（在一个迭代内）需一次性把菜单明细说明清楚，避免在做菜的过程中，提出类似加辣、少盐、不放香菜、葱花、加蛋等的需求。同时尽可能考虑这个饭菜提供方案，减少突发情况。比如，吃饺子的时候不仅要提供好的饺子，还要考虑提供好的蘸酱。即产品方案不完整往往是没有考虑全面， PO确认了本次迭代的需求，提交开发之后，要关闭本次迭代的需求。也就是说，原则上本次迭代不再加入新的需求。(Scrum Guide中解释为对于Sprint Goal不能改变，对于需求范围允许有一些弹性，但是要围绕既定的Sprint Goal。)同时还要区分是客户灵机一动的小点子，还是不得不解决的问题，需要取舍，最大化的给用户提供好的产品和服务。
“点菜人”和“厨子们”共同努力打造有特色的厨子班底
“厨子们”需认同好“菜”，“点菜人”需不断把收集到的各种反馈，传达给“厨子们”，让“厨子们”快速的知道做出来的菜是否令客户满意。即团队需认同产品。同时“厨子”团队成员，是经过选择组合的，是特意配备好的，比如有擅长捡菜切菜的、有擅长配菜的、有擅长做大菜的、还要擅长做甜点的等等；团队的每一个成员都干着与别的成员不同的事情，团队管理是要区别对待每一个成员，通过精心设计和相应的培训使每一个成员的个性特长能够不断地得到发展并发挥出来。即“期望全栈，同时尊重客观因素。”每位成员术业有专攻，也保持知识广度，即打造T型人才。团队角色能力要均衡。 T 型技能的的一个意思是「深度」，这点与传统专职团队相似，指的是成员具备某个领域的专长；另一个意思是「广度」，比如开发人员除了能够胜任研发工作以外，也具备一定的测试能力，又或是交互设计师也有一定的视觉设计能力。
“点菜人”善于利用数据，不断推成出新，持续改进
菜做出来后，“点菜人”和“厨子们”需要及时、主动挖掘客户意见和感受。保存用户用餐的相关数据（包括人群、偏好、口味等）借助于数据，分析客户的人群和偏好，有针对性做持续改进。比如，分析某个时间段内最高（低）点单率的菜品，以后可以发掘出更多高点单率的菜品；升级或淘汰低点单率的菜品。还可以收集不同客户人群对菜品偏好的不同，比如，年轻人爱吃“美味”且带来更多的“惊喜感”的菜，那为了留住更多的年轻人，可以尝试更多有创意的菜。即PO需要关心用户在产品上的行为，用户的行为数据和相关的反映用户情况的数据都是产品持续优化和前期需求命中情况的验证手段。
“点菜人”和“厨子们”共同努力把菜点好做好
“点菜人”需要鼓励“厨子们”不断推成出新，”鼓励创新，但当碰到无法预测的客观原因导致尝试失败，“点菜员”需安抚、鼓励“厨子们”，让“厨子们”迸发更多的创意，持续优化，“厨子们”也可以成为合格的“点菜员”。即“人人都是产品经理，让团队聚焦于产品价值提升”。
总结
敏捷团队中PO和团队需要互相磨合和碰撞：
●PO需要理解技术及其复杂性，以方便能设计出更合适的产品。
●PO需要知道团队的技术和能力边界，还要知道需要怎样的团队。
●PO确认了本次迭代的需求，提交开发之后，要关闭本次迭代的需求。也就是说，原则上本次迭代不再加入新的需求。
●团队需认同产品的目标。
●打造T型人才团队。
●PO需要关心用户在产品上的行为，善用数据，做持续优化。
●人人都是产品经理，让团队聚焦于产品价值提升。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
