1，用户和客户
用户不一定是客户。比如家长给孩子买玩具。谁是客户？谁是用户？这就要看玩具给谁用，孩子玩玩具，家长只是买，并不玩，所以很明显，家长是客户，孩子是用户。
用户：使用者
客户：付费者、购买者，是代理人和中间人，将产品与使用者关联起来。
2, “怎样卖梳子给和尚”。
如果我们将梳子视为产品，那么将和尚定义为用户，就不容易完成推广。但是如果和尚只是客户，或者直接看做中间人的话，或许就能找到突破口了，这就是一种找到解决方案的思维框架，比如将梳子用作寺庙上香的回馈开光平安梳之类的。
明确了用户和客户的差异之后，我们就不难理解为什么很多时候公司采购的系统或者软件那么难用——因为做决定的人或许根本就不用……那么，如果放在我们的话题上，我们的数据需求，其『用户』不一定是『客户』。
3,以用户为中心，还是以客户为中心
4,需求是什么
需求的本质，对用户来说，目标和现状之间存在差距，想要消除这个差距，就会产生需求。
所以，我们为了理解需求，首先要知道什么是目标，什么是现状。但是，需求方，比如我们的业务人员，或者很多上司，在他们的需求表述中，不一定直接表达了这两个重要因素。这种情况下，一旦没有思考这次要做的事情，说不定就掉到坑里了。
举个例子：一只帅气的大猩猩，他说想要飞起来，让你帮他。
这个如果作为任务去处理的话，我们或许就是做一个飞行器，一个竹蜻蜓，或者做了个火箭之类的，这样猩猩就飞起来了。（消失在天际）
然后，可能就惹猩猩不高兴，接着就挨揍了。为啥呢？这就涉及用户提出需求的一个很常见的点：
他提出的不一定是需求，甚至往往是**『他以为的』解决方案**。而这个**『他以为的解决方案』，既没有表达出现状，又没有说清楚目标，这种时候我们盲目去完成『他以为的解决方案』**的时候，往往并不能解决他的问题。
也就是说，回到刚才的案例中，如果我们去问一下这位猩猩先生，这位giegie，您为什么要飞呢？他可能说，啊，老夫要飞起来去那个树上摘香蕉吃。这样调查之后，我们知道，哦，原来目标是摘香蕉吃，而现状不是不能飞，而是吃不到。也有可能他说，我想要飞起来显得帅气，这样可以帮我追猩猩妹子。
这样我们的解决方案就可以从做飞行器，调整为帮他解决吃香蕉的问题了（或者是变得帅气，从而追妹子），不仅方法会变得多起来，而且成效也更容易保证。
再一个就是非常经典的案例：用户说想要更快的马，实际上他想要更快到达目的地，所以，可以提供更快的车来满足他的需求。
这在需求分析中，叫做『Want』和『Need』。
这些看似简单的小问题其实在工作中经常遇到。比如前不久，我在和营销人员沟通的时候，他们就说给数据提出的取数需求，等到结果跑出来了，才发现少了一列，结果耽误事了。如果这种情况，数据团队真的去了解业务人员拿这些数据想要解决什么问题的话，说不定这个事情就可以避免。
5,HTTPS证书认证
基于CA根证书签名的客户端身份认证方式
