四个多月的时间里，数据产品带给了我什么（下）
破釜沉舟，柳暗花明，用来形容我当时的状态太恰当不过了。没有谁能打包票，做事顺风顺水。也没有谁甘心，心血付之东流。唯有不顾一切地坚持下去，问心无愧。
说明：通过上篇、中篇的分享，收到不少的共鸣声音，谢谢大家喜欢我的故事。这里也针对大家反馈的典型问题，解释一下。
问题一、有朋友认为中篇所暴露的产品问题——比如推动困难，缺乏资源等。这些都是小公司的病，大公司基本不会存在。
我说两点：
- 我们公司成立快5年了，最高员工数1w+，由于业务调整，目前7k+，应该在某些方面跨入了大公司范畴了
- 其实这位朋友说的也没错，但我认为忽视了本源。大数据还是一个创新产业，类似BAT这样的公司也都是探索了很多年，轮换了好几批先驱者，甘当人梯，才逐渐找到大数据的价值，公司才肯花更多钱投入。而对于业务占主导的公司，对于大数据还处于观望，试探阶段。人力财力的投入肯定极其有限，毕竟投资回报率很低。每一个先驱者都是这样度过的。——何况咋们八路军曾经还小米加步枪的配置打过仗。
问题二，有几个朋友留言说，这个系列反映的现象，就是他目前在部门内所遇到的困惑——资源、业务方向和产品创新。他也很困惑。
我也说两点：
- 很高兴能够找到有同样共鸣声音的朋友，你们都是大数据领域的先驱者。这些问题肯定是会遇到，毋庸置疑，希望你们能够坚持下去。
- 在建议上，一方面，尽快招纳大数据部门的核心岗位人员，不在于多，而在于能够做实事。满口大忽悠，做事难产的，避而远之；另一方面，多和业务走近些，熟悉业务，找到交流的共同点，从而寻找一些能优化业务相关的大数据工作。优先服务于业务，再找到数据产品的立足点。
问题三，有朋友认真读完了我的前两篇文章，看懂了我做的产品能成功的核心关键——沟通，很高兴能有读懂的朋友。
对于做开发的朋友，我经常会听到这样的无奈，“感叹自己整天面对屏幕，极少的与同事沟通，与业务沟通，与领导沟通，恐惧自己情商越来越低”。
很多时候，工作的困难不在于技术难易。你目前项目用的技术点，至少在外界，甚至开源，都已经不再是新东西。况且真的是新领域，至少可行性上是评估过的。工作的困难我认为在于沟通协作的方式：
- 如何去跨部门合作，别人心甘情愿为你部门项目添砖添瓦？
- 如何在部门内协作、克服和团结去做项目，让每个人力量聚在一起？
- 如何正确和领导沟通项目过程中的困难和进度，让领导成为你的资源？
我自己也做开发，我同样也跑业务。因为理解这样的无奈，所以我只说心里话。并不是强调每个人非得去这样做，只是给有这样无奈的朋友一个建议。况且乐忠于开发也挺好的，还有什么比自己快乐更重要呢？
十一、挽救
2016年，9月中下旬，一切并没有想象中的那么糟。
当天晚上和幻影沟通后(幻影是后面叫上一起做产品的java前后端工程师)，我在当晚就做出了调整。
一方面，我必须站出来，承担这样一个角色，引导着项目成员一起走出困境，把产品推动起来；另一方面，调整我以往的工作方式，让自己动起来，在产品的每个困难点寻找突破。
思前想后，当下最应该做的就是让产品后端服务通起来，我应该做这两件事：
和周瑜确定Spark Streaming水龙头的数据源，一方面想办法让测试阶段有水能流进来；一方面让他推动着其他部门在理财端各个渠道的数据埋点开发，保障产品上线的进度和数据稳定性测试。
跨部门推动，让影帝加把劲填上以前产品后端开发埋下的坑和未完成的功能。同时尽快让幻影接手影帝的工作，逐渐让产品的后端功能开发回归部门内部。
说做就做，第二天早上，我找到了周瑜，和他沟通了数据源的问题。
很巧的是，周瑜说：“以前已经开发上线的借款端数据，表结构和数据类型基本一致，完全可以把借款的业务数据先拿来做测试。”
我觉得靠谱：“这样的话，就能保证整个后端数据流程的顺利，顺便测试后端功能的反欺诈校验流程、数据传输稳定性和效率优化问题。”
经过多次反复沟通，我让周瑜尽快完成两件事，推动一件事：
- 完成对接后端校验流程，完成数据的实时传输，以json格式，同时保证传输的稳定性测试。
- 完成对接大数据离线平台，跑P开发用户核心特征的行为数据，接入反欺诈系统涉及的业务模型中，保证用户全渠道数据的整合。
推动跨部门，尽早完成理财端数据的埋点功能。
解决数据源这个困难，接下来就是叫上幻影，一起亲自去找影帝，跨部门推动项目后端开发进度了。
当时还是遇到几个隐约的小困难，影帝经常性的人不在，大部分时间在开会。
好不容易撞上了，他却告诉我：“我目前主导负责别的一个项目，脱不开身啊。”
幻影没底气交接工作了，我俩一起回到部门，找个窗台坐下。幻影抓了抓头，问我觉得这问题能不能解决，11月初没几个星期了。
我说你要有点信心：“这个问题看似短时间难以解决，但其实有突破的点。而且这个问题压根就不算问题。”
幻影有些没听明白：“为什么这么说呢？”
我说因为这基本是跨部门协作项目，都会存在的现象：
- 对接人的确并发做多件事，导致协作时不走心；
- 项目的归属感，毕竟是帮别人做事，短期内并不会对自己工作成果起太大帮助。
对于跨部门合作这事上，我们掌握两个核心点就可以了：
积极性，大部分人都是乐意在工作中寻找成就感，你的积极性也会感染协助你的同事，能够就你们之间对接的工作去不断优化，达到相互满意的状态。
给予反馈，懂得去感谢别人的付出，肯定别人的工作。能够用请客犒劳解决的问题都不是问题，如果不行，那就是再请一次。
幻影有点质疑：“是骡子是马拉出来遛遛！”
我让他等着瞧，准备好作战准备。
后面一周的时间，我基本是往影帝工位上跑(一天都能跑好几次)，优化一些开发完成的bug，新增个别的功能点。最重要是，对于一些核心业务点，都是喊着幻影跟着一起，尽快的把影帝手里的工作接手过来。肯定别人付出的同时，也让别人能够尽快脱身，专注做他主导负责的项目。
找到问题的关键，用正确的方式去处理，大家都能高兴，何乐而不为呢？
通过10多天时间的挽救，产品在后端功能的坑逐渐填补上了。影帝也成功脱身了，幻影也能够把产品前后端的功能接手过来了。
2016年，9月30号这天。
在国庆节前期，周五那天，我、幻影和周瑜推迟了下班时间，终于把产品后端的功能服务跑通了，虽然和产品的落地还差得远，但至少又能看到一丝丝希望，那种感觉真好。
窗外一角
十二、沟通
做数据产品，页面是不可缺少的，一方面是供运营人员好推广使用，一方面高层领导要实际能够看到这段时间所做的事。
2016年，10月8号，国庆回来。
我和领导单独沟通了下，决定全力以赴把时间花在页面上了，保证11月初能够给运营部门，领导看一版上线的产品。
这算是军令状了，虽然整个产品的大部分核心页面都还未规划，以及产品数据传输的稳定性还有待调整，甚至UED和前端跨部门对接也保不准会出现什么岔子?但是我敢答应，是因为我心里有底，我认为No Problem!
当天，我梳理了下整个产品在前端页面遇到的困难点，以及确定了相应的解决方法：
- 特殊性 ：同样对于跨部门之间的协作，但是这次是有差异性，毕竟UED和前端属于服务性部门，他们主要的工作也就是协作跨部门之间产品的页面开发。并不像影帝对接的特殊性——纯帮忙。
- 原因点 ：对于UED和前端的协作，导致整个产品页面进度开发慢，只有两个原因，缺乏沟通和推动，一味把原型丢给别人，只想着某个时间点得到成果，显然是不切合实际的。
- 解决点 ：唯有沟通，增加沟通的成本，降低复工的成本，反而能够提高整个产品的开发效率。
所以接下来三周内，我特别忙，到处跑，就像红楼梦里的王熙凤，什么事都要管，而且都要保证不出岔子。
我当时采用了看似最笨的方法，却是不可避免的方法，也反而是效率最高的方法——一对一，去把控产品的业务功能，去推动产品进度。
截止目前，总共开发了8个页面，除了常规统计页面、自定义配置页面，还有两个有创新的功能页面。基本都是用这套方法，效果显著。
沟通一：产品原型规划
在开发前期已规划好的页面同时，我都会做大量调研和竞品分析工作，确定整个数据产品闭环流程上都会需要哪些页面功能点(不缺少，也不让产品整体显得笨重)，提前思考后端功能实现的可行性和页面交互的效果，最后规划设计页面。
这里面有几个核心点：功能可行性和必要性，以及页面展示和交互的确定。一定要有把握，一定要方便和UED、前端的对接。时间成本耗不起。
沟通二：对接UED
在把原型交给UED做设计的同时，不可掉以轻心。不要委婉，要如实表明项目紧急程度，以及评估页面的难易程度确定时间点，更重要是把页面的展示表达明了，充分利用她们的专业性去润色很多细节。
百度百科对UED的介绍
考虑到我自己也很喜欢设计，所以在UED做页面的时间里，我都会亲自和她们一起讨论，确定颜色、布局、大小屏幕考虑，交互效果以及需要她们发挥专业性的设计点。如果这些都确定一遍了，我才能安心下来。
当时，我们在做一个比较有意思的页面功能——用户关系网络分析，它类似百度的关系图谱，但是也有很大的差异性和实用性。
百度知识图谱
简单来说，这个功能是分析平台所有用户之间的关联性，找到恶意的某些用户是否存在大批量操作多个用户账号。
从原理上，把用户之间的关系定义为强关联、中等关联、弱关联和无关联。就比如两个用户都使用同一个身份证，或者银行卡，那这两个人之间肯定是强关联。倘若检测到多个用户使用同一个IP地址，那只能说明有一定的弱关联性，因为保不准是同一个公司的员工呢?
斯科特·斯特莱登，TED大会新锐演讲者
我们当时考虑了6个方面的维度去分析用户的关联度，根据具体维度贡献的关联强弱，有差异权重值大小，最后确定一个阈值，计算用户与全用户之间的关联度强弱排序。
后端功能原理和幻影讨论了许久，最终确定模型的输出以json格式来对接。但是对于前端的页面展示和线条交互效果，我们有很高的期待，但是我自己只能勾勒一个轮廓出来。
没办法，我后面单独找到了UED表述了很久我的想法，感觉都快绕晕了。
我很欣赏做UED这些同事，有创造性。结果到最后，都能收到比较满意的设计效果，很棒!做工作就是需要有创造性，而不是照搬原样。而且还能充分利用她们的专业性，让大家协作工作能够有成就感。
这种愉快的协作方式，基本能够保证一天出一个页面，最困难也不超过两天。
沟通三：前端
如果你在UED这块做的工作足够，对于后面前端的对接，就方面明了很多。保证几点就足够了，交互效果，一些特效说明，以及叮嘱考虑页面屏幕自适应，至于浏览器兼容都是他们专业性会考虑的问题。
又是一个快速致富的职业
当时和金总对接时（前端同事），比较喜欢他的一个特点——强迫症，做工作的确需要强迫症，不断追求完美。而我需要做的就是充分调动金总的积极性，尽情让他畅快的发挥自己的强迫症，让页面细节更人性化。
和做设计和前端的同事对接起来让人很舒服。对于我而言，一种认真执着态度是我不可缺少的，只有这样才能真真切切感染到他们，让每个人能够在项目中找到成就感，提高页面开发的效率。
于他们而言，作为服务性部门，被别人认可，做的产品页面得到领导肯定是让他们欣慰的点。所以对于我来说，每次辛苦劳累以后，我基本都自然而然的请客，感谢工作的支持。对于每次从领导那里得到的肯定，我都会及时反馈给他们，给予他们心底的认可。
工作没有高低之分，也没有谁一定要服务于别人。大家愉快轻松的工作，找到工作中的成就感才是最重要。
沟通四：对接Java Web
在这样一对一的推动下，整个项目的效率提高不少，复工的可能性更小，所以对于java web这块的开发，基本能保证原型不超过3天，就能够把工作推动到幻影这里。
在对接幻影时，是整个推动过程中最关键的，因为业务性质，一不留神，也许做开发就会把某个业务做错了，写了一堆代码，到最后，推倒重来，这很影响情绪的，甚至影响整个产品开发的效率。
我特别理解一些做开发的比较反感产品经理，主要是一部分产品经理尽是瞎扯，一大堆天马行空的东西，导致一次又一次的推翻重来，甚至是实现不了。而做开发的同事，也不太善于合理的反馈沟通，有气也憋在心里。互相闹得不愉快，整个产品也开发不下去——鱼死网破。
产品经理高频次修改需求为了降低幻影的工作量，我当时是这样和他说的：“基本涉及业务方面的表结构都是由我来设计，整个数据这块的逻辑计算和数据同步都是由我来支持。”
幻影说这样最好了。
产品设计前期都会和幻影沟通业务逻辑实现的可行性。所以他的工作量得到大幅度降低，只需考虑页面和数据库功能的交互。
最关键是，我基本都是坐在他旁边陪他一起写代码，在核心业务逻辑上给他解释清楚，所以开发效率挺快。
但毕竟他也不是专职做java web这块的，很多实现也没做过，遇到了好几次卡壳。而对于我来说，我要做的事，就是和他一起想办法，甚至是寻找资源，帮助他解决开发上遇到的困难。
有几次，幻影在做图形echarts插件时候，遇到一连串的问题，文档也看不懂，和我反馈开发不下去了。
我毕竟也不是做这块的，但是也不需要我真正切切懂这块，我能做的，就是给他找资源去解决这事。
对于前端的问题，有不清楚的，我替他联系了我的朋友，一行代码一个方法的指导如何去实现。
对于后端实现工作，我也联系我另一个朋友，那朋友直接抛给我开发完的代码，又算是解决了。
其实那一段开发的日子挺值得怀恋的，能够做一些有意义的事，有困难一起想办法去解决，完成了，一起吃着零食喝着饮料庆祝。(工作在这样的状态，是很多人都向往的。——想着当初和我的队友，三个人放弃几个暑假、寒假的时间，待在实验室一起为了数学建模比赛一起奋斗的日子，足矣!)
通过一对一的对接，把控着每一个环节的流程，我们高效的完成了一个又一个页面，而且一次又一次的迭代优化让产品体验更好。离真正的上线发布的时间越来越近，我们更有把握能够按时完成。
如果总结能够如此顺利的原因，我列举了以下三点：
- 有足够一对一的沟通，推动着产品的前进，把控着产品的每个环节，降低复工的时间成本。
- 整个项目小组营造出一种积极正能量的一面，没有别的想法，大家一股脑只想看到产品的落地。
- 我必须要提前做好工作，熟透整个产品开发环节中的每个细节，让大家做正确的事，而不是一头雾水。
十三、上线和推广
整个羊毛党反欺诈产品在11月初面向公司内部的运营部门推广，也给CTO和共同做同一件事的别的部门看了。
这里需要说明一点，当初和我们一同做类似产品的其他部门，他们也在并发做同一件事，算是竞争也勉强吧。他们是单独成立的一个子公司，也单独招了一些开发人员、设计师、前端和产品经理来做这事，但是唯独没有大数据，甚至是做过数据产品的人。
这或许是他们到最后没有做出来的核心原因，用传统的方式来解决大数据场景肯定是会遇到很大困难。他们后面也解散了一部分人，具体也不清楚，还合并一起完善我们的数据产品了。
在我规划的整个数据产品的功能范围内，还有一个最核心的点还没有做——与线上产品的业务流程接入。这才是数据产品真正的价值核心。
不过我清楚，现在还没这么着急，首当其冲的问题，是要让产品推广出去，在业务层面上先运营好数据产品。
当时和领导也是这样沟通的，“现在整个产品的功能点的面基本闭环了，也满足很多的业务场景功能，现在最重要的事： 一是继续优化产品的功能，以及数据稳定性和准确性；二是从业务层面上，运营好产品，让业务推动产品的更深入完善，以及实用。 至于后阶段的线上业务产品的流程接入，我认为是水到渠成的事。”
领导认可了我说的这番话，所以我们接下来做了两场比较正式的培训。
一次是针对同样做类似产品的其他部门同事。
给他们培训的目的在于和他们交流，寻找融合进我们产品的一些功能点，共同完善我们产品。
做完培训以后，他们也很肯定我们做的工作，说是他们看的类似竞品里面，做的很优秀的产品。还单独问我，“整个产品花了多少时间，有多少开发人员”。结果都比他们的人力和时间成本少很多。
一次是针对运营部门的很多同事，也包括运营的领导。
我讲解起来也变得更有底气，畅快淋漓把产品流程的每一个细节和创意亮点进行了说明，从他们的眼神里，我收获了认可。
但这并不是单独做这次培训的目的，我是想通过这次培训，正式推动产品的运营，让他们接入更多业务场景去推动产品的不断完善。
他们后面过来的产品经理和我做了业务上面的更多交流(也是我上篇文章中耐撕的那位产品经理)。的确，他说的一些业务场景对我们接下来的运营很关键，也认同接入更多业务场景去推动产品的更上一步。
结尾语
说到现在，整个文章基本算接近尾声了，在质疑和困境中，我们坚持到了最后，我也算完成了几年前的一个梦想——做一款有自己特色的大数据产品。
我很高兴，做事也很卖力，这段日子会是我工作到现在，最值得回忆的时光，我很欣慰自己能够有幸，有这个缘分遇到这样一个机会——一个让我成长起来的宝贵机会。
而回到文章的主题——这四个多月时间里，数据产品带给了我什么呢？我想会有以下三点：
- 一种感动，一份经历
- 学会沟通，学会管理
- 一种期待，对未来大数据发展的一种向往
足矣，足矣……
路漫漫其修远兮，吾将上下而求索……
作者：汪榕
本文来源于@36大数据，作者@汪榕
关键字：产品经理, 产品
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
