2.3 怎样做到的——理解技术

在前两节中，我们了解了如何找到数据产品要解决的业务问题，以及如何通过理解业务更好地理解数据产品究竟在“做什么”。

在本节中，笔者开始关注数据产品搭建的另一个重要关注点——这也是数据产品经理的另一个能力板块——技术系统。之所以要特别地关注这个部分，是因为数据产品相对于业务产品，是一个“技术密集型”的细分领域——很多应用和产品形态上的挑战，最终会转化为技术上的挑战，而不像业务系统那样，更多地转化为对设计者的行业经验和想象力的挑战。

因此，我们首先要理解的是技术系统“究竟能做些什么”。在这部分中，笔者探索的是技术系统的“能力边界”，并会提出一些常见的挑战。针对这些挑战，笔者会在后续的章节中给出目前已经成型的解决方案。对这方面的了解，将会帮助我们在搭建数据产品的过程中，不会逾越这条“能力底线”，以至于设计出一些“根本不可能实现的方案”。

其次，在基本能力之上，笔者开始关注效率提升的问题。也就是做同样的事，如何使耗费更小；或者在同样耗费的情况下，如何做更多的事情。这种效率提升将来源于三个方面：绝对资源的补充、技术能力的提升和对业务的深入理解。其中技术能力的提升和对业务的深入理解是笔者主要探讨的内容，第一方面对大多数情况来说，在客观上做不到。

2.3.1 理解“究竟能做些什么”

技术系统究竟能做什么？这是一个很有趣的问题。在各种关于产品经理的社区和问答平台上，最常见的问题就是“数据产品经理是否需要懂技术”。相信这样的问题能够受到广泛关注，是有现实基础的。

笔者在讲解与业务相关的内容时提到，技术创新是业务创新的基础。业务上的突飞猛进，常常伴随着技术上的重大革新；技术上的停滞不前，必定限制了业务的想象空间。我们在追求业务拓展的同时，很容易就触及了技术系统的能力边界。

因此，产品经理是否一定要懂技术，这个没有绝对的答案，但是懂一些技术上的基本逻辑，一定对大家理解技术系统的能力边界很有帮助。笔者接下来就来探讨一些关于理解技术系统能做什么的问题。

1.从严谨的逻辑开始

“严谨的逻辑”是技术世界的敲门砖。任何含糊、无法清晰而准确地描述的内容，都无法直接让技术系统来实现。大家在实际的工作中就会对这个问题有比较深刻的理解，只不过身边的案例都是一些个别的案例，不太容易举出一些普遍适用的案例。关于这一点，各位产品和运营人员，在与研发人员进行沟通的过程中，能够比较明显地体会到。

在具备了基本的逻辑思维之后，我们要开始攻克第一道难题。许多想要学习技术的产品和运营人员，经常会面临这样的状况：拿起一本与技术相关的书准备好好研读一下，结果从第一页开始就看不懂——不是似懂非懂，而是根本就不知道在讲些什么，又没有人能够提供帮助，最后只好放弃了。

为了避免这样的状况发生，我们先将目光放在业务与技术的“交点”上。一方面，我们要研究的是业务需要从技术系统中得到怎样的信息反馈，以及以什么形式反馈才能最大限度地支撑业务的正常运转，这是从业务到技术的视角。另一方面，我们也需要关注技术系统为了提供这些反馈，需要从业务系统那里获得怎样的信息支持，这就是从技术到业务的视角了。

关于如何从业务领域的内容和思维过渡到技术领域，笔者在第6章中会特别介绍。

2.数据量问题

通过视角的转变，我们大概了解了技术系统“在做什么”。现在回到本书的主题，我们要关注的是使用数据产品来提高公司和团队的数据应用效率。如今应用效率低下的一个主要原因就是数据量越来越大。更麻烦的是，不仅数据量大，而且数据的表现形式越来越多，从简单的数字，到稍微复杂一点儿的文字，再到更加复杂的图片、声音、视频，乃至VR和AR等。

正因为要处理的内容变得越来越多、越来越复杂了，我们就需要将它们分类。从数据分析的角度，可以将数据分为定性数据和定量数据两种。这两种数据分别有自己的处理逻辑和应用方法。

随着数据的表现形式越来越多，关于数据处理的需求也变得丰富多样。为了高效地满足这些层出不穷的新需求，我们同样需要对这些需求进行分类。对于不同类型的需求，我们需要权衡应当通过怎样的方案来实现需求。简单来说，常见的方案只有两种，即通用方案和定制方案。

