本次分享是打算从我个人的实践和思考中，提出在某些工作过程中，可以改善甚至避免资源化问题的例子和大家探讨。
年初我们大团队层面有过一次对现有问题的调研及总结，其中大家提的多的就是前端资源化问题，摆在了所有问题的位。本次分享是打算从我个人的实践和思考中，提出在某些工作过程中，可以改善甚至避免资源化问题的例子和大家探讨。也想抛砖引玉，引起大家对这个问题的再次重视，能在后续有更多的讨论和发声。前端资源化在某种程度上表达了前端人在业务中的主动性差、参与感弱、存在感不足、价值体现不够，合作起来往往被需求方牵着鼻子走等等现状，是前端人对自身在业务中的真实角色定位和影响力问题的综合反映。对于大部分程序员群体来说，处理因资源化带来的情绪管理危机是要比处理技术问题更加困难的，所以这也是迫切需要认识并解决资源化的重要原因。但每个人参与业务的角度和背景不同，对前端资源化也会有不同的看法，也的确不好一概而谈。但也有些经验丰富的同学已经给过总结，我们可以参考一下他们的观点，梳理出来大概就是这样的：在绝大多数业务目标中，PD是产品系统能力的主导者，后端是从底层到上层产品系统能力的实现者，而前端负责的是与用户交互的更上层，作为前端当然要懂产品，但因为岗位分工的侧重点不同，对整体系统的了解程度不如后端和PD也是正常的。因此前端起的多数是横向的资源作用，能在资源上不拖累项目进展就是绝大部分业务方对前端的要求，偏资源化是共性问题，需要正视前端作为资源的事实。业务支撑角度前端做不到主导位置，回避不了资源化的问题，但是我们可以主导其它可以带来额外业务价值的事项，即业务增值。大家也都能认可作为前端我们的价值：前端在业务增值中能发挥出PD、后端岗位所不具备的、前端岗位所独有的横向优势和用户视角优势。关于这一点，TL们也给过我们很多思路和目标，让大家从体验、从性能，让我们从用户视角出发去看自己的业务中有哪些真实用户，去看去分析这些用户有哪些待解可解的关键问题。很多时候我们能看到这些事情，也着手去做这些事情。但或是眼高手低，事情想得很多，却终没有实操性或因为各种原因中途放弃。又或是很顺利，天如人愿事情努力做完了，但仍然没有改善资源化的问题。大家有没想过这里面的问题是什么？我认为可能会是这些原因：在没有被项目组足够关注的情况下自行投入，OKR都难以对齐；为避免拉通、协同等成本，自己既当军师又当小兵，不同岗位间交流不足，项目组未必能感知，更不要说有多少人能多认同；对成本、风险、协同资源等预算问题在前期考虑不足，中期难以持续；这里大家可以检查下自己设定的与业务增值相关的OKR，看看是不是有一些项目组无感知也不关注的事项？这已经可以复现出一个岌岌可危的所谓前端主导的业务增值项目了。那根本的问题出在哪呢？我的观点列出来供大家参考：抛去用爱发电的理由，那是什么驱使我去做的？技术驱动？体验驱动？又或是自己已经具备了产品或运营能力想去跨界多迈出一步？技术驱动可以做的事：性能、延续性、可用性、稳定性等等；体验驱动可以做的事：用户运营、自服务、交互效率、交互体验等等；若他认可了我做的这件事，那么谁来认可他的所谓认可？这件事的价值是否能够互相印证？有人说只要TL认可我做这件事我就做，但我理解的是TL认可这件事更多是因为所在业务认可，是你通过在业务中的重要程度说服了TL，认可并不是凭空出现的。3.谁愿意和我一起去做这件事？有没可能实现更多价值？若他愿意和我一起做这件事，那反过来他的驱动力从哪来？他需要我 / 我能够帮助他做哪些事？这些事的价值在哪？这三个问题想通后，我们起码知道主导这件事情背后的驱动力是什么，有怎样的价值，以及共事成员的驱动力及其价值。那么我们再做事情就不再是自闭环独狼这一条路了，可以抱团去产生影响力，去反向管理项目组，为我们设定目标或贴近目标。你会发现从这一刻起自己不再是一个资源化的角色，反过来成为项目的发起者和了。而同时也会发现项目合作者们或多或少都可能会有一些资源化的影子在，就好像资源化的你我一样。这里可能会有个误区，这个是在做项目PM吗？当然不是的，这个是在完全的主导一件事，你自己是项目的主导者，而PM更多是项目的管理员，是一个执行角色，这两者还是非常不同的。前端作为一个项目发起者、和项目管理者，需要考虑到更多筹备拉通的事情，所以有一些特别需要做以及避免做的事情，我简单梳理了一下，这也包括一些TL们的看法：1.对事：对业务足够了解，了解自己坚持的核心价值点。能吸收不同角色视角的输入，如何求同存异，结合自己的思考。但也不随波逐流，不能别人说啥就是啥，没有自己的坚持，让人不信任。2.对人：需要了解每个人对协同边界的考虑、每个人对价值的衡量，他们在坚持什么目标和价值，在意的是什么，甚至还要当有人动摇的时候，如何给予他们信心，当期望值过高时，如何帮助他们降低期望等等。1.避免树立高期望目标，过度放大自己或队友的能量，让所有人都很累，没有持续性，用一锤子买卖换一地鸡毛；2.避免为了做自己觉得正确的事燃烧自己，逼迫自己或队友，等大家做了牺牲之后，事情又变成了烂摊子；3.避免让参与者用爱发电，宝贵的时间里大家都有自己想实现的价值，用爱发电意味着很容易放弃、不靠谱；接下来是一个实例，这是我今年做的一个的重点项目，在这个项目中甚至能感受到项目进行过程中，前端与后端在主导和资源的换位，以及运营与PD在业务输入输出的换位，这些非常明显的变化。做体验绝不是简单的事，对体验的改进是一件有计划、有方案的非常具有前端专业性的事情。从重要性来说，体验改进是针对所有用户的，而功能迭代往往是针对某些特定用户的，特别是成熟产品后续就更少有针对所有用户做的功能迭代。但实际做体验有多难？一旦涉及到横向协同就会非常多的阻碍：与产品功能的迭代相比，体验改进难与具体业务目标挂钩，与业务的关联程度低，结果难以衡量，难以出现在垂直于业务的PD、后端的OKR中被执行，这样只有前端和UED在用爱发电，不可持续。长此以往，前端越来越偏资源，做的事情都不是大家的重点。大家对于体验的感知也只是浮于抠抠文案改改布局这种表面问题上，这让体验改进无法有效影响业务和拿到产出，这是发生在每个前端身上非常残酷的现实，也是大家都在困扰的事情。如果这么去设置OKR去做这个项目，是很难能拿到结果的。我相信大家都会有和我一样的感受，所以结合之前提到的种种思考，我们需要去推动项目组，其中去推动做体验优化的难点是：1.产品功能迭代是绝大多数PD工作的重点，他们在意体验，但是缺少强有力理由争取高优先级去驱动他们做体验；2.后端通常有厚重的底层积累，他们对稳定性和成本更关心，很难争取后端为了体验去调整功能；3.目标认知不匹配，功能需求的落地对于PD、后端是重要的业务结果，其设置的OKR可以完全对齐业务上下游。而对前端来说只是日常支撑，做得好只是本职，在真正工作中体现不出竞争力。可主导体验内容类建设的岗位，去推后端、PD以产品功能为主要工作职责的岗位，不如去推动运营、UED这些横向的角色，更容易找到相同的价值目标从而影响其它角色。原因是运营角色相比PD，在业务中离用户更近，他偏向用户也在意体验。如果业务中没有运营，那么前端或者UED必须有一个要跨职能协同，至少在项目中做好对客分析角色。他们的需求除了来源于一部分顶层规划外，大部分都是自身或相关系统的用户诉求，产出结果可以由用户满意度来衡量，而用户满意度通常又是工单量、咨询量这些直观的指标，比较好量化。目标确定后，需要把主导角色明确出来，在过程中也顺带将风险摊开来：体验驱动类的工作，可由前端、UED、运营去主导；为什么这么做？主导权不是功利，而是为了达成业务目标所需要的不同岗位职责，作用是负业务责任和把控执行方向，去做拆分可以让相应优势的角色负起应有的责任。这里会让后端或PD产生不适感，因为体验驱动这部分工作，可能在惯用使用产品功能去解决问题的同学眼中，认为解决不了具体问题，面临这种质疑，这里建议我们也至少需要做到两点：我们在这次改版中找了能代表不同场景的多位用户参与到体验改版的过程管理中，他们留下的体验感想是非常重要的，既能够说服大家，也能够给我们信心和动力。我们在改版中分析了很多工单，暴露了很多用户视角对功能问题的反馈，这些作为体验改版中的产出，也能为第二波功能类优化的工作提供非常有价值的输入；我的建议是，在横向岗位主导的体验优化项目中，不能强依赖后端开发做高成本投入，否则容易出现：“后端同学搞某个更重要产品功能去了，暂时没时间投入，这个要不先放一放吧？”原因很简单也非常能够理解，资源总是容易流失到更加重要的项目中，横向推动的项目管理一但出现风险，可能就直接面临失败，一但失败后续再想发起就没这么容易了。好不容易拉起来的队伍，重新建立信任关系、应对各方挑战的成本太高。在这个项目中，我给自己的要求是除了项目产生的业务价值外，还要让每个参与的角色都有自己坚持的信念以及想要的收益，宁愿不做也要拒绝用爱发电：对于UED，通过这个项目可以找到他从开始就一直在坚持的设计价值，而且这个项目提供了数据和目标支撑，让他的坚持更加有说服力；对于运营，可以通过这个项目让他走得更远做得更多，完全可以达到甚至超越由PD推进的产品功能改进所产生的业务价值，这对于运营和PD在同一个团队良性竞争的现状来说，这也是他所需要的；对于前端，我们通过这个项目可以找到前端驱动项目组增值业务的可复用的通用方法论，增强在项目中前端的参与感、存在感。可以经历整个从筹备到拉通实施的过程，跨过项目和管理者门槛，更进一步成为其它项目的发起者、和管理者。原文链接：https://mp.weixin.qq.com/s/tbtnw_sPUrTLvsrLsCmyrw
