品觉导读：
- “从一开始，你就得考虑怎么保持数据整洁，否则你就麻烦了。我敢保证。”
- 提供的数据太多，用户就会不知所措，一片茫然。
- 很多数据产品的成熟都需要时间，催生出进一步改善所需的信息也需要时间
- 构建数据产品的正确切入点只有一个：弄清楚你该如何评估其表现，以及如何构建评估工具。
- 你必须投入大量的时间和精力去监控数据质量。你需要像监控网站的服务级别协议（SLA）一样。
原文翻译：
“我们说些什么，才能帮大家避免系统故障和数据损坏带来的痛苦、烦恼和熬夜工作？”
在最近召开的首轮资本（First Round）CTO峰会上，DJ帕蒂尔（DJ Patil）以此作为开场白。帕蒂尔是前RelateIQ产品副总裁，现任美国首席数据科学家，他说，若要把他走过的所有弯路和从中升华出来的所有教训总结起来，20分钟是远远不够的。和他同台的还有现任Salesforce工程副总裁鲁斯兰·贝尔金（Ruslan Belkin，随原RelatedIQ一道加入Salesforce）。他说，他们此次演讲的目标是挑最重要、最关键的误区和教训，与大家分享数据产品的构建与发布问题。
第一个常见误区，就是以为“数据产品”仅指Twitter或LinkedIn这样的应用，以为社交图谱就是一切。其实，它所囊括的产品越来越多，包括硬件、可穿戴设备等任何收集数据、帮用户理解数据的东西。对此，贝尔金和帕蒂尔给出了他们的建议，而且这些建议也适用于整个初创企业生态系统。
“一旦扩大数据产品涵盖的范围，你就会意识到，即便是内部控制面板都至关重要。你的视野瞬间开阔起来，你可以规模化地理解、制造并销售东西。”帕蒂尔说。那么对构建有用的数据产品这件事，为什么很少有公司会去讨论或强调呢？为回答这个问题，帕蒂尔引用了著名经济学教授丹·艾瑞里（DanAriely）的话：
“大数据就好比青少年性行为：所有人都把它挂在嘴边，没有人真的知道究竟，大家以为所有人都在做，于是所有人都宣称自己在做……”
说到底，规模化地构建数据产品着实不易。贝尔金和帕蒂尔分享了很多从摸爬滚打中得到的经验，很多独到的战术，便于大家创建大胆的新产品，以改变我们观察世界并与世界建立联系的方式。
数据产品的构建方式与众不同
如果只是把东西组合起来做成原型，这个过程并没有什么难度，数据产品也不例外。但规模化会带来一大堆独特的难题。你心里得有一个进度规划。这些产品从来不是一次性的或孤立的。所以你不能按以往的流程来走，它不是简单地构建、测试、发布就可以了的。
首先你要有一个基本观念：数据是极度凌乱的，数据清理永远要占去你80%的工作量。换言之，数据才是问题所在。
“比如在早年的LinkedIn，人们光是描述自己在IBM的工作经历，就有几千种不同的说法——IBM、IBM研究，软件工程师，各种缩写，诸如此类。”帕蒂尔说。
“从一开始，你就得考虑怎么保持数据整洁，否则你就麻烦了。我敢保证。”
“事后再要清理起来，至少要花上几个月的时间。”
要避免这种困境，你应该从建构简单产品着手——超级简单的东西，纯粹的计数，就比如协同过滤器，只有0和1两种数据。在规模化实施中，这一切都会变得复杂得多。“如果构建的是机器学习这种野心不小的东西，你注定要栽跟头。关键是把产品管道这些东西弄妥，在此基础之上，再慢慢构建产品。”
向用户反馈数据要切中要害
这方面的一个最佳例证还是来自LinkedIn。它有一个机制，显示最近有谁浏览过你的个人资料。促使人们一次又一次地返回该网站的，正是这类信息。
“这里有一个常见误区：你知道向用户回馈数好处多多，于是你想，‘再多回馈一些，越多越好！’但网页数据量的增加其实和点击量成反比。”帕蒂尔说，“你必须在受众中找到一个平衡点。”
提供的数据太多，用户就会不知所措，一片茫然。
决定把哪些数据呈现给用户的时候，你不仅仅要考虑到量的问题，还要考虑到它们透露出什么讯息。帕蒂尔和贝尔金考虑过向用户推荐职位，就比如“您应该申请这个职位，您的技能与之匹配！”但很快他们就意识到，这样做风险不小。
“一不小心，我们就可能推荐一位资深人士去申请某个实习职位，或者让某位证实为加州居民的用户搬到爱达荷州工作，这种情况极有可能发生。一旦发生，就会把用户惹毛，你的牌子很快就砸了，”帕蒂尔说，“你必须站在用户的视角来体验特定功能。这时候你就需要偷巧——在数据产品领域内，偷巧十有八九会胜过英明。”
在这种情况下，偷巧的解决方案就是换个角度来推荐职位。比方说有一位用户叫“比尔”。他们不直接向比尔推荐工作机会，而是引导他到自己的人脉网络，外加一条简短注释：推荐比尔申请该职位。算法还是原来的算法，只不过语句变了一下，硬相关可能造成的各种问题就迎刃而解了。
“如果一个朋友推荐比尔申请某份工作，比尔还是有可能会说，‘哦，是吗，你个混蛋。”但这种情况就比较少见了，而且他们永远不会怪到网站头上，”帕蒂尔说。“除此之外，我们还能收集这方面的数据，弄清楚这一功能的具体运转，并不断地加以完善。”
没时间尽善尽美，但有时间从头再来
这是贝尔金的口头禅，强调了“是骡子是马，拉出来溜溜”，掌握更多的情况，再加以迭代。
前段时间，LinkedIn构建了名为“人才自动匹配”的产品，目的是让企业在发布职位空缺之后，能看到适合职位描述的最佳推荐人选。一开始，效果相当不错，但进入规模化阶段，各种复杂问题就接踵而至。
“我们不得不在所有系统上迭代个遍，才找到了最完美的功能组合，以及合适的评估框架。不然大规模的构建就无从下手。”帕蒂尔说。
很多数据产品的成熟都需要时间，催生出进一步改善所需的信息也需要时间。
“这很难，就连苹果公司有时都会因为数据产品质量低劣，不得不向用户道歉，并推荐竞争对手的应用程序。”贝尔说。不论规模大小和技术水平高低，哪家公司都逃不过这个问题。
在LinkedIn，“猜您认识”这项功能最初是一名工程师笔记本上的一个大型python脚本。但一直到2008年，也就是该功能推出两年之后，它才开始对平台的壮大起到显著的推动作用。
Twitter搜索功能也是如此。一开始，它作为一项工具面向Twitter用户推出。但直到2013年年中，它才成为Twitter点击与参与度的主要驱动力之一。
“如果要推出一个复杂的产品数据，永远不要采用一个固定的时间表。”
DJ.帕蒂尔在旧金山的CTO峰会上发表演讲。
构建数据产品该从何处着手
很多人都从产品建模入手，有的从功能发现或功能设计入手，还有的一开始就构建基础设施，为结果的规模化呈现做准备。但对贝尔金来说，构建数据产品的正确切入点只有一个：弄清楚你该如何评估其表现，以及如何构建评估工具。
“迄今为止，我工作或接触过的每一家公司都无一例外地面临这个问题——数据质量差，尤其是跟踪数据，”他说，“不管是数据不完整，跟踪数据丢失，还是跟踪数据重复。”
为解决这个问题，你必须投入大量的时间和精力去监控数据质量。你需要像监控网站的服务级别协议（SLA）一样，仔细监控数据质量并做出响应。应当把数据质量缺陷作为重中之重。若发现数据质量问题，不要不敢叫停某个版本。但比尔金说，有一件事你绝对不能做：
“要是发现数据质量问题，千万不要草率地把产品提交给应用商店，”他说。“你要做的是确保自己工具齐备，跟踪的所有事件有一个扎实的架构，以及一个架构注册表，以整合到你的开发流程中去。”
为进一步强调这些教训，贝尔金在每次员工会议的开头，都要简短审视一下内部操作面板。这个面板他每天都要看20 次以上，但他发现，围绕它展开积极讨论，能让很多问题和潜在问题及时浮出水面。因此，它们还没有机会造成什么破坏，就被解决掉了。
产品发布前的核验清单
在面向用户推出数据产品之前，应该过一遍这样一份清单：
一、产品必须能正常运作
在职业生涯早期，贝尔金曾在网景公司（Metscape）工作，他记得当时的CEO吉姆·巴克斯代尔（Jim Barksdale，曾任职于联邦快递）曾说：“如果100天里面，每天有1%的包裹错过配送，那么因此而失望的客户群体就已经相当可观。”你需要考虑的是，用户看到坏结果的频率有多高？
把同样的道理应用到科技消费产品领域：“消息流中每三个月出现一次色情消息的话，用户能否接受？每六个月出现一次呢？每九个月呢？”贝尔金说。“你必须搞清楚哪个水平是可以接受的。”
如何应对令人尴尬的内容和推荐？这也是一个需要注意的问题。“不论你做得多好，出错总是在所难免。你会怎么处理？你会不会赶忙把软件滚回先前版本？你会不会跑到已经开始运转的生产系统中，修改数据库中的一条记录，试图纠正问题？你会不会从搜索索引中撤回一些东西？会不会去提升某个系统的排名，虽然它已经开始运转？以上做法通常都不太好。你应该提前预料到这方面的可能性，制定好随时可以部署的解决方案。”
二、产品必须对用户有意义
你必须站在用户的视角，审视你呈现给他们的所有东西。用户看到的信息，必须能与某些具体情况联系起来——可能是因为他们关注了某个用户，也可能是因为他们采取了某一行动，甚至可能是因为没有采取某一行动。
重要的是，如果某些数据或信息与用户毫无瓜葛，在用户与你的品牌或产品的互动历史中从未涉及到过，那最好不要呈现给用户。没人想看到无缘无故出现的东西。模棱两可会让你失去用户。
举个例子，你打开某人的Twitter主页，上面会显示此人的关注者中，有多少是你认识的人，这样，你关注此人的可能性就会大大增加。关注就成了水到渠成之事。
三、必须给用户以安全感
“我称之为泰迪熊原则，”贝尔说。“扪心自问，‘有没有任何方面让用户觉得你的产品鬼鬼祟祟或对他们不利？’事实情况不一定如此，但久而久之，用户对这些问题的感知会有损于你的平台。”
首先，你必须确保用户的个人身份信息无论如何都不会泄露。这可不是闹着玩的。总是会有这样的风险存在，它可能是由于产品设计或实施中某个缺陷。你可能会被黑客攻击。有些数据可能没有妥善加密或匿名。这些都事关重大。你必须尽一切力量防患于未然，并通过良好的设计和扎实的用户体验，让用户吃下定心丸。决定用户是否信任一个产品的，往往都是一些微乎其微的细节。
四、让用户感到一切尽在掌控
用户设置——特别是隐私设置——的呈现是非常重要的。不能让用户感到无从下手，要将选项明确呈现给他们，让他们感到自己能全盘掌控自己的隐私，如分享给谁、何时分享等。权衡再三，制定出最佳方案。用户会不会回头访问，往往就看这一点了。
五、本国以外的用户
很多美国企业竟然都没有意识到，他们的大部分用户都生活在美国以外。“按照我的经验，和你的公司有关的语言可能多达35种。通常，换成别的语言，数据和选项就会缩水。很多用户会说多种语言。如果不大量投入额外的努力，你就无法向所有用户提供同等质量的体验，除非你本来就不打算这么做。”贝尔金说。
即便你的初创企业还很小，没有足够的资源去考虑国际化，你也需要为这些问题的解决打下基础。你不能做一个纯英文的大型产品做了很久，然后有一天突然想拓展到35种语言以上。如果你拥有全球野心，就得趁早做好这方面的铺垫。
如何组织团队
贝尔金老是被问到这个问题：如果要构建并迭代的产品不止一个，产品与工程团队又该如何组建？怎样的人员配置才是合理的？
“这就不得不提到一个古老的争论：是走垂直方向呢，还是水平方向？”正确答案是哪个？
| 垂直 | 水平 | |
| 执行速度 | + | – |
| 创新 | + | – |
| 代码质量 | – | + |
| 领导满意度 | + | – |
| 复制与效率 | – | + |
| 团队间互动 | – | + |
| 团队外互动 | + | – |
“这里并不存在一个普适的正确答案，要看公司所在的阶段，不同阶段有不同的正确答案，”贝尔说：“我喜欢把它想象成一个特征矩阵，就像这样：”
“评估一下你在这些层面做得怎么样？——执行速度、创新、代码质量、用户满意度有多重要？产品的构建与规模化需要怎样的团队间互动？”
一般来说，在执行速度或创新方面，垂直整合的团队更胜一筹。大家更开心，外部关系更为融洽，因为团队跟企业的目标是一致的。
平行团队的产出质量通常更高。他们更加高效，通常团队间的互动会更好。
真正的关键是保持实验和迭代，不只是针对产品，也是针对产品构建方式。你无法一口气解决工作方式的问题。不断产生的新数据可以利用起来，重新投入到流程中去。不要指望一开始就马到成功，特别要注意的是，随着受众群体和企业规模的增长，难度是会逐级上升的。
“对于构建数据产品，我们有一个很好的比喻，”贝尔说。“它就好比是爬山。你前有古人，后有来者。有一些路是还没有人走过的，但只要有信心，一步一步地来，你一定能到达峰顶。”
转自品觉
原文：Everything We Wish We’d Known About Building DataProducts
来源：http://firstround.com/review/everything-we-wish-wed-known-about-building-data-products/
本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流，内容版权归原作者所有，如涉作品、版权和其他问题请给「我们」留言处理。
