上一篇我们聊到“问题“，不管是在数据分析项目、数据平台对于”问题“的定义与优先级是工作成功的重要因素，本篇尝试继续与大家分享。
准确定义“问题”是成功的开始.什么是“问题”？如何一句话说清楚呢？ 百度-知道对于“问题“的解释是复杂而较全面的，但毛主席有句话是最简练：”问题就是事物的矛盾，哪里有没有解决的矛盾，哪里就有问题“。
例如“业务逻辑逐渐复杂与对数据平台数据模型冲击所带来的维护与更新变得更加困难“ ，这个矛盾就是业务系统的逐渐复杂化，导致数据平台数据模型复杂度更高，数据处理过程更复杂，因为复杂了维护与更新难度就提高。
有时候在“问题”的常见定义中，会出现误把方法、方案当成“问题”，把挑战当成问题,把不是问题的问题当成问题。
我们来看三个案例，看是否这三个案例对于问题的定义怎么样（案例仅作说明不展开讲）：
例如 一：“业务的多样化与复杂化加上数据架构过于陈旧，数据模型过于冗余，对数据平台的数据模型冲击带来维护与更新困难，使得数据在生产、整合到消费的链条变得超长。“
这个案例的问题定义是什么？
A回答“这里问题定义，数据平台需要重构”
B回答“这里的问题定义数据在生产、整合、消费链条过长”
C回答“这里问题定义，业务快速变化导致数据模型无法支撑业务了，需要重构”
D回答“这里的问题定义是数据平台如何通过技术手段，屏蔽业务的快速变化产生的数据对数据平台所带来的冲击，重构只是手段之一”
E回答 “我们可以在数据搜集、数据处理、模型管理、指标体系管理、代码自动化部署、元数据这些过程中构建灵活的不同模块，来评拍满足不同业务快速变化的数据平台的自动化管理、部署与变更”
以上五位同学的回答，大家认为呢，还有没有其他的呢？
案例二：如果问客户数据平台要什么，客户会说要一个能看到日常业务关键指标并能快速定位问题。
这个案例的问题定义是什么？
A回答：“快速定位问题”
B回答：“更加快速的定位问题，天级、小时级、秒级都是叫快速”
C回答：“…”
假设你作为数据的lead 该如何理解与分析这个矛与盾呢。
案例三：“客户问：我们的日志采集、ID映射关系、字段命名、统计分析口径混乱与不统一，我要上套数据治理。“
这个案例的问题定义是什么？
A回答“客户提的这些都将要解决的问题，不需要问题定义“
B回答“数据治理是一套方法论,实施好坏判别标准是什么？“
A回答“这些问题跟数据治理有什么关系？都知道问题是什么，解决上方案解决“
B回答 ”…”
C回答“不要歪楼“。
各位关注读者可以尝试自己来做分析，这三个案例中问题定义到底是什么？不同的人回答都是问题定义吗？还是已经拿着方案来当问题了。
问题的优先级、重要程度是衡量“问题“的2个维度。如下图所示，
用数据说话的角度来看，衡量问题的严重程度是有点挑战的。
现状是什么？目标是什么？ 对现状有准确的认知，问题解决后有清晰的衡量。
对于有些可以数值能衡量的状态是很容易搞清楚，目标值减去现状就是问题的严重程度。但是有一些案例是难以量化的。尤其是在数据平台，工期评估不准、实施结果期望相差很远，都是难以量化的结果造成的。
例如：“表字段分布混乱，交叉重合涉及700+表以上“ ”统计分析指标多样化，涉及到133个指标“ 这些起码是有一些清晰的衡量。
例如“数据架构过于陈旧、模型过于冗余“ 类似这样的问题很难做出严重程度的判断，如果模型架构合理的情况下，哪能节省多少ETL资源？节省多少存储？
不能确定问题严重程度就直接沉迷于架构方案的设计，当不懂时或不知道时就会度娘到很多千变一律的数据架构图胡凑一通并进入开工，只会是网上谈兵。
就先写到这里，下一小篇将进入到一个问题的案例做个分析。不知不觉已经写了有四篇，尝试想把一个分析思路背后的一些思考写出来还是满有挑战性。
ps，在写这个随笔时计划用“炼” 从第二篇改为“练”
该随笔的其它三篇 "或许连起来看更有感觉"：
我的数据是怎样炼成的 一
我的数据是怎样练成的 二
我的数据是怎样练成的 三
