需求管理的敏捷，为什么做不到？
理想中的需求敏捷，展现出一种目标明确且有价值、节奏轻快、协作自主、每个参与方（开发方、业务方与用户方）都在不断的正循环中受益的面貌。首先目标明确且有价值，如果你被安排去筑一堵墙却不知道为什么，你预见到的将是日复一日垒墙搬砖的枯燥；但是如果你知道这堵墙将堵住滔滔洪水，挽救2000万人的生命，你对待整个事情的思考就会不一样。软件开发也是如此，理想中的需求敏捷不是为了开发软件而存在，而是为了提供价值、解决了问题。在清晰的价值驱动下，以自主协作的团队为单位向前进发，以较快的频率去试验解决问题的办法（我们也可以称为“最小可行性产品（MVP）”，注意，MVP是指试验的过程而并非产品。）如果不奏效，放弃或者调整方向，开启下一轮的试错，而团队将受益于这样的有序节奏。试错的过程要轻快，引用我的同事张岳的话来说类似于“空手套白狼”，如果免费的方案可以解决问题，我们便不需要为了造软件而造软件，这也正是能让业务方受益的正循环。而用户，也能在最快的时间内获得价值并且参与到问题的解决过程。
一切听起来特别美好，价值优先级特别清晰，团队做得很high，上线后业务效果特别好，大家都得到了奖励💰，一切都很有节奏、很流畅。
然而在现实中，很多团队设置了迭代，建立了看板，每个迭代都做计划会，采用了用户故事，开卡、验卡都做了，甚至还有专门的敏捷教练辅导，但却一直陷在“业务需求永远也做不完的死循环”里：
很多人不禁开始动摇、怀疑：“敏捷，是不是在我们这里行不通？需求管理敏捷，是不是根本就无法做到？”
统一的产品待办事项 (Single Backlog） 小步发布（Small Release） 价值驱动（Value Driven）
1、敏捷的汉堡包式的Backlog vs. 传统的离散、自带鄙视链特征Backlog
传统上，由于决定产品优先级的干系人多来自业务背景，对于产品的待办事项（Backlog）天然会优先重视业务的开发，而技术改进、产品研究都是有“闲钱”再做或者应该由技术团队自己负责，性能改善和功能缺陷更是鄙视链的中低层，没有抱怨的时候就先放着，或者由技术团队自行消化。还有一种情况，如果同一产品有多个干系人，每个干系人都可能“扔”过来一本长长的文档，里面列着几十甚至上百条需求，以及标记着部门领导认为的“重要又紧急”的需求；当这些“重急”需求都挤到团队开发计划上时，往往就会陷入在办事项（WIP）数量严重超过团队可吞吐的能力，但是团队又无法自行决定优先级的状况。
敏捷需求中，将一个产品的待办事项比喻成一个汉堡包，里面如果只有肉（业务需求），长期吃就会消化不良，影响健康（技术债雪球越滚越大，开发效率降低等）。而在面对有多个干系人时，需要创造合适的渠道将汉堡的组成分享给所有干系人并达成共识；干系人之间可能会有争执，但这是好的事情，因为争执中人们会对究竟什么才是对产品发展有用的事情进行充分讨论，产出统一的目标与任务优先级。
2、敏捷的小步发布 vs. 传统的憋大招
传统上，如果是产品，是习惯于一年做一次规划、然后憋一年憋出个“惊世骇俗”的版本；如果是项目，则是三个月出业务需求、三个月做方案设计写需求规格说明书、六个月开发，这样从提出想法到看到产品差不多一年就过去了。
敏捷需求中，强调像吃上面这个汉堡包一样，每次一小口、但每一口要从上层要到下层、吃到真正有滋有味的汉堡，即一小批一小批，尽快上线提供价值。
3、敏捷的价值驱动 vs. 传统的产出驱动
传统上，以“完成多少条需求”、“开发了多少功能”、甚至是“写了多少代码行”这样的产出来做绩效度量；而敏捷则度量“多少需求真正对用户有用”、“在多长的时间内创造了业务营收”等。每一条需求，都要求必须澄清价值；需求的Backlog按价值做优先级排序；说不清楚价值的需求就不进入开发。
就拿小步发布来说，很多团队不是没尝试过，但却碰到了如下的“桎梏”：
如上图中的产品小A，很多干系人都在背后盯着这个产品，特别担心如果没有“足够多的新功能”，大家就评价不好。在组织的一贯思维里，上上下下都认为产品表现力就等同于 “若干数量的新特性”。做出小版本发布，挑战的不仅仅是自己的上级，可能还包括大老板、业务线领导、市场和运营等等。小A自己人微言轻，又怎么能撼得动呢？ 上图中的小B，IT部门一直就是被业务押着走，长期处于弱势地位。一开始迫于业务压力，也没有跟团队充分了解复杂度，对可能出现的风险估计不足，早早给业务做了承诺抬高了业务的期望，最终非常被动。 上图中的小C，在很多组织都存在。产品和开发测试是分开的；组织对产品的绩效考核就是“能上线多少个需求”，小C那肯定是逼着团队使劲往前做啊，哪怕知道后面有很多Bug需要返工。 上图中的小D，往往发生在比较多的B端产品的情况；与客户签合同的时候，为了拿单往往承诺一些需求，但需求的价值没有经过认真考量的，所以即使发现需求没有意义但也得照合同完成。
还有一种就是“大老板的需求”或“VIP客户的需求”：
看看，产品宝宝心里真地是苦！无论是哪种情况，很难简单地归罪于“哦，产品经理能力不行”。任谁都觉得难办！这是真真切切、非常具体的挑战。
那么，就从此一苦到底，彻底无解了吗？
产品经理：坚持三个底线
1、坚持需求20/80原则
产品经理存在的价值，不是“找出了多少个有创意的点子” 而是“在看起来都很有创意、很有价值的10个点子”里，挑出2个最突出的让大家做。所谓80%的价值往往存在在于20%的需求里。建立统一的Backlog，永远只找出价值最突出的Top20%给团队做。
越是有需求压力，越应抗住这个底线，只有抗住才能突破。当好开发团队的老母鸡，护好小鸡，而不是和老鹰一起来抓小鸡，最终都不得好活。
2、坚持与团队坐在一起
再好的想法，在用代码转化成为可用的东西之前，一点价值都没有。有很多产品经理/PO，离团队很远，好像不屑于和开发宝宝坐在一起。如果把产品比喻成一艘船，这个产品就好比坐在远方的岸边来遥控这只船。产品说，“西南23.5度有很好的鱼，快去打！”。但西南23.5的水下有个暗礁，只有船上的船员知道，因而决定不听指令径自往前走。这事情如果发生3次，基本上产品在开发宝宝这里就完全失去信任了；后面无论规划地多好也只是自high而已，并不能上线带来价值。
3、坚持成为业务专家
要识别“价值”，必须想尽一起办法花时间和客户、用户泡在一起，真正理解业务。《启示录》的作者Marty Cagan说，在他由开发转为产品经理之前，他的coach要求他至少拜访30家以上的客户以后，才能开始对产品需求进行决策。这个价值判断和分析，就是产品的责任，要让大家信服，就必须成为最懂业务和客户、用户的那个人。
别偷懒，把老板的话直接当问题。澄清老板真正的意图了吗？老板本质上想要的是什么？老板说要学习友商的XXX，可能是要我们分析清楚背后的逻辑、重视相关趋势，未必就是也要去实现同样的功能。不要只听表面，同理到老板/用户真正的意图，澄清挖掘到真正的问题，针对老板的目的，提出针对问题的专业解决方案（即要把老板需求翻译成真正的用户需求以及产品需求）。
你以为大老板真地爱提需求、爱做决策？很有可能你错了。老板的真实心声是：“眼看着时间窗口过去了，看你们没动静，只好提一提想法！” “都是拿着一堆需求来让我做决策，我上下文还没你们多，还要被迫帮着你们做决策！我是花钱请你们来给你们打工吗？”
针对老板的意图，利用对业务的专业性和对用户的洞察，提出多种解决方案，评估出价值和风险，提出自己主张的优选方案，然后给老板沟通。
如果除了大老板，还有别的多方干系人，最好的方法就是提前建立价值决策机制，统一遵守执行。
建立需求准入门槛。“只有排在Top 3的需求才能进入开发”；如果正面原则定不下来，可以定义“什么需求一定不能做！” 建立价值决策模型。根据产品的特点、产品所处的生命周期，综合考虑用户成效（如为用户带来的营收、任务完成效率、用户体验提升等）、企业成效（战略相关性、景恒利提升、预计创造的营收、节省的成本、缩短的上市时间、提升的效率等）、合作伙伴成效（供应商、及合作伙伴价值）等等，选取适合的若干价值因子，设置权重，建立权重价值矩阵。 无论是任何人提出需求，都要通过价值评估模型，依据评估的优先级进入Backlog。如果优先级低，即使是老板、VIP客户提出的，也一样也要怼回去。
价值驱动需要建立共识模型，这确实是比较重要，我们当前正在做一些探索和总结，希望下次能有机会来深入分享。
准则1：遵守数字产品本质规律，代码质量是根本。绝对不要照单全收业务需求、忽视质量。那团队就成了前有埋伏（新需求），后有追兵（bug），腹背受敌。当产品代码库X个、分支XX个、每个特性上都有几百上千个Bug的时候，修Bug的时间特别长、而且同一Bug反复出现、这个分支上修了、那个分支上好像还有......积重难返，再想回到好的状态就要付出相当大的代价。 准则2：如果没有产品经理/PO的话，一定要任命产品经理，对产品需求和优先级负责，从需求源头把控节奏；且要前移到业务和用户问题挖掘中，而不是等着接需求，仅当传话筒。 准则3：有了产品经理，把产品和开发团队拧成一股绳，抗同样的价值成效，奔着同一个目标走。不管是产品和开发团队，就只有一个目标，“如何把咱们这个迭代的投入转化为对用户可用的东西，给用户提供价值？”。不要让产品、开发、设计都是自己搞自己的。
Marty Cagan说，"IT is serving the customer, not serving the business"，但现在组织中恰恰相反。如果是组织最高管理者，那应该重新摆正IT技术的位置，让业务和IT真正协同起来，才能让业务需求-用户需求-产品需求端到端敏捷起来。
“在业务方或者说甲方制指定上线日期的情况下，BA如何用敏捷迭代的方式安排优先级？客户的口头禅就是：这个功能我十月30号就好，怎么破？”这种情况非常典型。
传统合同问题是最难处理的。x尤其是国内，很多组织还是很传统思维模式，甲方就是甲方、乙方就是乙方；敏捷宣言中的“客户协作 over 客户谈判”，压根就没这个基础。我们也的确面临过这样的情况，不能说有很好的办法，大致总结出的几条是这样的：
签合同时产品一定要参与。合同条款一定要明确目的和价值，注明需求在符合目的和价值前提下可以通过协商变更。这个客户一般会同意，因为他们也知道自己需求可能变。 在交付过程中，除了把迭代需求漂亮showcase外，要去通过各种分享、培训、一起回顾等等尽可能让客户理解支持敏捷价值观。 作为产品，提前2个月识别需求风险，尽早提出达成同样目的、但性价比更低的解决方案，获得客户认可后变更需求条款。这特别考验产品的业务理解和方案能力。
小产品团队（10个人左右）：此时产品经理/PO/BA可以是同一个人，此时无论戴的是什么帽子，所承担的职责就如同上面“敏捷需求分析”所示的那样，负责把业务需求转换到用户需求再转换到产品需求；作为需求的统一入口，为需求按照价值优先级排序，建立统一的backlog；及时为开发团队澄清需求；尽快让规划的需求上线得到用户反馈，尽早创造业务价值。 如果产品慢慢成熟，变成了非常大的产品，有若干子产品构成。此时可能就需要大产品经理（有的组织称为大PO）；而各个子产品/或者子领域，则分设不同的小产品（有的称为小PO，也有的称为BA）。此时大产品经理/大PO负责粗颗粒度的战略、需求举措规划、上线反馈及举措调整；而小产品经理/小PO负责子产品的需求，其职责范围如上述小产品团队一样。 在一些开发为外包团队、或者直接把一块业务外包出去的一些情况下，通常产品经理/PO是在甲方，而在乙方则会设置BA。这种情况下，甲方的产品和PO主要负责把业务需求转换到用户需求再转换到产品需求，作为需求的统一入口，为需求按照价值优先级排序，建立统一的backlog，“Do Right Things”；而乙方的BA则会是更多地负责给开发澄清需求、确保从PO到上线这块，“Do Things Right”。 现在体验设计（不单是视觉、交互）越来越重要，但我们发现的是很多产品团队仅仅只有“画界面”的设计，并没有完全洞察用户意图、从体验驱动的设计，这导致了产品虽然有很多功能、但体验是碎片化不流畅的；或者某个单点上的产品不错，但用户对品牌整体体验感知却非常差的情况。无论是To C、To B还是B2B2C产品，我们建议都要在产品团队配置真正的体验设计角色，重视体验设计能力的培养。 还有的团队，虽然有设计，但设计和产品、开发却是分职能的。这样以来还是长瀑布：业务提需求、产品翻译成产品需求、设计来完成交付设计和视觉设计、产品/技术负责人再写成需求详细说明书（或详细设计方案）、然后进行开发和测试。一旦开发和测试过程中发现设计不合理（技术不可行或技术成本太高）的情况，就要返回这个沟通流程来回确认导致延期、要么就是开发觉得这个沟通太累索性按照自己的想法来实现。最后时间一看不够了产品和设计也顾不得跳出来就先让上线。等最终用户看到，就是“无力吐槽”。有了UX还不够，UX要与产品一同敏捷起来，具体如何操作可以参见这本书：《Agile Experience Design》（当用户体验遇上敏捷）
另外，无论是什么样的组织、什么样的产品形态、多大多小的团队，敏捷需求的这三条原则是普遍适用的：
一定要有人（可以是产品经理/PO，也可以是几个角色共同组成的产品决策委员会）对产品统一Backlog和需求优先级负责，决定哪些需求做、哪些需求不做； 角色之间一定是要协作的状态，相互紧密融合，“Collaborative Design”、“Collaborative Analysis”、"Collective Owership"，而不是各自只管自己的一亩三分地； 从技能上来说，想要真正敏捷，每个角色都应该建立“M-Shape Skills”，有广度、并在2-3个维度上有深度，无论产品经理/PO、BA、UX，都是有一个自己的主特长、但同时又拥有的另外两个专向特长，大家的协作像是“橄榄球队”，哪里需要赶快主动去顶上，而不是一个“流水线”被动等着上游输出，这样才能让产品团队真正成为一个强大的团队。
如果仅仅是做形式上的实践，如站会、故事墙、用户故事、开卡和验卡，但很少就用户故事的价值发生过讨论和争执，就不是敏捷。
今晚8点，Agile Show第二期将讨论：真正的迭代难在哪里？欢迎报名参加。