产品与交付 · 事业与财富

项目一上来就画页面，很容易让大家觉得事情已经开始了。按钮、颜色、布局都有了，拿在手里也好讨论。但一个页面可以画得很完整，里面的人究竟要完成什么事情，仍然可能没说清楚。

我觉得先要讲明白几个问题：谁来用，什么时候用，做完这一步以后去哪里。功能名称只是一张目录，功能之间怎样接起来，才决定这套东西能不能使用。各方对用法理解不同，画得越细，后面需要推翻的部分也可能越多。

准备进入设计时，可以先拿一个具体场景走一遍。把每个人需要提供什么、能够看到什么、最后得到什么说清楚。遇到理解不一致的地方，当场记录下来。等这些关键问题确定了，再把它们变成页面，沟通会有一个共同的依据。

当然，有些想法必须画出来才看得见。这时可以先画粗稿，用来发现问题，别急着当成定稿。准备到什么程度，取决于下一步需要解决什么。把设计当作确认需求的工具，和把未经确认的设计当成开发指令，影响是不同的。

一句不好用，可以指很多事情。有人不知道怎么操作，有人遇到了程序错误，有人觉得现有流程不顺，还有人想增加原来没有的功能。如果把这些反馈都放进一个待修改列表，团队很快就会忙起来，却未必在解决同一类问题。

遇到问题，我倾向于先分清它是什么。操作不熟，需要说明或培训；已经承诺的功能不能正常运行，需要修复；使用过程不合理，需要检查设计；新增的想法，则需要重新讨论需求。处理方式不同，参与的人和完成标准也不同。

提出问题时，尽量说清楚自己做了什么、期待什么、实际发生了什么。把可以重现的现象留下来，再让相关的人确认。这样讨论就能从好不好用，往具体哪里出了问题推进，也更容易判断改动会不会影响原来的用法。

分类并不能代替修复，也不能成为拖延的理由。已经清楚的问题就往前做；还不清楚的部分及时核实。尤其不要把所有问题都说成用户不会用，那只会让产品失去反馈。先分清问题，是为了少走弯路，也为了让真正需要解决的事得到处理。

单个功能看起来正常，整件事情仍然可能做不完。能提交资料，不代表下一步的人能收到；能生成订单，不代表后面的处理有着落。测试只看一个个页面，很容易漏掉页面之间、人员之间和不同状态之间的问题。

所以我更关注业务怎样完整地跑一遍。从真实使用者的位置出发，拿一组接近实际的数据，把开始、处理中和结束都走到。过程中谁需要操作，谁要等待，出了问题由谁处理，都放在同一条流程里看。功能是否存在和业务是否能完成，需要分别确认。

测试也可以跟着开发进度往前走。已经完成的部分先检查，能够连接的流程先串起来，发现问题就记录和反馈。等到全部结束才第一次试用，前面理解错的地方会集中到最后出现，原来能及时调整的事也会变得仓促。

这不意味着不完整的版本可以直接给所有人使用。准备不足时，可以先用样板数据在明确的范围内测试，知道哪些步骤还不能完成。阶段测试帮助提前发现问题，最终验收仍要回到约定的完整用途。少一点凭界面判断，多一点沿着事情走。

讨论产品的时候，想法常常越说越多。每个人都能补出一个看起来有道理的功能，放在清单上也不显得多余。但真正开始做，设计、开发、测试和维护都要有人承担。这些事情叠在一起，产品就可能一直停在还差一点的阶段。

我觉得要回到当前要解决的问题。缺少这个功能，主要使用流程还能不能完成？它解决的是已经出现的问题，还是我们想象中也许会有的问题？如果没有它也能完成主要用途，可以先记下来，等使用中有了明确反馈再判断。

删减也要讲理由。让参与的人知道这次保留什么、暂缓什么，以及为什么这样安排。已经做好的部分列出待修问题，还没做的部分列出真正缺失的功能。把两件事分清，团队才知道下一步是在修补现有产品，还是继续扩大范围。

少做并不等于降低基本质量，更不能用赶进度解释关键流程做不完。当前阶段需要的完整性仍然要守住。把精力放在会影响实际使用的地方，有时比继续增加看起来很丰富的功能，更接近一个能够交出去的结果。

看到同行做了新功能，研究一下是有必要的。但对方为什么做，面对什么用户，准备配合什么业务，我们未必都知道。只看见一个新按钮就急着补上，自己的产品可能越来越像一张同行功能的汇总表。

我觉得更新先从自己的使用过程开始。业务有没有变化，客户反复提出什么问题，现有流程在哪些地方不顺。再去看外面的产品怎样处理相近的问题。这样得到的是可以比较的办法，而不是一个必须跟进的名字。

讨论新功能时，也要检查它与现有流程怎样连接。谁会使用，需要哪些资料，做完以后影响谁。如果这些还没想清楚，功能数量增加了，使用难度也可能一起增加。把运营上的实际需要说明白，技术更新才有比较稳定的方向。

外面的创新当然可能提醒我们发现原来没看到的需求。可以先在具体场景里试着理解，再判断是否值得采用。保持对同行的关注，也保留自己的选择。产品需要持续变化，但每一次变化，最好能够回答它究竟帮使用者把哪件事情做得更好。