背景

关于需求分析和工期预估一直是老大难问题，Joel 的这篇文章谈到了这个问题，我挑一些记录下来。

客户不知道他们想要什么是问题吗？

通常，在定制项目中，最常见的超支、失败和悲剧的原因总是归结为，基本上，"客户不知道他们想要什么？”
事实上，有一件事是每个初级BA都需要在开展工作前要知道的，那就是：客户其实不知道他们想要什么。不要再期望客户知道他们想要什么。这是不可能发生的。忘掉它吧。
相反，你要假设你将不得不制造一些东西，而客户将不得不喜欢它，但他们将有一点惊喜。你必须做研究，想出一个设计，以一种愉悦的方式解决客户的问题。
设身处地为客户想想。想象一下，你决定装修你的厨房，因此，你聘请了一位专业的设计师，指示要把它弄得高大上一些。你不知道如何完成这个任务，你不知道那些事厨房中必须要装的，哪些事提升体验的，这些都不是你擅长的，你想让设计师帮你完成这个事情，这就是你雇用他的原因。
有一种办法是让客户进入房间，让他们作为开发团队的成员参与到设计过程的每一步。我认为，这有点太 "极端 "了。这就好像我的设计师在设计厨房时让我出现，并要求我对每一个小细节提供意见。这对我来说很无聊，我会觉得这个设计师对我毫无价值。
假设你的客户不知道他们想要什么。根据你对这个领域的理解，你自己设计它。如果你需要花一些时间来学习这个领域，或者你需要一个领域专家来帮助你，这很好，但软件的设计是你的工作。如果你做了领域方面的功课并创造了一个好的用户界面，客户会很高兴。

冰山理论

现在，我答应告诉你一个关于在你的软件的客户（或非技术经理）的语言和程序员的语言之间进行翻译的秘密。
你知道一座冰山有90%在水下吗？那么，大多数软件也是这样的–有一个漂亮的用户界面，需要大约10%的工作，然后90%的编程工作是在盖子下面。如果你考虑到你大约一半的时间是用来修复bug的，那么用户界面只占5%的工作。如果你把自己限制在用户界面的视觉部分，即像素，也就是你在PowerPoint中看到的东西，现在我们说的是不到1%。

Hexo 静态 blog 支持 markdown 绘制 plantuml。

安装步骤

• 进入hexo 目录
• 安装 npm install --save hexo-tag-plantuml

使用示例

简单时序图：

1
2
3
4
5
6
7

{% plantuml %}
Alice -> "Bob()" : Hello
"Bob()" -> "This is very\nlong" as Long
' You can also declare:
' "Bob()" -> Long as "This is very\nlong"
Long --> "Bob()" : ok
{% endplantuml %}

实现效果：

概述

在设计事实表的时候，和设计普通的数据库有一些差异，有以下一些注意事项：

graph LR
B(包含完整业务事实)---A(事实表设计)
C(去除多余业务事实)---A
D(分解不可加事实)---A
E(先声明粒度)---A
A---F(避免不同粒度)
A---G(保持单位一致)
A---H(处理null 值)
A---I(退化维度)

什么是事实表？

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度 和与业务过程有关的度量。

每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据。事实数据表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与纬度表中对应项的相关索引字段之外的任何数据。

事实表的三种类型

事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。

事务事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。它统计的是间隔周期内的度量统计，如历史至今、自然年至今、季度至今等等。周期快照表没有粒度的概念，取而代之的是周期+状态度量的组合，如历史至今的订单总数，其中历史至今是一个周期，订单总数是度量。

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表，比如说时间周期是1周，那么这个周期快照事实表的一条记录就是这一周的对于某个度量的统计值（我理解的）。

累积快照事实表

累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。

事务事实表中一条交易记录会每天有一条数据来记录整个交易过程；而累积快照事实表只会有一条记录，数据会一致更新直到过程结束。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

周期快照事实表记录的是重复的可预测到的时间间隔的事实，例如帐户月结余事实表，用来记录每个月末的帐户结余信息。一般周期快照的数据会按报表需要的周期进行记录，比较适合周期长一些的情况。

而累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中每个步骤的执行时间，使分析人员对执行的过程有整体的把握。周期快照事实表记录上每个步骤的执行时间是逐步建立的，随着执行的过程逐步更新的事实表中。

类型比较

数据治理实施流程，是我们依据业务数据治理标准化框架在实施解决具体数据问题时，总结抽象出来的一套适用于大多数治理场景解决问题的通用标准流程。标准流程的好处在于更加规范化数据治理工程师的操作流程，来保证实施的质量。流程一共包含5个步骤：

STEP 1：发现问题和制定目标