通用方案是那些实现一次之后，几乎不用再投入成本就能够满足所有相关需求的方案，这是我们希望看到的情况。如果真有这样一款产品，在几乎不改变什么的情况下，就能满足大多数需求，那么这也标志着产品本身的成熟，乃至整个行业逐渐走向了成熟的阶段。

但总有一些需求是使用通用方案满足不了的。因此，还会有一些情况需要一些临时性的、针对性很强的方案来解决，这就是所谓的定制方案。从业务角度来说，定制方案能达到最理想的“PMF”（Product-Market Fit，产品-市场匹配）。这是一个最近被频繁提及的概念，并且具有预见性。但是，从业务角度思考的需求在实现这种理想状态的同时，却忽略了定制方案本身隐含的高成本。

针对这样的问题，如果将思考的时间拉长，我们不仅仅希望眼前的、现阶段的产品能够实现PMF的理想状态，还希望今后任何阶段的产品都能高效地达到PMF的理想状态。在这种长周期的思考方式下，我们就会发现，通过定制方案来实现PMF需要投入相当高的成本，包括人力资源、技术资源、时间和资金成本等。因此，如果希望在更长的时间周期上实现PMF的理想状态，我们依然要通过不断优化通用方案的途径来实现。

3.计算效率问题

随着数据量和数据表现形式的增加，一个直接产生的问题就是计算效率问题——我们很快就会发现，用原来的办法，不能在规定的时间内得到想要的结果。当然，这种压力不仅来源于技术实现的层面，也来源于需求的层面——人们想要了解的东西越来越多，会不断有新的、更复杂也更具挑战性的数据计算需求产生。

从最开始的统计数据，到复杂一点儿的统计模型，再到规模更大但对延迟的容忍度反而下降的推荐场景，这些新出现的场景都给技术实现上的计算效率提出了挑战。不过，人们总是凭借自己的聪明才智，一次又一次地发现了既能够完成任务、又能够尽快得到计算结果的方法。

当然，从企业资源的分配角度看，随着数据越来越受重视，企业管理方面也愿意在与数据相关的软硬件资源方面投入更多的成本，这为我们搭建数据产品提供了良好的支持，让我们能够不断应对各种复杂的挑战。

当然，只说这些“空话”没有任何意义。在本书的第6章和第8章中，笔者就来详细地讨论关于实现和提高计算效率的问题。这其中包括业务上的数据如何更高效地存储到计算机系统里、通过怎样的处理逻辑能让海量数据的计算更加高效、现有的技术方案和技术框架又如何对海量数据进行处理等。通过这些探讨，希望各位“非技术背景”的读者，能够对技术方案的基本逻辑有一个比较清晰的了解。

4.元数据管理问题

在本章第2节中笔者讨论了数据的意义，接下来笔者就要讲解如何通过技术系统将这些“意义”管理起来。这部分工作可以归入“元数据管理”。

首先笔者来介绍“元数据”（Metadata）。通常大家看到的关于“元数据”的解释是“元数据是关于数据的数据”。这个定义总结得太简练而无法让人理解。

如果要深入理解“元数据”的定义，我们需要结合业务数据库与数据仓库之间的设计差异，以及纵表与宽表在理念和特性上的区别，来考虑查询效率的问题。这是比较偏向技术的理解，其实我们可以通过一些简单的具体场景来理解“元数据”。

比如，在通常的产品设计中，我们都会给用户设定编号，并且要求每位用户在一款产品当中拥有唯一的编号，甚至在同一家企业的多款产品中都拥有唯一的编号。这样做的理由很充分，我们希望以最简单的方式能够在任何时候唯一地找到一位用户。不管是在更新或查询用户信息的时候，还是在后续分析用户相关数据的时候，这种“唯一性”都至关重要。

应该怎样做到这种“唯一性”呢？用户的姓名可能重复，其他信息就更容易重复了，再加上我们在初始阶段不可能直接获得像用户的身份证号这种比较私密的信息。因此，就只好人为地给用户赋予一个编号。但是问题又出现了，这个唯一的编号是如何生成的呢？

