Melodie's typing...

回顾近期工作，发现大家做事情的方式发生了微妙的变化，但又很难说清那到底是怎样一种不同，郁结在心里。周五刚好读到 Intercom 产品 VP 的一篇文章 Great PMs don’t spend their time on solutions，醍醐灌顶，又狠又准地抓住了症结所在。于是写下这篇半笔记半译文的东西。

我们的工作流程有什么问题？

大部分公司的产品设计开发流程大同小异，分为这么几个阶段：

确定问题优先级 - 定义问题 - 设计解决方案 - 开发 - Beta - 正式发布

现在假设在一个项目投入的精力可以被分为 100 个单位，那么每一个阶段大概占到多少呢？

大多数公司在各个阶段的精力分布可能是：

确定问题优先级 5 - 定义问题 5 - 设计解决方案 20 - 开发 55 - Beta 10 - 正式发布 5

或者更「敏捷」一点，干脆是：

确定问题优先级 0 - 定义问题 0 - 设计解决方案 10 - 开发 75 - Beta 10 - 正式发布 5

当团队中有一些很「重要」的人想做「重要」的事情时，通常会出现上面这种情况，very important person 会说不用再纠结问题是什么，直接开始设计开发吧，再不抓紧就来不及了。

How we decide to work now is shaped by our prior experiences. For me, the ‘important person’s idea’ happened a lot on the projects I worked on at Google back in the day. There were a lot of people with big car/shower/neighbour ideas. Most of those projects were failures. I know other parts of Google were better, but that was my experience.

This also happens a lot in startups that are failing. When I talk to people in these startups, and ask them how they work, this is often how they work. They may talk about doing research, about talking to customers, but it’s just lip service, or a token gesture.

可是问题定义清楚了吗？

我自己的亲身体会是，PM 会找到设计师说「我们需要 X 功能」，这就是越过了问题直接陈述解决方案。X 功能只是一种解决方案，你要解决的问题是什么？为什么你觉得 X 可以解决问题？有没有更好的办法解决这个问题？脱离了问题谈需求，是本末倒置。

真正的「敏捷」是在每一个阶段都投入了相当的精力，而不是牺牲前置阶段来节约时间。何况找到正确的问题，不比找到解决方案简单。在理想环境中，团队的精力配比应该是这样的：

确定问题优先级 20 - 定义问题 20 - 设计解决方案 20 - 开发 20 - Beta 10 - 正式发布 5

或者，如果没有如此理想的环境，至少大家能多花一些时间围绕问题进行讨论，不要太着急列出需求列表、进入设计或开发。

为什么我们总想快速跳到解决方案？

为什么我们虽然知道「定义正确的问题」很重要，还是想拼命略过这个步骤，快点跳到解决方案呢？三个原因：

1. 定义正确的问题非常难。你需要和许多用户反复交谈、深入挖掘、不断提问，弄清楚他们的真实需求究竟是什么（人们倾向于给出他们想要的解决方案，而这可能并不是真实的需求）。这个过程挑战非常大，而且也很耗时。
2. 这件事看起来不太迷人。相比起来更酷的是产出研究报告、高保真 UI、原型。高层的人更喜欢看到这些酷的新东西，而不是阅读或反思。
3. 看得见的产出无法反映出这个阶段的工作，而且难以证实。有时候几个人可能要花几周的时间产出一篇短小简单的阐述问题的文字。对于不重视这个过程的管理者来说，他们很难认识到这件事的价值。

是啊，这件事很困难，但也最重要。

试着多花些时间在定义问题阶段吧。假如一开始的方向都是错的，跑得再快又有什么用呢？