用户故事地图学习笔记(三)开局,中局和终局

对产品故事进行首次讨论,应聚焦于如何具象化产品的机会。需求其实很可能是一个假想,那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多,比如和客户、用户深入交谈,观察他们目前做事的行动,不断和他们反馈,用手绘线框图(Axure)和高保真模型实现解决方案的具象化,并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用,有价值,并能够质疑用户所说的内容,然后在开发过程中学习(Scrum),迭代乃至最终发布。必须要始终记得,交付给客户/用户的是可用产品。

基于验证的学习循环:开发-(最小可用产品)-度量-(与客户/用户一起,基于目标)-认知-(新的Idea)循环。

如何做计划呢?首先一点,就是要让所有团队成员对于即将要做的内容都非常非常清楚,因为估算要准确,就在于每个人都要真正理解自己在估算什么。第二步,制定可逐步达成的开发计划(先框架再细节。比如一种做法是先做端到端流程贯通以消除技术风险,再逐步添加业务功能)。注意,不要将所有的迭代产出都对外发布,对外发布是一个很严肃的事情,代表着对用户需求的承诺。

使用预算来评估估算是个好方法。

风险故事同样需要统一管理。不要遗漏。

“伟大的作品永远没有完成这回事,只有放弃”---达芬奇

迭代与增量。运用迭代思维持续评估和打磨作品,运用增量思维做加法。

开局,中局和末局。隐喻棋局。开局聚焦于必备功能或者用户步骤,重点关注技术条件和风险,所有开发只要跑通主流程就好。

中局,补充周边功能,主流程之外的可选流程以及复杂的商业规则,如果可能,增加质量方面的考虑,如性能,可扩展性和可用性。

末局,打磨,使产品更加抢眼。

你可能感兴趣的:(用户故事,编程思辨,读书笔记,user,story)