谈谈敏捷团队协作的那点事
|
序 "现在运营/产品/研发/测试不好，换一个可能还不如现在这个，忍着点，妥协点。" 这个想法，第一个悖论，为什么换了不一定有现在的好。其次，没有任何人有义务负责别人成长的。"你如果不成长，我们就换一个比你强的来。" —— 这是职场，不是过家家。 无论什么原因而造成的版本延期，这是一件多么严重的事情！这也许不关乎 KPI 考核，但这关乎团队的承诺。 无论是作为运营、产品、研发或测试，在自己的领域都需要定义自己的游戏规则和底线。制约别人，也约束自己。 问题 版本功能和发布计划在迭代中多次被修改，尤其是造成版本延期的故事。 版本需求在前期没有进行竞品分析。 部分需求和变更存在不合理，当出现问题时，多是靠打补丁方式进行补救。 规则 最重要的规则 —— 沟通 在版本启动之前，运营需要准备 MRD（Market Requirement Doc），产品需要准备"竞品分析"和 PRD（Product Requirement Doc），还要有研发设计评审和测试用例评审。 最需要关注的是事情 —— 缺陷 在版本启动之后，之间的沟通都是围绕着需求缺陷和设计缺陷，会严格评估造成延期的内容。 最不能容忍的事情 —— 变更 作为敏捷团队，应该是拥抱敏捷的，但是 Scrum 也要求在 Sprint 中不能变更故事，变更必须放到下个 Sprint。同样，可能造成版本延期的变更，都是极其重大的事故。"这不是闹着玩。" 最不能缺少的环节 —— 告知 由于部门差异，有的是运营会将需求直接告诉产品或研发，而有的是告诉产品再由产品告诉研发，不管那样，相互之间的通讯是必须的。 在处理版本变更时，可以是某一方发起的，但不能是单方决定的。 无论作为哪方，哪些事情是你能做的，哪些不是你能做的，弄清这些，就知道游戏的底线。 最适合的标尺 —— 合理 无论是运营、产品或研发提的需求，都可以被挑战，需求应该是合理的，不合理的需求就必须被反驳。同样，不合理的设计和排期也是不被允许的。 最需要清楚地事情 —— 需求源 作为敏捷团队，是一个 Team，运营、产品、运营或测试都只是 Team 中的一个角色，人人都是产品经理，只要需求合理，都是需求提供者，而绝非仅是某一方。并且，计划会议的需求必须事先通知需求干系人，否则上不了计划会议。 各方需求各自梳理，在计划会议上，各方阐释需求，团队进行优先级PK，需求未达成一致的，由 PO 决定。 流程
底线 版本功能和发布计划在启动后不可变更 不合理的需求或变更必须反驳 迭代任务在计划会议评估确定，前期由产品、运营和研发团队负责人进行梳理 "每一个机构，每一个部门每一个岗位都有自己的游戏规则。不管是明是暗，第一步学会它，不过好多人还没有走到这一步就已经死了，知道为何？自以为是。第二步，就是在这个游戏里面把线头找出来，学会如何不去犯规，懂得如何在线球里面玩，这样才能勉强保持性命。" —— 寒战 本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然) ©著作权归作者所有 |
