预测赢家
我们已经讨论过有关如何构建东西的扩展和方法论 ,但是,嘿,我们想知道构建什么 ,该死!
不幸的是,SAFe,scrum,XP或Lean Startup并没有谈论我们需要构建什么。 只是如何将其发布出去。
选择获奖产品似乎是圣杯。 业务分析和产品管理方法可以为我们提供帮助。
问题在于某些常规方法无法实现。 他们依靠直觉或对信息的主观解释。 而且他们没有考虑市场的复杂性。
在过去的十年中,出现了许多有很多共同点的方法,这些方法改变了我们对问题的思考方式。 他们试图将我们的建设方式转变为现实可行的方式。
首先,我们需要解释什么没有意义。 假设我(产品经理) 知道我需要一项功能。 团队花费了6个月的时间来构建它,然后向我展示,我说,“这不是我想要的”。 听起来很熟悉? 我们可以说客户(我)永远不知道他想要什么,但这很容易实现。 真正的问题是团队不了解正在解决的问题。 如果团队理解问题,他们可能会提出其他解决方案,不会浪费6个宝贵的时间。
问题始于我们不问“功能解决了什么问题”。 更重要的是,我们应该从问题开始,然后构建解决问题的功能。 这就是Chris Matts的Feature Injection背后的原因。 除了很酷的名字,对需求有真正的了解,然后才提出解决方案的建议。 这就是Gojko Adzic的Impact Mapping的背后,我们从我们想要实现的影响开始,然后弄清楚如何构建它。 这就是Liz Keogh的Capability Red背后的宗旨,在这里我们希望了解客户,以便为他们的问题制定解决方案。
并且不要忘记设计思维 –实际了解问题所在,然后提出解决方案。
在所有情况下,都可能有比我们最初想到的解决方案更小,更轻松和更便宜的解决方案。 一旦我们了解了需求或问题,我们可以提出多种解决方案,而不是选择一种解决方案。
您可能会在此时考虑:这只是常识。 这些是简单的想法。 为什么,我可能想到了!
好吧,这并不常见。 组织继续开发其产品人员的想法,部署解决方案,然后看看会发生什么。 只是,然后了解事后发现的情况。 那是一个很大的屁股反馈周期。
这可能并不常见,可能并不容易,但是它具有简单的敏捷性。
翻译自: https://www.javacodegeeks.com/2015/02/new-agile-picking-winner.html
预测赢家