业务、产品、技术、团队之间的关系（业务产品篇）
2016-04-23 刘学炜（马跃） liuxuewei
想写这一系列的文章已经很久了，临离开杭州的日子已经越来越近，想在离开前把这件事了了。
今天我想聊的话题是如何理解业务、产品、技术和团队之间的关系。下面的内容是我在阿里工作的两年时间里，从别人身上所学到或亲身经历所领悟到的职业心得，希望对需要的人有所帮助。
不同的人对业务和产品的理解可能都不一样。曾经让我把我们部门的业务大图梳理整理出来，刚开始我理解的业务大图就是产品当中具体的某个流程或者具体的某个页面，例如商品详情、下单页面、订单查询页面、信息反馈页面等等，其实这样的理解是非常片面的，刚毕业的时候，我觉得只要把手头上的事情做好就行了，至于公司的规划、战略跟我们这些虾兵蟹将没有太大的关联，刚开始还好，你会觉得大公司的分工和做的事情都非常明确，你只要往某一个方向、某一个领域长期钻研，总能折腾出一点什么门道来，这也就是传说中的1万个小时理论。这个时期你会慢慢步入一个工作的舒适区，因为你对自己的工作越来越熟练，夸张的说，你甚至闭上眼睛都能写代码把一个需求给做了，可是越到后面，你会觉得你的工作越来越无聊，成长越来越慢，似乎整天都在做重复性的工作，而且是做了一遍又一遍，就跟流水线的机器一样，整天都在做机械运动，最苦恼的是，干了这么多话，到头来，可能根本就没有结果。
互联网企业是变化非常迅速的，一天一个花样，今天一个产品刚刚上线，说不定明天就要下线，更说不定，还没有发布，上级就会说有一个更加新颖、更加能够抓住用户痛点的产品要投入工作，手头上产品，就先放一放吧。企业永远是以SMART原则结果导向来考察员工的绩效的(所谓SMART原则就是指一个人的绩效指标必须是Specific具体的、Measurable可量化的、Attainable可实现的、Realistic关联的、Time-bound有期限的，具体请自行百度)，如此折腾，你有可能辛辛苦苦白白工作一年也做不出什么成绩，这也就是所谓的苦逼的“劳模”。我们要记住，在企业，永远是不会有“没有功劳也有苦劳”这样的说法的，没有功劳也有苦劳是兔子的思想，企业都追求头狼作战的方式。
阿里巴巴的价值观里面有一条，叫做拥抱变化，就是让我们以积极的态度去适应变化，但有一些变化其实并不是必然的，根源有可能是你自己咎由自取的，因为你只会埋头写代码做需求，以为这就是你的工作。这是典型的没有思考的表现。说到底，你只是把工作当成工作，而没有把工作当成事业。接到一个需求，你可能都没有思考为什么会有这个需求、为什么产品经理要用这套设计方案来解决这个问题、这样设计是否真的能够解决当前的问题？如果是你，你又会怎样设计？要思考这些问题，如果你站的角度不够高，那么你看到的东西就会比较片面，什么是片面？拿一个例子来说，你懂得考虑用户体验上的问题，交互评审的时候，会觉察出这个按钮摆放的位置不合理，例如一个商品详情页面，有个跳转到购买优惠券页面的链接或者领取优惠券的按钮，你可能会从前端的视角觉得，这个优惠券应该摆放在更显眼一点的地方，毕竟这个是吸引用户的一个利益点。这就是所谓的片面，因为你只看到了当前的这个页面，觉得这个页面才是你接下来要做的工作，至于上面的流程和下面的流程你都是可以不用关心的。这时候，你日复一日重复工作量的生活可能就由此展开了，设计师觉得这个按钮颜色需要稍微调一下、产品经理觉得现在不需要主打靠优惠券来推广下载了，这个按钮可以挪到页面底部去了，这样可以腾出更多的空间来展示商品的详情。OMG，你要疯了对不对？整天就在调整这里调整那里，代码开始慢慢的重构、哦，还有可能重写。其实从整个交易流程上来看，根本就可以不需要把购买优惠券的链路夹杂在商品详情，用户在交易的时候，直接在支付页面勾选满足条件的优惠券一起付款，不就好了吗？
不同层次的人，看问题站的高度都是不一样的，例如马总那种级别的人，都是考虑集团全球化、农村、云计算等等集团战略和让天下没有难做的生意的公司使命，让天下没有难做的生意，这句话听起来好像有点虚，但阿里人却的的确确是一直朝着这个方向走下来的，从B2B ICBU 、1688、到阿里云计算、到淘宝天猫、菜鸟网络，再到支付宝、网上银行都是为了解决大中小企业所面临的各种各样的问题，给他们提供内外贸、云计算、电商、物流、金融等服务和平台，解决他们的供应链、资金链、物流等方面遇到的问题。正是因为有这么多客户面临的问题，才衍生出各种各样的业务。说了这么多，终于绕回来说业务了，下面举一个例子来说明什么是业务，去年B2B全球峰会（详细内容请自行百度）的时候，逍遥子说B2B是阿里巴巴的一个业务，“让天下没有难做的生意”，这句话首先是在我们的B2B业务上开始起步。最早就是帮助中国的中小企业去找到全球的商业机会，把他们的商业带到全球各地。这是第一个阶段，在很长一段时间里，在整个B2B的业务上做的就是一件事情，就是通过互联网能够把原来不对称的信息进行对称，让很多的中小企业把商品的供给能力发布到网上去，让所有的全球的采购者、全国的采购者能够在网上找到这些信息，通过这些信息的撮合，最后能够形成交易，形成贸易的机会，能够形成一种稳定的商业关系。第二个阶段，也就是现在的业务发展方向，是让电子渠道的产生，网上所有的行为，都能够沉淀数据，特别是客户的数据被沉淀以后可以进行管理，然后使用这些数据，分析这些数据，给我们的生意带来增值，给我们商业带来新的机会。
所以，业务其实就是我们需要解决的客户诉求、客户问题。所以想要理解业务，就必须先要走近客户，站在客户的角度思考问题，这也就有了阿里巴巴的第一条价值观：客户第一。例如我隶属的部门B2B国际，是为了解决B类客户在进行跨国贸易过程中遇到的各种问题，其中包含信息浏览、货源、沟通、合同、支付、订单、报关、退税、金融、物流等等问题，由这些业务衍生出了流量、国际站、旺铺、询盘、RFQ、webATM、信保、PO单、PI单、信用证、一达通等等产品。再以我前一个部门来讲，城市生活事业部，是为了解决用户在商场场景下遇到的各种问题，包含消费者的优惠、排队、停车、wifi等问题和商家的员工管理、门店管理、促销活动、线上商品专柜等问题，由此就衍生了喵街元宝街、优惠券、排队等号、停车找车、一键wifi等产品。
产品是业务梳理清楚之后先做什么、再做什么，具体解决什么问题的具体策略、解决方案的实现。同一块业务的玩法有很多，不同的解决方案会衍生出不一样的产品，就拿美团、大众点评来讲，他们就算是同一类型业务的不同产品实现的典型案例。所以当我们在做产品需求的时候应该先去了解这个需求背后的本质是什么、是为了解决什么问题、为什么这么做、有没有更好的解决方案，而不是关注这个页面具体的技术实现是怎样的，这个按钮放在哪里比较好。
前面说了什么是业务和什么是产品，那么为什么我们技术人员需要去理解业务？第一，我们理解业务是为了解决前面说到的问题，面对日复一日的需求变更，由于自己没有理解清楚用户真实存在的问题，一味地埋头苦干、却不知自己所做的事情毫无价值。只有理解了业务，我们才知道自己所做的这块需求是为了解决什么问题、这个方案好不好？有没有别的方案替代？这是不是一个伪需求？是不是真的能为用户带来价值！第二点，只有当我们熟悉业务以后，才能够对需求方的具体需求做出合理的判断、梳理出需求的优先级，例如ABC三个需求，我们应该先做哪个，再做哪个，哪个需求对用户的价值最大，我们应该如何合理的去安排他们的优先级等。第三点，如果说，我们对某一块的业务本身比较关注，那么当一个需求完成上线之后，它的结果是不是正向推进业务的，能不能带来更多的用户，可以实现自身成就感、优越感，如果产品做得好，肯定也得到大家的认可，我们每个人自身当然都是希望自己的开发产品使用的人越多越好，而不是说做了一个产品，没几个人用。第四点，可以发挥自己的主动性，而不至于被动做事，被当做资源方的角色，如果你知道用户的痛点，那么你有可能能够延伸出自己的解决方案，产品经理拿过来的一个产品设计解决方案，都是站在他们的视角来看，而我们作为技术人员，肯定也会有自己的不同看法，如果能够发挥自己的主观能动性，深入去思考，拿出自己的解决方案来，肯定能产出不同的价值，这样你跟别人体现的价值也会不一样，这就是能够达到一个项目有你和没有你是不是不一样效果的鲜明对比，如果说一个项目大家都可以完成，那有你又有什么用呢？这样就体现不了你的价值。发挥主动性还体现在，自己能否把一些自己了解到的新技术，看能不能引入到项目中去，真正发挥技术的作用。例如一些新的浏览器消息推送技术等是否能够投入到新的产品当中，正向推动业务。最后一个，对我们自身发展、能力提升来说都是一种优势，由于我们更加熟悉业务、了解用户，那么我们后续的职业生涯道路会更加通畅、更加宽广，可以使劲的点也会越来越多，能够挖掘自己更多的提升空间。对于竞争来说，其实现在的新人能力会越来越强，你如何保证你自己不会被淘汰，其实技术能力占得比重会很小，还是需要通过提高别的能力来提升自己的核心竞争力，如果说，你跳不出自己的领域，那么你可能就会被下一波的人超越。
对于产品，我们前端视角应该关注什么东西才能更好的促进业务呢？第一点是用户视角的用体验，狭义的说是产品体验、例如页面导航使用是否顺畅、颜色搭配是否舒适，但广义上的体验包含更多的内容，例如服务体验，以亚马逊来说，有个人在亚马逊买了一本书，过了两三天，发现他买的书还没到，但是订单状态却发现是已签收，那他打电话给亚马逊的客服投诉，亚马逊的工作人员首先都是自身找问题，会说，不好意思，先生，可能是由于我们系统的原因导致，我们会再给你寄一本书，再过几天他真的收到了一本新书，而最后他又发现，其实他买的书其实早就已经被他老婆签收了，只是忘了告诉他，那么最后他就得到了两本书，这种体验就让他由衷的感到客户第一的服务体验。再拿国际贸易老说，出口的货物，可能是需要通过海运经过漂洋过海一两个月才能送到，那么我们的系统能不能准确的追踪到货物的情况，例如货物有没受潮、有没有别的自然灾害的风险预判等待，这就是提供贸易双方高质量体验的产品所要追求的方向。第二点，开发视角的产品形态，如何能够高效的进入开发，完成任务，这时我们可能需要将产品进行抽象，例如这个产品是偏展示型的list列表页、detail详情页还是偏动画或复杂交互型表单页面，不同业务产品形态，我们能不能抽象出统一的解决方案，这里更多的是要求我们的工程架构能力，从整体去考量，而不是单纯的把一个产品割裂成一个具体的页面，例如一达通有个FormX，就是为了解决一达通大多数的业务都是表单类型的页面，FormX可以根据文件配置自动生成表单，这样的话，就可以快速的完成负责交互的表单开发，解放人力。
好了，业务和产品先说到这里，下一篇文章讲技术和团队。