在我们所处的这个互联网时代，总有一些创想家们在试图改变着世界，让人们的生活变得更加高效，更有质量。“开放”、“拥抱”是互联网人的标签，更是产品人的特征，开放心态，拥抱变化。
9月19日，人人都是产品经理联手桔子空间举办的“woshiPM开放日“在上海五角场圆满落幕。本场活动特邀三位业界大咖同台探讨互联网的产品中的用户、设计、运营、数据等各种产品姿势（知识）。
本篇是七牛云早期技术专家、布道师。《Go 语言程序设计》译者@何李石 的现场分享实录。
何李石
七牛云存储 布道师
七牛云早期技术专家、布道师。《Go 语言程序设计》译者。6年以上互联网从业，创业经验，互联网产品基础架构解决方案专家。热爱技术，专注于服务端分布式系统开发，为开发者和互联网产品企业打造更好的企业云服务产品。
为什么面向开发者？
技术人员是懒惰的，他们宁愿花费业余时间来创造提升效率的工具也不愿一直重复劳动，当然也更愿意使用现成的提升效率的工具，前提是你这产品做的足够好，也就是有其价值。这也是出现越来越多服务开发者的细分产品的原因之一。我们的云存储产品虽然以 API 这种无界面的形式提供，但用户的体验也非常重要，其中有两点体会非常深刻：
1、体验的要素：Don’t make me think
在我们七牛的云存储产品一开始面市的时候好多人问我，你们和竞争对手相比有什么优势？那时候市场上面向开发者可用的云存储产品没有几个，很多存储领域的创业者还是在做网盘，API 对他们来说是可有可无的。因此，光从这点来看，我们就有足够的优势。存储之上，我们有一个受到几乎所有客户好评的重要功能，也就是后来被所有友商当作标配的镜像存储功能，这个功能几乎可以让大多数客户毫无成本的从任何别的地方迁移过来。
不久以后，图片社交类的产品越来越多，对图片缩放裁剪等各种处理的需求也越来越多，我们推出了一个几乎囊括了所有图片缩放裁剪需求的功能，一直用到现在（也一直在优化），后来也被友商们作为标准功能。
镜像存储和图片的灵活缩放裁剪两项功能，真正做到了“不让用户思考”，开箱即用。但是对于一家以提供 API 为产品的公司来说，Don’t make me think 的边界还是很难衡量。并不是说我提供了某项体验非常好的功能就可以让客户一直爽到底了，因为我们所提供的产品是以 API 的形式呈现的，其连续性相对没有网站或者 App 产品那么好（这点可以拿 API 的“交互”对比网站或者 App 产品的交互体验）。那么到底做到多好才算足够好呢？比如，文件的 MD5 值到底该不该我们来生成？我们到底该不该帮用户自动生成可以保证唯一性的文件名？终端用户上传完成后，回调成功的可靠性到底该由谁来保证？
对于基础架构没那么好的系统来说，你可能觉得我这里提到的几个问题都可以由用户自己来完成。比如 MD5 值可以在上传之前就算好，唯一的文件名也可以在上传之前就生成好写入数据库，而对于回调成功的可靠性保证那就更不好做到，因为每个终端用户的网络环境都是不一样的。对于图片的缩放裁剪来说，你也可以让用户在上传之前进行缩放裁剪，或者上传之后需要用的时候下载下来再缩放裁剪。但是，我们认为当客户有需要的时候进行这样操作不是一个完整甚至完美的体验，比如图片文件的缩放裁剪放在本地处理会花费终端用户或者我们客户巨大的代价。为此，我们在存储周边做了很多看似存储之外的事情，而保证基础架构良好的扩展性是应对多变需求的基石。
当然，作为技术人员，我们并不是不知道所有事情由服务提供商做了的好处，但作为实现方，我们也要考虑实现该功能的便利性和实际价值。这时候 MVP 原则就派上了用场。如果我们无法预测某项功能是否有必要开发，是否能够对体验带来提升价值，那就暂时先不实现它。客户不是上帝，他只是上帝的派生类对象。而派生类的对象具有唯一性，其“父类”上帝的共性需要我们自己去归纳和总结。
打造极致的产品和保证体验的完整性，是保证良好用户体验的两个非常重要的要素。
2、服务即体验：Don’t make me cry
对于上文的阐述，或许你有一个疑问，同样作为服务技术人员的技术人员，为什么我们会遇到无法预测某项功能是否有必要开发的情况？其实，作为互联网最基础的服务，构建在我们之上的上层服务和业务非常多，而其中大部分场景都我们都没有经历过。例如对于一款视频类的社交产品，没有类似客户之前我们都没有过类似的研发经验，不知道这里的研发会遇到什么坑。如果把我们的产品当成是由几个上传下载 API 组成的“界面”，那么我们自己对存储之外的事情就知之甚少，甚至毫无必要知道。
我们可以从客户需求中抽象出共性，然后通过满足共性需求来满足大部分客户的需求。但是对于一款产品来说，如果脱离了客户的使用场景，再好也没有意义。因此，对于一款视频社交类的 App，我们有必要去了解我们客户的用户是如何使用产品的？而他们在使用过程 App 的过程中，又是怎么样使用我们的服务的？比如在视频播放之前，是否有必要提供一些视频内的截图让用户预览？很多有版权的视频是否需要水印来保护？这些问题都涉及到对整个视频的处理。对于已经上传到七牛的视频，我们是否有必要让客户下载下去处理好之后再上传？如果这样让用户自己去折腾，那就不是一个完整的体验。我们的做法是，还是以 API 的形式提供一系列的视频处理操作，这样客户只需理解我们 API 的用法，然后根据他的业务需求做相应的操作就可以，完全不需要我们的干预。
那么，在我们对视频领域毫不熟悉的情况下，我们是如何做到准确感知客户需求的呢？答案是客户服务。
如果按已知和未知来划分我们所认识的世界，那么我们已知的部分其实很少很少，未知的部分比它多很多，而还有另一部分比例相当大的“暗物质”是我们不知道知不知道的。我们对自身产品的了解得非常的熟透，但那只是已知的很少很少一部分，而对于很大一部分在使用我们产品的客户，我们所知甚少。因此，如果闭门造车，只完成我们认为已经完成的那部分，这样打造出来的产品对客户来说可能价值有限。很多人都说乔布斯是创造需求的，实际上不是，这样的神话只会出现在不知道如何收集客户需求如何根据需求来改进产品的创业者眼中。即便是有，也是风貌菱角，非常不具有可复制性。
对于一款服务于技术人员的产品来说，研发产品或者功能的技术人员直接与客户接触有一个很大的好处，他能够理解自己的努力对于同行的价值。如果有个问题困扰了客户，造成客户方价值的损失，他可以去直接修复，这是显而易见的价值体现。对于服务方来说更重要的是，这个与客户互动的过程，是一个很好的建立认同感（或者不认同感，如果自身很糟糕的话）的过程，用好的方案解决实际问题比任何虚的关系维护都更有效。而对于服务方产品的一线研发人员来说，接触足够多的案例或者使用场景，是抽象和创新的基础。从具体场景到抽象再到具体场景，是一个螺旋式的正向循环上升过程。
说到客户服务，不得不提一下最近几年非常流行的“布道”。布道一词在过去是指对宗教的传播，以扩大受众范围，福泽天下。对于互联网公司来讲，带有客户服务性质的布道会有更广泛的含义，这个过程不止是一个把我的产品传递给你的过程，甚至也不止收集需求改进产品。和用户交流多了之后你会发现，原来你的产品有很多很多不同的使用方法（姿势），不同的用户在使用你的产品过程中也会遇到各自不同的问题。举个例子，我们有一个功能，在用户往我们这边上传完文件后回调我们客户的服务器，通过网络请求的形式通知客户方我们已经上传完文件了。这个功能在生产环境使用起来很方便，因为生成环境都有比较好的网络环境。但是客户在自己本地机器调试的时候会有一定的不方便性，我们回调的时候没法访问到他的本地机器（127.0.0.1），这时候就需要客户部署一个可被公网访问到的 API 服务来接受我们的回调请求，然而这样的操作在大多数情况下很不方便。有一次在和客户接触的过程中发现他用了一个叫做 localtunnel 的工具来给自己的机器做代理，用一种很取巧的方式让外部服务可以访问本地机器，于是我将它推荐给了后来接触到的所有需要的客户。再后来，我发现了一个以此服务为产品的公司Runscope，这项服务可以用来监控、测试以及调试你的 API，分析你 API 的进出流量。所以可以说，布道不仅是一个将你的产品或者理念单向传递给对方的过程，对方的反馈对你和你的其它客户都非常有帮助，甚至可以在这个过程中发现更多有趣的商业机会。
服务是体验的一部分，我们可以从两个维度来理解：好的服务态度和提能力是一种好的服务体验，与客户的积极接触能够帮助改进产品进而带来更好的体验。
本次活动系列文章：
如何打造一款开发者喜爱的产品
http://www.woshipm.com/pd/210441.html
我是如何在知乎做到10万粉丝的
