iPhone 4颠覆了人们对智能手机认知的那一年，正是出版社如火如荼的开展数字阅读的元年。R公司，以可旋转的魔方作为电子书目录的独创设计，令他们赢得了一个重要的出版社客户。

不过，实际开发的过程中，R公司的PM发现，魔方目录会导致程序闪退，无法解决，因此据实已告，并建议客户换成传统的目录。客户方坚决不同意，PM也只能“顺从”客户的选择。

App上线的前三天，在App Store中创下了同类产品下载量第一的好成绩。还没让PM有时间沾沾自喜，客户的电话就来了。

 “很多用户反馈，目录页面没法使用，只要旋转魔方就会闪退！怎么回事？！”

 “这个问题啊……我之前就跟你打过招呼了，是你坚决要保留魔方目录的。”

 “你怎么可以这样讲话！我要找你领导！”客户说完就把电话挂了。

PM冷笑了一声，“SB，让你跩！”，转眼就接到了老板的电话。

“客户怎么会这么生气！赶紧先换成传统目录，保障正常使用！要快！！”

PM得意洋洋的挂了电话，心想，“找老板还不是一样？SB！”

这是一个难得的客户“屈服”于PM的案例，是PM难得的“胜利”。在你的工作中，是不是也有这样SB的客户？就是不信邪，非要撞南墙？偏偏喜欢折磨工程师，好像自己真的是上帝一样？

需求啊，需求……谁人欢喜，谁人愁……今天，我们就说说软件开发的需求管理。

通常，需求管理解决方案是长这个样子的：

尽管一般人都知道，但还是做不好。难道是需求管理解决方案有Bug？呵呵，别皮。这都是出自无数研究、无数实践、无数专家之手，和无数公司血泪史的精华。那为啥，你照着做，却收效甚微呢？

因为

（想想上面那个案例）

难道客户不是SB么？

不知道要什么，不SB吗？

只能说感觉，不会说功能，不SB吗？

要这个、要那个，让程序很负担，不SB吗？

不听劝，非要这那那这，不SB吗？

……

所以，因为客户搞不清需求、弄乱了需求、夸大了需求、忽略了需求……需求的源头出现了问题，而程序员只能被动接受、主动背锅。凭！什！么！

来，程序猿，看看你的同行——公关狗。

为啥我堂堂程序猿，要与公关狗为伍？

因为，你们的工作都是极具创造性的。需求人员为软件提供了创造思路，设计人员设计了软件的架构，编码人员用代码创造了软件产品，测试人员设计的测试用例验证了前面所有人的创造……亲，你还认为自己是搬砖的码农吗？你是一个地地道道的设计师！你的每一天、每一行代码，都在创造功能、产品、服务，让客户和用户的生活变得更加美好！

我不想给你喝鸡汤，但你确实需要洗洗脑：

需求不是魑魅魍魉，需求管理解决方案也没有Bug，需求仍然做不好，是因为你没有运用设计思维，“像设计师一样思考”。

David Kelley列举了几种思维的分类：

很显然，设计思维是最合适程序员的。设计思维，源自斯坦福大学大名鼎鼎的D.School。这是一所由机械工程系教授David Kelley创办的学院，专门教授设计思维课程。横扫全球的“互联网思维”，就从中借鉴了很多内容。David Kelley是个工科生，却发明了设计思维，这从侧面验证了,程序员运用设计思维完全没毛病。

那么，程序员该如何利用设计思维，真正解决需求问题呢？

David Kelley为我们提供了五个步骤：

我们结合R公司的案例，一步一步来看看：

换位思考，以客户为中心，洞悉客户深层次需求，并获得创意思路。

客户真的是上帝，不管他作为需求的源头是多么的“不靠谱”。可需求就在那里，你见与不见，它“不来不去”“不增不减”“不舍不弃”。挖得到，是👍；挖不到，是👎。

R公司PM的那句“SB”，没有骂到客户，但却让自己一叶障目，堵上了与客户愉快解决问题的道路。你可能会说，PM有同理心，就是对自己残忍嘛。其实，情况并没有你想的那么糟。↓↓↓

重新定义是指设计师转换思维模式，摆脱困境的方法。怎么做？连问至少3次“为什么这个对你很重要？”根据情境，适当变形。

还是R公司的例子，我们把时间推到PM第一次与客户沟通魔方目录的隐患。

“魔方目录会导致程序崩溃，换成传统目录，程序会很稳定。”

“不行，一定要魔方目录！”

“能请您谈谈，坚持选用魔方目录是出于哪方面考虑吗？”

“效果炫酷啊，所以当时你们赢得了这个订单。”

“您为什么这么看重效果炫酷？”

“有创意，我就没见过行业内谁是这么做的。”

“为什么行业内的独创，您觉得至关重要？”

“电子书区别于纸书，就在于丰富了展现形式嘛。况且耳目一新的设计，会吸引更多的读者，让我们有机会抢占电子书市场，保持领先优势。”

你看，经过对问题的重新定义，客户并不是就要那个魔方目录，他要的仅仅是一个“展现形式新颖的目录”而已。

The best way to have a good idea is to have lots of ideas. 

——Linus Pauling 与居里夫人齐名的科学家

既然客户不需要R公司的魔方目录，那么也许可以试试“寻宝目录”“菜田目录”“机器人目录”“AI联想目录”……你看，我随便想想就有很多主意了。如果换成R公司机智的程序猿设计师们，天呐，会不会内存都装不下了？

把你的多个解决方案显性化出来。

让你的使用者使用这个原型。

第四步和第五步，这就是大家都知道的Demo阶段。不废话，就想给你看一个简单、有效的Demo方法。

如果R公司的PM，这样去跟客户评审和确定创想出来的很多Demo，一定是有趣而高效的。不仅如此，PM也不会觉得客户是SB了，他会更加有同理心，更能清晰的定义问题，找到更多、更好的解决方案并实现它们。从此摆脱需求的困扰，走上工作的巅峰。

行动正确但受限时，就是转变思维的契机。因此，被需求问题卡的动弹不得时，亲爱的程序猿，要记得，自己是个高大上的设计师哦~