|0x00 拿结果，拿的是什么
在“中台”如火如荼发展的这些年里，“前台”过的也并不舒服。
尽管中台提供的能力在不断完善，但业务战场一日一变，仅买菜赛道，就有团购物流、即时物流、仓配物流、快递物流、分销物流等多种业务模式，在决出最终赢家之前，前台尚且不能自保，中台也无法发挥价值。
在过去，非常成熟的电商体系，在前台战场上打赢了，中台才具备了长期存在的意义。时至今日，我们可以这么讲，前台依旧是非常重要的，决定了中台的存亡。
在前台业务中，最重要的事情，就是“拿结果”。
我们往往会讲，作为团队TL，要有“建团队、拿结果”的能力。我们往往把注意力放在了前半句“建团队”，而往往忽略了后半句“拿结果”，而这个能力，才决定了我们在市场上竞争力，不仅是公司业务的竞争力，也代表个人能力的竞争力。不仅对于TL而言如此，对于一线的研发小二而言，能拿结果，相比工作很忙，更容易获得团队的认可。
那么，“拿结果”，拿的是什么？
不论是“降本提效”，还是“创造营收”，结果都代表了“价值”，也就是团队能够创造的价值。这里的团队，不仅仅代表技术团队，也代表了运营、采购、销售等职能线，技术提供竞争力，业务打赢市场竞争，是价值创造最好的体现。
对于前台的技术而言，尽管身处前台团队，但毕竟不是结果的第一负责人，因此考核绩效和评价晋升的方法，就落在了“支持业务”上。谁能够更好的支持业务，谁就有更大的发挥空间，技术是为业务服务的。
因此建立“信任”，了解自己的技术能帮助业务做什么，同时建立良好的合作关系，就是一件非常重要的事情。
尽管我们可以讲“流批一体”多么先进，可以宣讲“用户运营”的案例是如何成功，但对于业务而言， 能够提供趁手的工具，建立信任，产出结果，“支持”才是有意义的。
拿结果，拿的就是“信任”，不因为繁琐而消磨斗志，不因为艰难而选择更换赛道。
|0x01 合作方的信任感
作为一线数据的TL，是业务和数据交汇相融的地方，不仅对数据的处理技术要有熟练的掌握，对于业务的洞察同样必不可少。在很多公司的掌门人眼里，数据是一种有“魔力”的东西，认为只要有了数据，就可以解答很多非常高深的问题，比如“公司的实时利润变化”，这种情况对于数据团队而言，压力非常大，因为从掌握的数据现状上看，我们其实是不具备这个能力的，一段时间跑下来，往往只能提供一些分析深度有限的看板，不仅对于业务没有帮助，反而消耗了不少的时间来配合，那么业务就“不信任”你了。
其实我们仔细分析合作方的想法，大体可以将不满意的类型，分成两类：一类是隐形诉求；一类是业务体感。
先说隐形诉求。企业的经营决策通常是一个非常复杂的过程，比如采购，涉及到多方利益的博弈，并不是采购价格越低越好，往往要适度高价采购一些东西，否则你会发现，当你卖的好的时候，热销品因为利润太低，突然就不卖给你了。而数据的判断往往是具有确定结果的，比如采购价要低、缺货率要低，等等，很难反映利益博弈的结果。
同时，有一些想法，其实是在使用产品的过程中产生的，因为见到实物之前，没有谁能够明确自己想要什么。从研发的角度看，这就叫需求变更，但从业务的视角看，这是很正常的诉求。
因此，针对这种情况，我们就要有一种宣讲、同步机制，这并不是故意扩大影响力，而是确实有必要的。我们要讲清楚数据背后的逻辑、数据计算的口径、数据工具使用的方法，等等。尤其要讲清楚，我们能做什么、不能做什么，有一套成熟的应对方法，以解释很多情况下数据与经验有偏差的原因，并把这些差异呈现出来。如果业务能够提供一些新的思路和生产要素，我们也要积极的作为PM，来尝试这些新思路，并通过实验来找到答案，最终达成共识。
很多时候，项目工期的预留，不光是为了应对研发，也是为了预留修改的余地。
再说业务体感。
做汇报之前，往往都会有一些小插曲，比如一号位印象中为研发团队投入了不少资源，但感觉业务上好像没有什么变化；或者是某个季度非常重要的目标，却始终不见动静或者是反馈。
遇到这种情况，除了要定期进行汇报，以建立比较好的沟通渠道外，还可以从以下几个方面入手，考虑回答问题的方法。
一个是成本的节约，通常研发团队的人力成本都是一笔不菲的开支，但通过技术团队的努力，可以实现在业务高速增长、功能快速增加的同时，人力成本只需要小幅度的增加，便可以满足业务的发展。
一个是业务响应速度，部分看起来非常简单的业务，比如购物车扩容，其背后设计的是非常多个团队夜以继日的努力，这些都是竞争对手难以企及的竞争力，我们有信心跟紧业务团队，适应市场的变化，让技术迭代适应市场变化。
一个是用户体验提升，我们讨论用户体验，并不是代表销售额的增长，而是重视诸如物流发货速度、线上操作更加简便等动作，用户用产品用的更爽了，这是一种长期价值。
总之，除了学会用技术响应需求外，还需要组织起属于技术的“话术技巧”，复杂的职场环境下，“深思熟虑”的代价可能是非常非常昂贵的。前台业务是战场，你不可能在喝每一瓶水之前，都打电话验明它的真伪，大多数情况下，甚至连质保日期都不会看，因此学会如何讲故事，把一瓶水包装成百岁山的故事，别人才会有信任感去消费它。
|0x02 团队成员的信任感
前台业务，往往会被质疑“没有技术含量”，因而团队流动性会很大。
作为直接服务业务的研发，最大的优势是“贴近业务”，而最大的挑战也往往是“业务压力”。相对比中台团队，一线研发的业务Sense一定是最专业的，同时也是最难的，因为无法达到专业的层级，就很难成为业务的合作伙伴，无法真正的提供有价值的支持，从而沦落为业务的资源方。但学习业务的过程、洞察业务的变化，往往是团队成员比较排斥的，不仅是因为这跟技术毫无关系，也是因为学习另一套知识体系，需要比较高昂的成本。
同时，因为业务在最前沿，组织架构的调整也往往会非常频繁，甚至于一年多变都是常有的事情，导致与业务的合作通常不会非常持久，建立信任感的成本非常高。这种时候，仅仅只满足业务的需求，通常是一种非常不明智的选择。短时间可以进行封闭开发，但时间一久，团队变得非常疲惫，矛盾就会骤然爆发，流动性突然加大。往往到了这个时候，我们才会发现，深耕业务价值，必须是全局的视角，你会有权拒绝业务的需求，但同时又需要真正的解决业务痛点。
这些问题，对于一线研发而言，很难，对于TL而言，更难。
建立与团队的信任关系，首先是有节奏。比如我们为业务做支撑运营的工具，刚开始就没有必要直接做到可以支持大促的实时级别，可以先从T+1的离线数据看板，逐步做到T+1的离线分析看板，如果业务反馈比较不错，再进一步升级为实时数据看板，如果业务反馈一般，那么就不要投入巨大资源来做。再比如应对营销活动的临时需求支撑，刚开始要1个月的支持周期，逐步通过帮助业务梳理环节，把支撑人力下降到周级、甚至是天级。这都是一种非常不错的节奏，能够有序的推动业务发展，也可以选择性的退出低价值的业务，避免消耗彼此的信任关系。这种业务节奏的变化，便是一线同学逐步成长的过程，成就感会逐步增加。
建立与团队的信任关系，其次是融会贯通。我们非常不建议前台团队的同学钻研技术深度，而是考虑掌握大量跨学科的知识，除了本职的研发技能外，还需要掌握诸如分析、算法、产品、数据化运营等思维，并通过大量的分享与实践，来逐步的将这些技能融会贯通，提升自己解决复杂业务的工具广度。这种情况下，不论是做架构设计，还是技术选型，都会有更充分的业务理解，同学的价值会得到比较好的体现。同时，更多的知识，也为那些愿意学习的研发，提供了更广阔的发展空间。
建立与团队的信任关系，还需要与每个人交心。因为业务的变化，试图通过信息不对称来消除，是一种不现实的情况，也往往会被质疑不作为、团队乱。因此除去与业务相关的事情外，团建就是一种必不可少的事情，不光是吃饭、自己掏钱Outing，也可以组织密室逃脱、狼人杀，用年轻人自己的方式来建立私人的信任关系。常言道：“员工离职两个原因，一个是钱给的不够，一个是干的不爽”，钱的事情你做不了什么，但干的爽不爽，可选择的工具，就太多了。
|0xFF 与投诉为伍
作为前台团队，被投诉是常有的事情，不能因为太多而忽视，也不能因为委屈而暴力对抗。
我不否认，很多业务方，是很难打交道的，甚至于对方不想跟你好好打交道，只是找个可以甩锅的对象。但也有很多团队，对我们是认可的，合作起来会非常愉快，效率越来越高。
毛主席说过，所谓政治，就是把朋友搞得多多的，敌人搞得少少的。不论合作方的目的是什么，最终我们能够团结大多数的业务，就是最大的政治胜利。
因此，项目KO会议、私下约业务负责人吃饭，或者是积极响应部分业务的需求，多聊一下自己的看法和见解，都是有效的团结方法。
但也要注意自己做的一些事情，确确实实会导致投诉，这些情况通常有三种：
自己做的产品有Bug，影响了某位重量级人物的OKR；
对某些小业务不理不睬，导致小业务出现问题；
拖着一些需求长期不解决，对方考虑另起炉灶。
被投诉的原因，总结一些，大体也就是如下原因：
沟通的过程没有温度，对方感觉你态度恶劣；
沟通的结果不够高效，打字回复，对方认为你在应付；
给出的解决方案没有考虑周全，对方埋怨你没有服务好业务；
确实无法解决的需求，业务质疑你能力不行；
计划优先级已经排好了，业务只抓住多久交付一件事情死磕；
已读不回；
可以说，跟业务打交道的过程，并不是一个理性的过程，感性占据了绝大多数场景。我们埋怨前人留下了稀烂的文档，业务也埋怨技术团队都在搞毛，本质都是因为业务的混乱导致的，每个人站在不同的立场而已。
因此，从某些角度上讲，被投诉是不可避免的，要学会与投诉为伍。毕竟，现状不是一时半会可以扭转的，但我们自己的情绪可以。
网友评论