在技术实现上，这样的编号通常是系统自动给用户生成的。它可以是一串数字，也可以是一个包括数字、字母与特殊符号的组合。如果我们从交互上考虑，以前的PC平台和现在的部分H5页面，当用户注册的时候，需要用户自己输入“用户名”，并以此作为用户的唯一标识。

不过，随着更多的功能从PC的场景转向移动的场景，手机号的作用变得越来越大。因此，目前更常见的一种方式是让新用户通过填写手机号注册。随着社交平台的兴起，这些社交平台成为更多新产品的“新用户来源”，如“使用微信登录”“使用微博登录”等。在这种场景下，社交平台用户的唯一编号就“变相”地被新产品采用了。同时为了自身发展，新产品通常也会单独再给用户做一个编号，并且基于自己的这个编号来构建数据体系。

既然一个简单的编号可以唯一地代表一位用户，那么我们就不需要在产品的任何地方都“带着”用户的各种信息了，如姓名、手机号、地理位置等。这些信息只有在需要的时候才可以通过用户的编号查询得到，在其他时候，我们只需要使用用户的唯一编号来代表用户就可以。

但是在分析场景中，我们处处希望通过用户的各种信息来找规律。比如，来自某个地区的用户的消费水平特别高，或者处在某个年龄段的用户经常使用某种产品。因此，在数据分析的过程中，我们希望处处能得到与用户相关的各种信息。对这些用户信息的维护，就可以归入用户的“元数据管理”的范畴。

在归类上，这些用户信息的维护可以归类为业务上的元数据管理。类似的管理，还有与渠道相关的说明和备忘、与运营活动相关的目的和计划等。虽然，从感性上理解，这些信息对业务的正常运转的影响通常都不太大，但是如果缺失了这些数据，我们一定没办法做好数据分析。

除了业务上的元数据管理，另一类就是技术上的元数据管理了。比如，一些数据的业务含义、字段含义、数据表之间的“血缘关系”、技术文档和操作指南等。与业务层面的元数据不同，技术层面的一些元数据如果缺失了，整个系统可能直接瘫痪。一旦我们发现技术系统出现问题，想要去追查原因的时候，就需要这些元数据的帮助，否则排查工作根本无法开展，这就类似于我们做业务层面的数据分析工作。

5.数据安全问题

最后，笔者来讲数据安全。随着数据的价值越来越广泛地获得认可，人们也开始越来越重视与数据安全相关的问题。

数据安全是一个很有趣的话题。当大家逐渐深入理解了与数据安全相关的思考方式和现有的技术实现时，就会发现其中的魅力。其实，同“数据产品是为了提高数据应用的效率”一样，数据安全也跟“效率”相关。

本书毕竟不是一本专门讲解数据安全的书，所以笔者只是介绍一些数据安全方面的常见做法。至于像“数据备份”这种偏向底层的维护数据安全的手段，在实际工作中主要由研发人员完成。因此在这里，笔者要介绍三种关于数据安全控制的手段，其目的是为了防止数据泄露。

1）别人看不到最安全

这种方法是容易想到的一种保证数据安全的思路，就是“只给对的人看对的东西”。比如，大家要给用户设立账户和访问口令（Password），在数据内容上增加权限控制机制并授权给特定的用户，甚至采用更偏向技术层面的做法——用逻辑或物理上的“隔离”来实现数据安全。

这些做法的共同特点是，只让一部分人看到数据，并且只能看到那些他们“应该”看到的数据，并不能看到其他更多的数据。通过这种方式，就实现了“数据安全控制”。

2）别人看不懂也安全

这种方法就增加了一些复杂度。第一种方法只对数据的访问设计了控制机制。但是如果有人通过“种种手段”绕过了控制机制并获得了数据，那么依然能够轻松地了解数据的内容。

因此，我们要对数据本身做一些操作，让那些受保护的数据，即使被人恶意获取了，也无法被理解，这些操作就是我们经常听到的“数据加密”。在数据加密的情况下，数据平时都以“被加密”的状态存在，只有主动执行解密过程，数据才会被解密，变回原来的样子。

相对于第一种方法，加密的方法是施加给数据本身的一种安全措施，能够跟随数据“移动”。因此，在安全性上比第一种方法更强。只不过，加密和解密都需要额外的计算量，也需要考虑加密算法和解密算法的计算效率问题。

3）在有限时间内无法破译也安全

加密的做法听上去已经很安全了，但是加密也做不到100%安全。

