探索需求本质，让技术产品更有价值

关于作者

小苹果儿科医生的 CTO 邬彦达,负责小苹果儿科医生在线产品和技术,线下 IT 系统,上海医生集团管理等工作。邬先生在国内获得了计算机硕士学位,然后又在海外拿到了 MBA 双硕士学位。主要在 IT 互联网及移动医疗领域工作，有超过 11 年工作经验,先后在盛大网络,微软中国, EMC, 育碧上海工作室担任资深工程师，技术经理，产品项目负责人，大数据管理等工作。并且邬先生还是 PMI 中国医疗医药行业协会资深会员,国际商业分析师协会 CBAP中国发起人之一。

1

导读

大家好！在开始今天的分享前，请大家先看下面这张图。左边这张图互联网人经常可以看到，这个图原始来源就是技术人员，他们的产品策划都是医院实体人员，但是真的有用吗？没有用，他觉得做出来的产品还是有问题。右边当中，主要想说明当需求出来时，各个角色针对需求的观点都不同。

当我在看到这个图的时候，我注意到右下角这张小图，我想到一个案例。当用户没有见过苹果手机前，不觉得苹果手机好，但是技术人员做出来之后，用户会玩很嗨。我相信很多做技术的同学在大公司都可能有商业模式或者项目经理去对接。因为我在小公司，所以开发人员直接面对的可能就是需求提出者。所以我今天就想分享一个很小的思考模型给开发人员。如果你将来遇到业务人员，甚至跨行业人员跟你提需求的时候，你应该怎么沟通，最后才能达到让产品更有价值的目标。

这也是我今天想要分享的，这个价值是有人性的，为什么这么说呢？比如我喜欢玩高达，但我夫人不懂高达，所以在我眼里这是有价值的，但她觉得一点价值都没有。所以我们今天要讲的价值是针对人而言的。

2

你遇到了什么

技术人员在工作的时候会遇到各种各样奇怪的问题。

首先是老板的天马行空。当一个小公司只有两位开发人员的时候，很可能出现这样的场景：

王老板

小猿，你是不是可以做一个像微信一样的工具？

李小猿

老板，我有自己的原则，不能。

王老板

那你不是很牛啊，要么做一个能聊天能发信息的工具就行？

李小猿

老板，我……

第二个奇葩问题就是技术和销售之间的微妙关系。无论是大公司还是小公司，做销售和市场的同事经常会向用户承诺很多好东西，但是！！最后都不能做啊！！！不是技术不愿做啊！！是实现不了啊啊啊！！！

第三个让人奔溃的问题就是运营爸爸事太多。做运营的同事由于没有很深的技术背景，所以就需要有各种各样的工具，原本后台一行代码就能查出的数据，为了运营同事，还得做一个管理后台？？

第四就是运维问题。很多大公司体系比较完善，在做开发之前，都会告诉你需要遵从什么规范。但是一些公司安全人员一开始并不出现，等你都开发完成了，准备上线了，他再跑出来告诉你：不好意思，你这个代码不符合规范，不能上线。这也是因为在运维早期时，运维和开发人员没有有效沟通，导致开发出来的东西不能进行部署，从而影响发布。

最后一个问题是来自供应商的问题。供应商如何跟技术集成需求也是很多技术人员都会遇到的大问题。

3

如何处理误区

处理误区有什么方法？

第一种是唯命是从，老大开发什么就开发什么，如果他真的让你开发微信，那你只能躺在地上装死了。以我这么多年的经验来说，你在没有进行有效沟通之后去做一个需求，那做出来的东西肯定是没有好的效果的，简单来说就是花时间做了一个没价值的东西。

第二种方法是闭门造车，反正老板不是做技术的，什么都不懂，我认为怎么样就是怎么样，不用说了。那大家都知道，这样下去肯定没有好结果。

第三个是时尚达人，市面上什么火我就做什么总没错吧？我在海外留学讲 IT 的时候提到过，IT 是要提高效率的。比如有一家公司只有 5 个人，他要做线上电子流程规范化，花了很多时间也花了很多钱，效率还是提不高。最后只能回到线下纸质板，没想到效率反而提高了。所以不同场景有不同的解决方案，不能一味的追求流行的东西。

我们团队经过很多沉淀，最后发现对于线上的互联网+ 医疗，我们凝不了力，得不到我们想要的东西。最后我们选择回归医疗本质，由于进医院看病这个过程是非常有意思的，市场教育非常大，我们必须坚持本心去做这个事情。

4

真正的需求是什么

有哪些需求

吐了这么多槽，那么真正的需求到底是哪些？第一是商业需求。需求定完之后，第二层就是分解需求。相关的人，比如开发、运营、安全、后勤保障会对大的需求有相对应小需求分解出来。再往下就是技术人员最熟悉的解决方案。我认为其实是什么时候发布，部署这样一个需求，它的说法叫做过渡需求。最后两个东西就是实施相关。解决方案怎么开发，怎么设计架构，什么时候进行发布，什么时候进行部署，部署的时候如何避开一些错误等等。整个思考过程是这样一个回环，最后发布的时候还是要回到最初的商业需求，你的产品有多少量，能带来多少用户和收入。

有哪些角色

在整个过程中，都是要跟人打交道的。我在项目开发过程中接触到十种人，其中第一大类就是管理者，我把他们叫做发起人，他们基本上处于商业需求这一层。另一大类就是工作人员，项目经理，主题专家，实施专家，运营支持部，供应商，然后就是客户和用户，最后还有审核人员。这些人在四个层级当中，在这个思考当中怎么思考这个问题，首先第一点非常重要，所有人都喜欢一上来就提解决方案，我们技术人员经常觉得很多人不懂技术，因为他们都喜欢直接给解决方案。我们需要反复的问为什么，知道需求可以归类到四大需求类型中。如果下一层次需求无法澄清，从上一层需求考虑。所有人都要考虑到，哪怕通知一下，参考权利利益方格。无法澄清需求务必延期或者拒绝。

加强沟通

我们加强沟通目的是什么？在建立信任之后，患者找医生看病？我明白了，老大的想法是希望能够提高收入，他想出来的办法是他了解的行业，所以说最后的解决方案非常有意思，我们解决方案参考了采用了 24 小时，我们平台医生都是三甲大医生，他没有时间回答大家问题，24小时他们有固定时间段来回复。在做方案实施的时候，第四点考虑所有的人，我反复说到，我们写源代码时，是不是考虑运营人员的问题，最后是没有办法澄清需求，我的建议是拒绝或者是不做。

推荐工具

那么这么多人怎么搜集他们的需求？除了用户之外，其它角色都是少数。谷歌和微软人员都有一些方法，他们是搜集需求的方法，像访谈, 协作游戏, 头脑风暴, 工作坊等。人数多的组类—用户调查问卷，用户行为数据收集及分析、Google Analytics (国际)、 安装跟踪代码; 24 小时可查看;高级细分; adWords 整合;还有国内各类工具。

5

总结

最后简单总结一下。首先，建议大家要有一套思维框架，接收需求需要有一整套思维框架并有相应的落地工具。其次，我们思考的层级应该是: 商业 -> 干系人 -> 解决方案 -> 过渡期需求。第三点，需求必须澄清目的,否则不建议做。最后，所有相关人员都需要有所沟通，前面也说了，我们在开发当中如果处于这个环境，有必要让他们知道。谢谢！