认识Spark暂时不能做的事情

为什么要认识不能做的事情？

乍看之下（对着题目），你一定会认为我在胡说八道，Hadoop/Spark生态在开源社区不是如此的火爆吗？大数据公司的招聘要求不都说会Spark会优先录用吗？Spark的开发者不是很多吗？社区的贡献者不都与日俱增吗？......。

我在接收了你一系列的反问之后，估计也是会一脸的无奈，的确会有点不知所措，但是，我还是会清清嗓子，抖擞精神的告诉你，认识到Spark暂时不能做的事情也是很有必要的，而且类似的事情还有很多。毕竟Hadoop/Spark再厉害，也不能保证用了它就一定能让公司成长。

Hadoop/Spark对社会有很大的帮助，也创造了不小的价值，但是，任何类似的技术产品，都不可能独立存在，它就如同人少不了空气，植物少不了孕育它的环境一样，同样也少不了应用Spark相关产品的价值场景。因此，认识这些Spark暂时不能做的事情，反过来以价值为导向，再结合资源导向，找到利益，价值的平衡点，也不失为一种好的产品策略。因此，认识到不能做的事情，反而能反推Spark的优势，反而能更好的发挥优势。

有哪些事情？重要吗？

很多情况下，我们都可能更想去谈论Spark到底能够做什么样的产品，比如做Saas,比如做接口服务，再比如将Spark Mlib再做一层垂直领域的封装，包装成一种机器学习算法服务，靠服务来卖钱。

然而，纵观整个产品的生命周期，至少对于从技术转过来的产品经理，或者懂技术的产品经理来说，较为容易的就会发现，Spark不能做的事情也有很多。比如以下列举的几个方面。

（1）Spark相关产品的用户调研

（2）Spark生态的类似产品（竞品分析）

（3）Spark生态的开源组件，它们为什么会存在，存在的价值解决了什么问题

（4）我们接下来用Spark要解决的是什么问题

（5）用Spark解决那些人群的问题

（6）解决类似或者同样问题的竞争对手都有谁

（7）被解决问题的人群有多少，即用户市场规模的问题

（8）我们用Spark的优势在哪（与竞品对比），如研发经验，有数据积累，更有行业经验？

（9）借助Spark创造用户价值的场景是什么

总的来说，Spark擅长解决的问题，只是决定Spark最终要解决的问题的子集。使用Spark作为工具来做什么产品，依然需要深度思考，而这种深度的思考却通常只是产品经理的责任。

如果一个大数据开发工程师或者大数据分析师不换位思考，懒于从整个产品周期的时间尺度来思考，难免也可能会小瞧产品经理只会说，不会做，心理抱怨说：“you can,you do”。

与之相反的是，产品经理如果不懂技术，也会遇到一些恼人的麻烦，比如，如果你听到有产品经理和开发争辩，并且也眼见他们面红耳赤，差点就要打起架来。请不要感到不可思议。这在互联网公司，无论是to C（C:Consumer,面向最终的消费者）的业务还是to B（B:Business,面向企业）的业务，都是比较常见的。

因为，我们的重点目标是一起来围绕Spark技术的产品展开讨论，重点是如何从大数据开发，大数据分析到产品。因此，作为技术人员（首先，我是标准的技术开发），我们有必要认识Spark暂时不能做哪些事情，以便绝对有一种尊敬的心态与产品经理合作，这样的话，能够更好的和产品经理一同高效的优化产品。

3年前的我，是一个编程爱好者，近乎痴迷的那种状态，每每看了Spark的学习视频之后，按照老师的思路和布置的作业实现了功能之后，常常到朋友圈刷屏，当时是感觉很有成就感的，但是，现在回过头来看，要真正做出一款能创造价值，对用户有实际帮助的产品，肯定是远远不够的。

那么，接下来，我们按照以上提的9个话题顺序，一一来认识技术到产品的相关认知。

也就是说，产品经理如果和精通Spark大数据内存计算的你合作，他非常的优秀，你也非常的优秀，你们会如何解决以上的9个问题呢？

Spark相关产品的用户需求调研

当然，Spark肯定是可以做大数据分析的，从这个角度其实也可以作为用户调研的工具，不过，它很难帮助一个产品经理做最后的需求提取，很容易就得出一个伪需求。

如果实在要尝试用上一用Spark，那么勉强可以使用Spark的统计API做一个回归预测模型，预测满足需求与最终期望收益的关系。但往往效果并不好，首先是因为训练数据质量不高，二来数据量一般很小。即使数据量合适了，但是与其花大量的资源获取到足够的调研数据，还不如用同样多的资源做一个敏捷开发的小阶段迭代，最小可行产品的迭代成本并不一定会比收集需求调研数据的成本高。

注：最小可行产品（Minimum Viable Product，简称MVP）是一种避免开发出客户并不真正需要的产品的开发策略。该策略的基本想法是，快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。[1]

[1] What is a Minimum Viable Product? http://www.quora.com/What-is-a-Minimum-Viable-Product

用户需求调研并不简单，相反，它反而很难把握，类似于问题：先有鸡还是先有蛋的问题，难以决策，从一个角度来看，需求确实是需求，但是换个角度来看，用户的这个需求真的是用户需要的吗？需求调研者对获取到的用户反馈是否还只是停留在表面呢？结论又不一样了。它不像我们做Spark技术那样，程序出错了就是出错了，一定是某个地方的异常没有处理好，或者是哪里的分隔符大小写不分。而要找出相关的bug也是有轨迹可循。而对用户需求的把握，真的就是靠心智了，不仅要用心，还得要有足够的智慧，才能找到用户的核心需求，才能挖掘出用户的核心问题。