"工作进度怎么样了？"我向开发的伙伴问道。
"现正在做数据的传输，数组的排列@#$%^"。我一听，额头顿时黑线。
"说抽象点，不要说那么细。"
"哦，你不懂开发是吧"开发说。
"告诉我你现在做业务的哪一个环节，进度是百分之多少？"我晕。

上面往往发生在工作或入行没多久的开发身上。因为工作性质他们更关注功能实现点，还没有建立起业务思维，在和非开发人员进行工作对接时没有考虑如何从对方关注的层级来对信息进行简化处理，对细节信息模糊化。

如果开发小伙伴在描述工作时能够运用抽象思维，沟通就会顺畅得多了。抽象思维在生活当中有很多的应用。通常我们要对信息抽象化，不是因为讲细节别人不明白，而是要借简单的表述，让别人在非常短的时间内就能够了解你要表达的内容。

以前做智能家居作为参展方参展，有人经过展台旁边，会好奇地问：你们这智能家居是做什么的？看产品通常没耐心听你讲太多内容，你需要在开始时候一句话就能讲清你的产品。我就跟他们讲，就是用手机控制家里电器啊，比如电视，空调。

你看，我在跟他们讲的时候，实际隐藏了很多的细节。至于手机是怎么控制的，通过什么方式连接到电器的，手机是不是要装个app，手机是不是需要联网，控制的电器有哪些？我都没去讲，为什么？你上来给他讲这些内容，有必要吗，他会去关心了解这些细节吗，这些细枝末节反而增加他们对了解事物成本。

在产品设计中，需求分析应该是抽象思维应用最多的地方。从大量的业务资料收集，流程梳理到最终产品的设计本身就是一个抽象的过程。需求的开始工作就是一个不断汇聚的过程，前期积累必要的资料，然后再一点点剥离不必要细节，重点关注业务流程中的主要业务对象。不断地做减法，对业务对象的每一个功能都要进行必要的确认：是否可以去掉该功能？去掉该功能后是否会影响正常业务的运转？而不是做加法，添加这个功能对业务有没有影响，放在这里，可能会对有些用户有帮助？可能？有些用户？我认为这是一种模棱两可，和稀泥的思维和态度，没有明确的产品目标和产品标准，对产品的发展是一种伤害。

从简单到复杂太容易了，不断地往里面加功能就可以。

从复杂到简单就难得多，保持主干清晰，分枝适度。

需求分析要做的是去繁就简，抽出其中的主干。

抽象思维在需求分析的两方面有着重要体现，适用性和精简性。

适用性

刚开始做程序员时，接到工作安排会立马去写代码，结果被老大训了一顿，先熟悉业务文档，看两天，想好再写代码。当时不明所以，心想立马上手干活还竟然说我。后面工作中慢慢体会到其中的意义和必要性。做程序设计的大忌是，没有理解透业务，设计好合理的程序结构，一上手就开始写，代码的模块化程度低，复用性低，程序到后面是越来越容易出bug。经验丰富的程序员就懂得设计合理程序，考虑代码的扩展性和复用性。

同样的道理，刚入门的产品人接到需求点往往只考虑到按需求方提出的要求去实现其功能。

实际上，我们在接到需求时从其出发点来考虑，不仅要看到影响需求的决策因素，还要考虑到影响需求发生变化的其它因素，需求背后的动机是什么？在产品设计的时候就要照顾到这些影响因子，去满足用户一类的需求。举一个例子，

比如说，产品初期业务员提了一个需求，加一个应用下载二维码，方便客户扫描下载安装。业务员在推广时发现，让别人到应用市场去搜索再下载十分不方便，客户与客户之间传播也不方便。业务员提出需求的动机是为了方便客户同事之间应用的传播与分享，但这里只涉及到面对面的场景，如果不是面对面怎么办？做的时候就要多往前考虑一步，支持微信，QQ等好友的分享功能。

往前一步，除了能够对用户提出的要求进行精准的分析，满足他们的需求，还要对用户未来的业务作出合理的预测，提前在产品设计上埋下伏笔。等到某一天，市场人员提出需求时，可以直接霸气地说，我们产品设计已经考虑到这个需求，完全可以支持，2天就能搞定。看下面权限设计例子，

销售主管说，产品要加个权限，要区分开销售主管和业务员，哪些功能销售主管有，业务员没有。显然，这里涉及了用户角色，设计的时候，不光是要考虑到从用户角色出发，而不是仅仅添加两个成员，还要做产品结构设计上做好预留，如果未来来了销售总监呢，后面又来了销售总监呢？甚至现有的业务功能和公司组织架构发生变化呢？

再往前一步，从行业的发展去着手需求分析，控制事情的发生。对B端产品来说，产品解决的问题不是简单地将线下的业务搬到线上来处理。比如说供应链的2B行业，即使是一个细分行业在某一个事务上处理都有不同的业务规范和准则，凌乱复杂。要是一一对应解决的话，成本巨大，是不现实的。而且还会有这样情况，为了对接业务满足某一需求要填一个坑，填完了却发现了又来一个坑。这也是产品设计上要考虑到的事情，在产品设计上，既能把握产品的适应性，又能控制或影响要发生的事情。当然，做到像微信那样有影响力的产品，难以想像。

关于「精简性」的分析放到下一篇文章来讲。