发现问题要从业务数据开发团队的视角出发，围绕服务好业务、遵守数据研发规范、收集好用户反馈，尽可能全地发现和收集相关需要解决的问题。同时，制定的目标要具备可实现性。

STEP 2：设计指标

针对问题进行拆解，设计可衡量的指标，并通过元数据的采集建设进行实现，用做对目标的进一步量化，并作为实施过程监控及治理抓手。

STEP 3：制定SOP并工具化

对衡量出来的具体问题，制定相关的解决SOP，并且检查相应的研发标准规范是否完善，通过问题发生的事前、事中、事后几个阶段，建设或完善相应的工具化解决问题的能力。

STEP 4：推广实施

推广运营，以拿结果为核心目标，针对不同角色运用不同策略，重点关注问题解决过程是否会与用户利益发生冲突，控制好节奏，根据问题的重要程度有规划地进行解决。

STEP 5：总结沉淀方法论

总结方法论，迭代认知，持续探索问题的最优解，优化治理方案和能力。

graph LR
subgraph Step1 
A(发现问题)-->B(制定目标)
end

subgraph Step2
B-->C(设计衡量指标)-->D(元数据及指标建设)
end

subgraph Step3
D-->E(解决方案SOP)-->F(工具化)
end

subgraph Step4
F-->G(运营治理)-->H(效果评估)
end

subgraph Step5
H-->I(方法论沉淀)
end

最近在重新看 Joel on Software 的blog，时隔二十年，很多错误还在重复发生，很有感触，比如这篇，翻译过来，引以为戒。

网景发生了什么？

网景6.0终于要进入第一个公开测试版了。实际上，从来没有5.0版本。上一个主要发布版本4.0已经发布了将近三年。在互联网世界，三年是相当长的时间。在此期间，网景无助地坐视其市场份额大幅下降。批评网景发布版本之间的等待时间如此之长似乎有点伪善。他们不是有意这么做的，对吧？其实是的。他们犯下了任何软件公司都会犯的最糟糕的战略错误：他们决定从头开始重写代码。

程序员在想什么？

程序员的内心是建筑师，当他们到达一个地方时，首先想做的事情就是将其铲平，建造一些宏伟的东西。程序员对逐步翻新、改进和种花园不感兴趣。程序员总是想要扔掉代码重新开始有一个微妙的原因。原因是他们认为旧的代码很糟糕。这里有一个有趣的观察：他们可能是错的。他们认为旧代码很糟糕的原因是基于程序设计的一个基本法则：
阅读代码比编写代码更困难。
这就是为什么代码再利用非常困难的原因。这就是为什么你团队中的每个人都喜欢用不同的函数将字符串分割成字符串数组。他们编写自己的函数，因为这比弄清楚旧函数如何工作更容易、更有趣。

这样做的问题是什么？

新代码比旧代码更好这种想法显然是荒谬的。旧代码已经被使用过了。它已经经过了测试。已经发现了许多错误，并对其进行了修复。它没有任何问题。它不会只是因为闲置在你的硬盘上而产生错误。恰恰相反，它会变得更加完善！
比如，一个程序员在分析旧代码时会说：“看一下这个函数，它有两页长！里面的这些东西都不应该放在这里！我不知道这些API调用的一半是干什么用的。“
这个API只是一个简单的用来显示窗口的函数，但它变得越来越复杂，无人知晓。其实，原因是：那些复杂的代码都是为了修复bug。一个修复了Nancy在试图在没有安装Internet Explorer的电脑上安装应用时遇到的问题。另一个修复了在低内存情况下出现的bug。还有一个修复了当这个文件在软盘上且用户在重要时刻拔出软盘时出现的bug。而那个丑陋的LoadLibrary调用，却可以让代码在旧版本的Windows 95上正常运行。
每一个bug都需要经过几周的现实世界使用才能被发现。程序员可能花了几天时间在实验室里重现bug并修复它。如果像很多bug一样，修复可能只需一行代码，甚至可能只需要几个字符，但这几个字符需要付出大量的工作和时间。
当你丢弃代码并从头开始时，你也在丢失所有那些知识、所有那些收集到的bug修复，以及多年的编程工作。

正确的做法是什么？

