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

这是敏捷开发一千零一问系列的第十一篇。（之一，之二，之三，问题总目录）

问题

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

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

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

方案

方案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还是领导还是投票解决，结果都不会是最好的。