敏捷开发一千零一问系列之十一:需求谁做主?

这是敏捷开发一千零一问系列的第十一篇。(在这里提问之一之二之三问题总目录

问题

原来问题是这么写的:“每个人对美的认识不一样,在产品开发过程中,该怎样有效控制界面设计用时?”

大致是说有些人觉得这样就得了,另外一些人觉得还不够漂亮,不知道评审的时候该听谁的。

这个问题有点另类,所以泛化成“需求谁做主”。

方案

方案1:听产品经理PO的

这个是简化的方案。

一般而言,我们总会挑选出正确的人,或至少是最正确的人——他对市场清楚,客户明白,至少在业务方面比程序员经多见广——来形成对需求的雏形,日后验收的,也是他。

这个人就是PO,Product Owner,产品的主人,产品经理。

不过,常常不存在一个人这么厉害,能超越和覆盖其他人的眼光和见识,怎么办呢?

方案2:听PO团队的

PO团队在产品管理系列中讲过,是一个高低、内外、业务与技术搭配起来的团队,从各个角度,保证对产品的把握。

这个团队不是一个“投票团队”玩少数服从多数的游戏,而是各自贡献特长互补的团队,人们通过共享知识+集体思考来判断哪个需求才是真正的需求。

方案3:做Servant,不做Owner

这个也是产品管理系列中提到过的,就是要真正为客户服务,而不要太在意“自己的审美观”。

对客户而言,不同的操作,会有不同的价值观,他们需要这些价值观服务于自己的工作。作为程序员,有时候会持有不太一样的价值观,比如技术先进性,性能,美观,而客户却对此不感冒。

案例

假设一个系统有一些自动的通知机制,应该在“我的通知里边”如何展示这些通知呢?

下面这个图平淡无奇,开始的时候就想到了,大致如此:

一些看不太出来的细节从左到右包括:

1. 闹钟是“限期完成”,鼠标悬浮时,上面出现限时的日期。

2. 三角是重要,图标是通知类型。

4. 小人是单发的还是群发的

5. 最右边的倒数第二个图标是“未读”,点一下变成已读。

6. 最右边一个是小旗子,点一下出现一个下拉菜单,选颜色。

 

这些,都是开发者(产品经理、程序员)的第一感。在开发到这里的时候,我们问自己:当一个用户看到自己的通知时,有哪些核心价值需要满足?

大致思考的结果及后续修改是:

1. 未读的是类型中最重要的----这导致缺省tab页面从原来的“所有”改为“未读”(图中为方便显示的是“所有”)

2. 阅读效率是至关重要的,这导致了很多变化,包括:

2.1 仔细看闹钟的左上角,每个事件距离现在还有几天,用一个极小的数字标识出来了,所以无需再“悬停”了

2.2 旗帜的颜色直接反映到通知内容中(比如“数据编辑”四个字是蓝色的,和旗帜相同),这样直接看文字比看旗帜再目光移动回来快很多。

2.3 旗帜上的下拉菜单操作太慢,改为直接点击就按一个顺序自动切换(只能用一个“爽”字形容啊)

……

3. 信息不要太凌乱

……额,应该说这个我们还有点做得不好,原来的界面比这个还复杂,已经简化过了,等下一步自己使用一段时间(我们“碰巧”自己用自己的产品),移除一些不太需要的信息,或者放到不显眼的位置上。

分析

注意在这个案例中,没有所谓“领导决定”“投票”这些内容,而是问“用户在这里有哪些核心价值需要满足?

就是不要把“我”放到产品中的过于重要的位置上,而是让用户做主角。

“用户"常常无法参加开发决策怎么办?其实当把握了用户核心价值的时候,不只是产品经理或PO团队,一般的程序员也能为这个价值贡献想法。如果没有把握这个价值,就会变成几个人无谓的争执,无论PO还是领导还是投票解决,结果都不会是最好的。

posted @ 2012-02-29 23:31  Java EE  阅读(113)  评论(0编辑  收藏  举报