当程序员说他们的代码一团糟时（他们总是这么说），代码可能存在三方面问题。
首先，存在架构问题。代码的分配不正确。网络代码突然跳出自己的对话框，这些应该由UI代码处理。这些问题可以逐一解决，通过仔细地移动代码、重构、更改接口。这可以由一个程序员仔细地工作，并一次性检查他的改变，以便不会干扰其他人。即使在不丢弃现有代码的情况下，也可以进行相当大规模的架构变更。在Juno项目中，我们曾经花了几个月时间进行重新架构：只是移动代码、清理它们、创建有意义的基类，并在模块之间创建尖锐的接口。但我们以现有的代码库仔细进行，没有引入新的bug或扔掉正在工作的代码。
第二个原因是代码效率低下。据说，Netscape的渲染代码很慢。但这只影响了项目的一小部分，您可以进行优化甚至重写它。您不必重写整个项目。优化速度时，1%的工作可以让您获得99%的成果。
第三，代码可能很丑陋。我曾经参与的某个项目实际上有一种叫做FuckedString的数据类型。另一个项目开始时使用了以下划线开头的成员变量命名规则，但后来转为更标准的“m_”。因此，一半的函数以“”开头，另一半以“m”开头，看起来很丑。老实说，这种问题可以在Emacs中使用宏几分钟内解决，而不是从头开始。

总结

重要的是要记住，当你从头开始时，没有任何理由相信你会比第一次做得更好。你可能没有与原版本一起工作的相同编程团队，因此您实际上没有“更多经验”。您只会再次犯许多旧的错误，并引入一些原版本中没有的新问题。

SIKT模型原理

SIKT模型是一套梳理标签的方法。标签是用户画像的基础，是构建画像体系的砖石。想让用户画像系统有用，标签本身得是有价值的。这就要求，在做标签的时候，不能凭着数据人员的直觉，像说贯口一样把“性别、年龄”胡乱怼进系统，而是从业务场景出发，层层递进。

步骤：

1. 梳理业务场景。使用方先思考：我要解决什么问题？
2. 梳理关键指标。使用方再思考：用什么指标衡量问题解决？
3. 梳理关键行动。使用方再思考：我做什么事能解决问题？
4. 筛选有用标签。数据协助思考：用什么标签能提升行动效率。

如何进行关键行动

可以从以下行动入手：

graph LR
A(认知现状)-->B(制定策略)-->C(选择方法)-->D(监控执行)-->E(复盘效果)

什么是用户画像？

用户画像系统是一个以用户为分析对象，通过各种方法将用户信息进行展示，提供给分析人员全面、准确并具有指导意义的信息，从而优化运营的策略，提高服务效率，最终提高用户满意度。
画像系统最为核心的三个能力，分别是：

• 信息的加工生产能力
• 信息的分析展示能力
• 信息的传递能力

如何搭建画像系统？

内容产生

通过埋点及与业务系统数据集成的方式，我们需要将用户在产品中的行为进行记录上报。尽可能准确、全面的采集核心链路的数据。

创新型垄断的特点是什么呢？

在 Peter Thiel 看来，垄断往往具有四个特征：

• 1️⃣ 专有技术；
• 2️⃣ 网络效应；
• 3️⃣ 规模经济；
• 4️⃣ 品牌。

专有技术

公司需要一个优势，使得现有企业和新进入者难以复制或模仿。以谷歌的搜索算法为例，Thiel的经验法则要求技术必须比最接近的替代品“好10倍”，才能构成“真正的垄断优势”。

网络效应

网络效应使人们在更多人使用产品或服务时获得更大的价值。Facebook或LinkedIn是典型的例子。当所有朋友或同事都在现有网络上时，很难切换社交网络。

规模经济

当企业的销售和生产增长时，他们的成本每个产品会下降，这就是规模经济。Microsoft等软件公司是常见的例子。由于每次附加软件销售的边际成本非常低，因此它们享受着更高的规模经济。即使年轻的新秀拥有更优秀的产品，由于高成本和价格差异，通常也难以取代具有规模经济的大企业。

品牌

强大的品牌可以帮助创造性垄断。但品牌并不仅仅是营销和销售的结果。它需要培养、持续执行和注意细节。正如史蒂夫·乔布斯所说，有效的品牌来自于公司对质量和体验的不懈追求。一旦建立了良好的品牌，就能对创造性垄断的良性循环做出巨大贡献：更高的愿意支付、更低的交易和信息成本、更大的口碑等等。

什么是可用性？

一个产品可以被特定的用户在特定的场景中，有效、高效并且满意得达成特定目标的程度。
包括：

• 可学习性：初次接触这个设计时，用户完成基本任务的难易程度？
• 效率：用户了解了设计之后，能多快地完成任务？
• 可记忆性：当用户一段时间没有使用产品后，是否能轻松地恢复到之前的熟练程度？
• 错误：用户犯了多少错误，错误严重程度如何？用户能否从错误中轻易地复原？
• 满意度：用户对产品的主观满意度，这个设计让用户感觉如何？

什么是可用性测试？

可用性测试就是通过观察用户使用产品完成典型任务，发现产品中存在的效率与满意度相关问题的方法。