【详解】如何避免大数据PaaS平台建设中的这些“坑”？(2)

（2）呆在实验室的那帮家伙几乎不可能有机会接触到客户的一线维护人员的真实诉求，他们偏重开发更多的功能（意味着更多的收入），提供更强的性能（意味着碾压竞争对手），但当我们欣喜的祝贺大数据PaaS平台上线的时候，却发现自己的一线维护人员要多花1小时去配置一个接口，这到底是怎样一种体验？

一般来讲，B端的产品相对C端不是太强调体验，但笔者觉得还是要具体问题具体分析，讲不讲体验跟B端产品的性质和使用环境有关，具体可参考另一篇文章《为什么就做不好数据产品的体验？》，大数据时代讲究个机器换人，但突然发现需要更多的人去运作这台机器的时候就感觉有点荒唐了，运营运维这种隐性成本其实很高。

A公司，B公司，C公司，D公司都非常拼命，现在的产品越来越好，这对整个大数据产业其实是好事，但也得感谢下那些第一个吃螃蟹的客户，他们给予了海量数据的测试机会，抓出的BUG可谓汗牛充栋，让这些公司的产品得以迭代演化。

如果你的企业需要建设大数据PaaS，但又不想吃螃蟹，那就不要太关注合作伙伴的PPT，应该直接问，在多少企业用过？多大的数据规模？现在有多少人在用？

3、很难有合作伙伴能够兼顾到产品的短期和长期，新时期要在组织架构上进行变革

产品研发的集中化、标准化才能确保合作伙伴用最低的成本获得最高的效益，合作伙伴对于大数据PaaS往往有自己的既定演进路径，而客户的需求往往在变，特别是大数据这种正处于从概念向实用的转变中的业务，两者之间的矛盾非常突出。

主要体现在以下三点：

（1）客户提出的需求要进入合作伙伴的研发列表决策流程很长，动辄半年，很多合作伙伴提出要让自己的专家听得见一线的炮声，但也是雷声大雨点小。

（2）B端产品的商务决策流程很长，从客户一线提出需求，到项目经理汇总，再到规划部门，采购部门，信息耗损非常大，再加上合作伙伴的决策流程，到最后，一线的需求往往变了样，一线作为使用人员在整个决策流程中其实是个弱势群体。

（3）合作伙伴规划的大数据PaaS产品功能跟具体的某个客户的需求有出入，客户并不愿意为自己不需要的功能买单，现在功能捆绑销售的问题不少，合作伙伴该如何权衡？哪些该做，哪些不该做。

很多客户受不了，只能另起炉灶，好一点的做法就是搞外挂，要求开放接口，自己搞小应用，不少合作伙伴拒绝开放接口，但这是下策，另一种就是选择其他的替代品，有机会就颠覆你，由于B端产品问题的潜伏期比较长，很多合作伙伴往往浑然不知。

那么，有什么解决办法呢？

笔者近期也在跟大数据PaaS合作伙伴探讨解决方案，有两个建议：

一是必须提升本地PSO的地位，一方面要承担起一线需求对接的职责，并且拥有较强的开发能力，在研发短线支撑不了的时候，进行补位，甚至能承担部分研发的职责，比如率先实现某些功能，另一方面也能传递真实的需求到研发，驱动大数据PaaS产品的成熟，成为感知客户的”晴雨表”和双方关系的”缓冲器”。

二是研发要走大中台的路径，主要做能力沉淀、前后端解耦及开放，为PSO赋能，让其去满足前端应用开发的要求，比如A公司的数据采集平台虽然功能较多，但由于必须前台配置，导致某些轻量级的抽取场景没法用，A又不愿意开放能力，逼得客户只能走外挂。

从这里我们似乎看到了阿里“大中台，小前台”的影子，是的，合作伙伴也可以借鉴这个理念，但不要仅仅局限在技术层面，阿里在实施这个战略的时候，首先调整的是组织架构，如下图：

这是一个很有艺术的组织架构，但显然当前大多公司的研发和PSO不是这种中台和前台的关系，研发只是单纯的满足需求，没有中台，无法开放能力，更无从谈起敏捷响应，PSO更多是个配合角色，缺乏话语权。

布莱夫曼2016年出了本书《海星与蜘蛛》，说得就是去中心化的组织架构，集中的组织必须要放权，让听得见炮声的基层组织进行指挥和战斗，别老想着控制，这种手段越来越不好用了。

相关阅读：

基于大数据的用户行为预测  

山东潍坊高密：大数据技术助推政策跟踪审计取得实效  

（编辑：ASP站长网）