本文共 2652 字,大约阅读时间需要 8 分钟。
Gil Zilberfeld在大会上做了的演讲。InfoQ采访了Gil Zilberfeld,谈到了产品规划与跟踪的更好方式,他的观点#没有估算,包括在产品规划中价值的讨论,以及如何提高产品开发的决策。
\\InfoQ:组织正在寻求产品规划及跟踪的更好方式。您能说一下吗?
\\\\\Zilberfeld:直到最近,组织都是在开发团队层面开始他们的敏捷之旅。Scrum、看板以及其他方式给与了我们规划和跟踪的方法。Scrum有现成的规划过程,包括发布、迭代以及每日工作。燃尽图和任务版可视化了状态以及查看分析是否到位,从而可提供良好的全局。例如,我与一个团队合作,他们持续地在一个迭代中交付60%的产品代办事项。幸运的是,我们只需要查看一下燃尽图,看到团队用稳定的速率工作,而他们花费太多的时间计划没有进入到迭代中的内容。
\\看板提供了一个看板板,但这看似简单。如果我们应用看板原则“政策明确(Make Policies Explicit)”,我们可以追踪工作流程如何以及在哪里卡住了。如果我们创建累计流图(Cumulative Flow Diagram (CFD)),我们可以根据前置时间(Lead Time)和在线制品数量(WIP)提前规划。在这两种情况下,我们到底基于哪一个做规划,目前正在收集信息。这个好处就是在过程中有一些可预测性。如果我们应用精益原则,约束理论和排队理论可以通过可视化、识别瓶颈以及改进流程成倍地增加可预测性。
\\搞清楚这部分的组织现在想要在组合管理上应用同样的原则。SAFe(一种规模化敏捷框架)为此提供了发布火车(Release Train),规模化看板是从开发团队到整个产品团队。这仅在最近几年才刚刚开始,因此比较明智的是慎重地把成功与失败的报告结果作为依据。参与的人越多,流程越复杂,并且可预测性开始遇挫。再次地,过程的可见性会带来较好的可预测性以及改进的能力。
\
InfoQ:对于#没有估算,您有什么想法?
\\\\\Zilberfeld:当我第一次听说#没有估算的时候,听起来像开发人员想要从项目发起人那里争取得到更多的控制。我的意思是,难道为项目买单的人不允许在整个项目中得到一部分控制权吗?
\\当我变得越来越感兴趣的时候,我问估算到底是做什么的。也许你对此答案并不惊讶:我们寻求可预测性!发起人想要估算,因为他们相信他们会帮助制定项目的最佳决策。哎,但并不总是这样。除了一些功能障碍,例如估算神奇地变成了承诺,或者估算通胀,我们并没有得到我们需要的工具。
\\要求估算容易,但他们很少有所帮助。实际上,他们是基于成本,而非基于价值来驱动决策。当我们以成本驱动制定决策时,我们是降低风险,而不是创新。在这层意义上,估算限制了我们创建新事物、提供更强大解决方案的能力
\\对于我来说,#没有估算变成了不仅是估算。如果决策在乎我们的估算,我们需要提供给他们,并提供其它因素,例如评估的复杂度以及历史数据。如果他们没有用,或者信心不足,那就不要投入太多。并且理所当然的,不管成本多少,开发同等的项目价值有时是值得的。
\
InfoQ:如您提到的,估算就是有关成本,不是产品和服务可带来的价值。当我们做产品规划的时候,在讨论中可以做哪些事情把价值考虑进去呢?
\\\\\Zilberfeld:这很有趣,我们经常要求估算成本,从而用于制定决策,但我们几乎从不质疑价值。我们假设有人已经做好了正确的优先级排序。另一方面,我目睹过很多项目,在他们要求成本估算后,得到越来越庞大的数字,而项目依然前行。为什么?因为他们有足够的价值。
\\价值估算和成本估算一样困难。然而,实践者可以用如延迟成本(Cost of Delay(CoD))的方法进行试验来进行功能和产品的价值估算。
\\例如,让我们看一组选项:
\\
- 功能A可以卖得更多,从而赚更多钱。 \\
- 功能B可支持保留现有的客户。 \\
- 功能C可以增加我们快速添加更多功能的能力。 \
每一个功能都可以用真实货币来评估。我们可以估算,从功能A上期望赚多少钱,或者功能B,我们可以节省多少钱。现在我们问每一项的延迟成本是多少,然后可以进行比较。接着我们可以检查,从功能A的早期获利或者从功能B的节省上,先开发功能C对此的影响。
\\一旦我们把所有功能都放在同一基准线上,并且估算每一项的价值,我们就可以决定先做哪个功能了。
\\CoD及其类似的方法允许我们基于更多的信息做决定,而不仅是成本估算。
\
InfoQ:产品开发涉及到很多决策制定。您可否给一些例子,通常是怎么做的?当制定类似决策的时候组织面临哪些挑战?
\\\\\Zilberfeld:我刚刚在ACE大会上做了一个演讲,名字叫“”,我谈到了产品经理从基于直觉到进行复杂的模拟来决定做什么。在项目组合层面,我们基于项目经理们告诉我们的内容制定许多决策。你可以说产品经理们是赌徒。不幸的是,就算你赌对了,产品也可能失败:一个好的产品会失败得很惨,仅仅是因为同一公司在两年前发布了很糟糕的产品,声誉变差,因此没有人会再看一眼新产品。
\\所以组织面临的最大问题是复杂性。复杂性并不新鲜,它一直存在。但是在新的敏捷世界里,很难让我们忽视它。当旧的产品扼杀掉了新的产品,这就是复杂性。当我们遭遇了不可预知的事件,这是复杂性。它就是项目杀手,有时也是公司杀手。
\
InfoQ:组织要怎么做才能改善产品开发决策?他们如何处理复杂性?
\\\\\Zilberfeld:不要忽视复杂性。相反,我们需要找到一种方式穿过迷雾而没有太多风险。我们需要假设我们在任意层面的无知,包括业务、开发和运营。一旦我们承认,难的部分就来了:我们需要改变工作方式。
\\多年来,产品经理们定义产品,然后开发团队开发几个月。我们得到仅有的反馈就是当产品发布的时候。我们再也不能继续按照那种方式工作了。不要用几个月的周期,我们需要做没有风险的试验。不要对整个产品投100万美元,而是需要用1万美元看看它是否可以解决问题。如果我们对了,我们可以继续以增量式验证我们的假设。如果不对,我们则为公司节省了一大笔钱。
\\当我与产品人员合作的时候,我总是缠着他们问他们对待办目录的价值有多少信心,包括问他们如何证实这些价值。如果信心不足,我们就计划一个短的试验,给到客户然后学习。如果对了,我们就继续。如果不对,我们就改变计划。
\
查看英文原文:
转载地址:http://bygjx.baihongyu.com/