首先，如果在加密和解密的过程中有人的参与，那么至少人要记住那些用于加密和解密的信息，或者将其妥善地记录在某个地方，才能顺利完成加密和解密的操作，否则整个机制就瘫痪了。其次，用于加密的信息有的简单，有的复杂。如果信息过于简单，那么只要提供足够的时间和其他资源，总能够“猜”出用于解密的信息。这就是所谓的“暴力破解”。

不仅加密，上文中通过设立账户和访问口令的方式来控制访问的方法，也会出现类似的情况。平时我们都是靠自己的大脑来记忆账户和访问口令的，因此它们决不能特别复杂，并且一定存在着某种规律性。比如，与我们的个人信息有关，与我们使用的键盘键位或者其他身边的东西有关。

如果别人坚持要“暴力破解”，我们没有办法避免，能采取的措施也就是限制尝试的次数，但这本身也很容易被突破。因此，人们想到了另一种方法，这种方法与“效率”有关。这种方法的核心思想是尽管通过多次尝试，访问口令和加密密钥之类的东西确实会被其他人“猜”到，但是我们可以增加访问口令或加密密钥的复杂度，这样能够有效地延长“猜”这个过程所需要的时间和资源。只要让需要的时间和资源的量达到一个“不可能实现”的量级，那么数据就是安全的。

比如，如果访问口令可以设置为一串异常复杂的字符组合，其中包括了数字字符、英语字母和常用的标点符号等。同时，这个字符组合的长度也足够长，可以长达十几位甚至几十位。如果用最“简单粗暴”的办法——“穷举法”来猜测这一串字符，可能需要几十年甚至上百年的时间。这样，虽然不能保证这一串字符100%安全，但是至少这个“猜”需要的时间已经能让我们安心了。

其实我们并不需要让这个时间或者资源的量无限地增加下去，这样有时候也会给自己造成麻烦。

之所以关注数据安全，是因为数据蕴含了某种可利用的价值。但是，随着时间的推移，大多数的数据都会逐渐失去其价值，这就是“数据的时效性”。一旦失去了时效性，数据也就变得没有利用价值了。因此，我们需要做的其实不是让这个“猜”的时间周期无限延长，而是只要让它比数据的时效性周期要长就可以了。

在本书第6章中，笔者会详细介绍关于数据安全的定义，以及控制数据安全的常见思路和几种可落地的控制方法。

2.3.2 思考“怎样做得更高效”

笔者从“效率”的角度出发，给出了数据产品的定义。因此，关于“效率”的观念，会贯穿全书。在上文中笔者跨越了从业务层面到技术层面的边界，开始考虑为了支撑业务层面的数据应用诉求，大家在技术层面能够做些什么。

接下来，我们在确定了要做的事情之后，就又需要考虑效率的问题了。当我们想要通过系统的方式来实现业务的某种诉求时，都会产生一定的成本。这些成本可能是抽象的计算资源、存储资源等，也可能是比较具体的电力、资金，还包括一些风险和未来潜在的维护成本等。同时，我们也通过技术系统的支撑，帮助业务创造了价值，包括金钱收入、品牌认知、社会影响力等。

可见，我们在考虑技术方案的时候，依旧从投入和产出两个方面来考虑。这意味着当我们接到了许多诉求需要满足，或者有许多备选技术方案时，因为团队的资源有限，我们要做出明智的取舍。

因此，2.3.2节的内容与之前的内容稍有不同，区别主要在于思考的角度改变了。笔者在之前讨论的内容大多从满足需求的角度出发，讨论如何对需求进行评价和衡量，以及如何对现实中的问题进行思考。而在2.3.2节中，笔者站在系统搭建和数据生产的角度，来考虑为了产品和团队的发展，我们应当思考哪些内容，以及如何思考。

1.技术投入与业务产出的关系

我们首先要考虑的就是业务价值的最大化。数据产品以“提高数据应用的效率”来定义。而在实际工作中，效率中的产出部分大多来自业务层面。这其中包括业务实际赚取的收入，以及业务实现的市场规模扩大、用户规模扩大等。业务自身的发展，几乎是一家企业或者一个团队从外部获得价值的唯一途径。

因此，在分配团队中有限的资源时，我们经常要考虑，一项工作究竟会给业务带来哪些价值。通过这种价值来“反推”，确定不同的技术研发和数据生产工作的优先级，以及其他需要取舍的问题。

这些价值主要包括五个方面，即创造收入、节省时间、节省人力、降低风险和沉淀资产。我们在对技术方案和数据需求进行取舍的过程中，同样通过以上这五个方面来衡量技术方案与数据需求背后的业务价值究竟有多大，并以此来评估其优先级和团队内部的资源分配。

2.寻找业务价值突破口

同时，我们在搭建数据产品的过程中，不能总是“被动地”对业务的价值进行评估再做出选择，也可以“主动出击”——在设计和搭建产品的过程中主动把控产出的价值。

要达到这个目的，我们可以从以下两方面考虑，分别对应了投入和产出两部分。

1）更高效的技术支持

为了让搭建出来的数据产品能够创造出更多业务价值，我们首先应当考虑的还是自己要“练好内功”。假设业务诉求已经比较稳定，也比较清晰了，我们就需要不断迭代满足需求的方式。

要“练好内功”，我们可以考虑在覆盖范围、支撑时效、内容丰富性等方面做突破。

在覆盖范围方面，我们需要考虑的是，现有的技术方案是否可以“横向拓展”到其他领域，让其他业务也获得数据方面的便利，提高数据应用的效率。

有些业务看上去很好，但数据应用方案无法落地，我们自己也可以梳理一下，找出无法落地的原因。常见的原因主要是数据准备不齐，或者仍然存在某些问题导致达不到可以直接实现数据支撑的程度。之后，即使现阶段我们无法直接利用现有方案支撑业务，但如果一项业务的确有价值，我们也可以针对现有的问题进行时间和资源的安排。

在支撑时效方面，主要表现为性能的优化。比如，原来由于能够处理的数据量有限，相同的时间段内只能处理很少的数据量。这种状态反映到产品的用户体验当中，很可能就是“稍微操作一下，就要开始等待加载，并且需要等很长时间”。同时，服务器资源也极其有限。我们需要选择那些能够给用户带来更好体验的资源分配方案。

最后，在内容丰富性方面，我们需要对现有的技术方案不断迭代，以便能够支持更丰富的内容。比如，原来我们在做内容推荐的时候，可能只考虑了对文字性内容的推荐，但是现在增加了图片推荐、视频推荐、直播推荐等。这些新形态要在更多方面考虑特征维护和用户匹配的问题，并且这已经成为未来的发展大趋势，我们需要在数据支撑方面做到“未雨绸缪”，提前做好数据分析的相关准备。

这两年，更多新的线上社交方式层出不穷。而我们要做的，就是针对这些发展趋势，加强自身的分析和技术能力，实现以更低廉的成本支撑业务运转与实现发展的目标。

2）寻求更高的业务价值

除了对已经“塞到手里”的需求进行业务价值的评估，我们还可以主动寻找那些高价值的业务，并不断与它们保持信息同步，在必要时帮助那些高价值的业务或部门做数据应用方面的支撑。

根据数据产品自身的特点，要寻求价值更高的业务或者数据需求，通常要注意以下两个方面。

首先，要注意的是“一次性”的数据需求。这种需求在数据分析工作中并不少见。需求方可能对一个研究方向拿不准，或者其他什么原因，总之想通过数据分析的方式来验证，甚至连验证的方法都准备好了，只需要人力来“做一下”。这样的需求并不能说它没有价值，至少通过验证我们能规避一些资源浪费的风险。不过，这样的需求对数据产品迭代和工作流程优化的价值就比较小了，每次需求之间的相关性也很小。

因此，为了打磨数据、优化数据分析工作流程和数据模型，我们应当更多关注那些不断有后续工作要做的所谓“长期持续型项目”。这种项目的价值就在于，它给了我们不断提高自己的机会。

其次，要适当“瞄准”那些更容易创造业务价值的部门。在通常情况下，除非直接将数据产品出售，或者绑定其他服务一起出售，否则数据产品这种偏向企业或团队内部的产品，比较缺乏机会来创造出“显而易见”的价值。而通过与那些更容易创造价值的部门合作，也更容易通过对方的指标对我们自己的工作价值进行量化评价。

比如，搭建一个数据平台，大家就可以直接以需求方创造的价值来评估自己的工作，也可以将需求方创造的价值作为搭建这个数据平台的重要产出。因此，在其他一切条件都不分高下的情况下，或者在最开始思考产品发展路线的时候，应当优先选择“更接近价值”的部门。