从执行者到共创者

从执行者到共创者：我的身份认同转变与年终总结三月份接到季度OKR的时候，我还在笔记本上把“完成12次客户需求响应、项目交付合格率100%”划成了红圈重点。那时候我对自己的定位很清晰：作为产品落地环节的执行岗，我的核心价值就是把上游传递下来的需求准确落地，不出错、不延期、不打折扣就是最大的KPI。部门周会上每次讨论产品迭代方向，我总是坐在最角落的位置，手里攥着待办清单，满脑子想的都是“这个需求排到我这边的时间节点是什么，需要调用哪些资源，之前做过的同类型项目有没有可复用的模板”，至于需求本身是不是合理、有没有更优的实现路径、用户反馈里提到的痛点能不能从根源上解决，我从来没主动琢磨过——毕竟“想方案是产品经理的事，定方向是领导的事，我只要把分配到手里的事做好就行”。这种心态在四月份的一次客户复盘会上被彻底打破。那次我们给某连锁零售品牌做的会员系统上线后，客户反馈核销环节的操作逻辑特别反直觉，门店员工每次核销都要多花三倍时间，已经接到了十几起店员投诉。项目组紧急拉会复盘，产品经理说需求文档里明确写了要和总部的财务系统做对接，逻辑是按财务的要求定的；技术说开发完全是按照产品文档走的，没有改动任何流程。我作为负责项目落地实施的人，站起来汇报的第一句话是“我们的执行环节没有问题，培训材料、操作手册、现场支持都按标准流程做完了”。话刚说完，客户方的运营总监突然开口问：“你们做实施的时候，就没发现一线店员根本记不住这么复杂的步骤？你们的标准流程，有没有考虑过我们门店的人都是两班倒，培训的时候只来了一半人？”我一下子卡了壳。我当然知道这些问题，培训的时候就有好几个店员跟我抱怨过步骤太繁琐，我当时还安慰他们“习惯就好，系统都是这么设计的”，转头就把这些反馈当成了“用户适应期的正常吐槽”，既没有反馈给产品团队，也没有调整落地的方案，只是按部就班把该走的流程都走了一遍。那天散会之后，部门总监找我谈话，他没批评我执行不到位，只是问了我一个问题：“你觉得把需求做完，和把事情做成，是不是一回事？”那天晚上我翻了自己入职三年来的所有项目文档，发现几乎每一个项目的收尾报告里，我写的都是“已按需求文档完成全部落地工作，达成交付标准”，但从来没写过“项目上线后实际解决了多少问题，用户满意度是多少，有没有可以优化的空间”。我一直把自己当成生产线上的一个工人，只要把自己负责的那部分零件加工合格就万事大吉，至于零件装到整机上好不好用、能不能满足客户的需求，好像从来和我没关系。但那次复盘会的问题像一根刺扎在我心里：如果我在执行的时候多往前想一步，把一线的反馈提前传递回去，是不是整个项目的结果会完全不一样？转变是从五月份的智慧园区项目开始的。这个项目的初始需求是园区要做一套访客登记系统，产品部给的方案是在大门口装人脸识别设备，访客提前在公众号预约，刷脸进门。我拿到需求之后没有直接做落地排期，而是先花了两天时间泡在园区里，找了保安、前台、企业行政和经常来拜访的客户问了一圈，发现真实的痛点比需求文档里写的复杂得多：园区里有三栋楼，不同企业的访客需要去不同的楼层，很多访客预约的时候不知道要填具体到访的楼层，保安放行之后还要再打电话给企业确认，反而更耽误时间；还有很多来送物料、取快递的访客根本不会提前预约，每次都要现场登记，高峰期门口能排十几个人。我把这些问题整理成了一份五页的反馈报告，主动约了产品经理和园区的运营负责人开了一次需求对齐会，提出了三个调整建议：一是在预约界面增加必填的“到访楼栋和楼层”选项，预约成功后直接给访客发送对应楼栋的通行权限，不用保安二次确认；二是在门口的设备上增加临时访客登记功能，输入被访人的手机号就能直接发送申请，对方确认后就能获得临时通行码；三是给经常到访的供应商、合作方开通半年有效期的固定通行权限，不用每次都预约。一开始产品经理还担心调整需求会延误上线时间，我主动提出可以先做最小可行版本，我负责和园区方沟通测试，先上线核心功能，后续再迭代其他模块。那次项目上线后，园区门口的访客通行效率提升了70%，保安的工作量减少了一半，园区运营方专门给我们部门发了感谢信。项目复盘的时候，我第一次没有只汇报执行的流程，而是列了三张表：一张是初始需求和实际落地需求的差异对比，一张是用户反馈的问题和解决情况，还有一张是后续可以迭代的功能方向。那天部门周会上，总监特意把我的报告当成了范例，说“如果每个人都能把自己当成项目的共创者，而不是只盯着手里那点活的执行者，我们的项目成功率至少能提升30%”。身份认同的转变从来不是一瞬间的事，而是在一个个具体的项目里慢慢落地的。七月份公司启动内部数字化工具升级，要做一套跨部门的项目协同系统，一开始的需求只是把现有项目的进度、文档、审批流程搬到线上。我作为业务部门的对接人，没有只等着产品部出方案，而是拉了销售、产品、技术、运维四个部门的一线同事建了个小群，用两周时间收集了27个日常协同里的痛点：销售签完合同之后的需求经常传递不到位，产品和技术不知道客户的特殊要求；项目过程里的文档散落在各个群里，新人接手的时候要翻几百条聊天记录；审批流程经常卡在某个领导那里，没人知道进度，也不知道找谁催。我把这些痛点整理成了需求清单，和产品团队一起梳理功能框架，甚至自己画了几个核心页面的原型图。那段时间我经常下班之后和产品经理讨论功能设计到八点多，有同事开玩笑说“你现在比产品经理还关心这个系统”，我笑了笑没说话，只有我自己知道，我不是在帮别人做项目，我是在给自己做工具——这个系统上线之后，我自己的工作效率也能提升一大截。九月份系统上线测试的时候，我主动申请当第一个体验官，前前后后提了42个优化建议，其中31个都被采纳了。现在这套系统已经在全公司推广，每次看到同事们用我提的功能解决了协同的问题，那种成就感和之前我按要求完成一个项目的感觉完全不一样：之前的成就感是“我做完了一件事”，现在的成就感是“我参与做成了一件事，这件事因为我的存在变得更好了”。到下半年的时候，我已经成了部门里的“需求共创联络员”，很多项目启动的时候，大家都会主动来找我聊一线的实际情况。十一月份我们接了某制造业的智能工厂数据看板项目，客户一开始的需求是要做20个数据指标，实时展示生产线上的所有数据。我去工厂现场调研的时候，发现车间的管理人员平时根本不会盯着看板看20个指标，他们最关心的只有三个：设备故障率、良品率、产能达成率，其他指标只有出现问题的时候才会去查。我把这个情况反馈给客户的项目负责人，对方一开始还觉得“花了钱当然要做全一点”，我给他们算了一笔账：如果做20个指标，不仅开发成本要增加30%，看板的加载速度会慢2秒，而且界面太复杂，车间里的工人根本找不到重点。我们可以先做3个核心指标放在主界面，其他指标做成折叠的二级菜单，想看的时候再点进去，既满足了需求，又降低了成本，还提升了使用体验。客户最后采纳了我的方案，项目上线之后，客户的生产总监说“这个看板比之前找别的公司做的好用十倍，终于不用在一堆数据里找我要的东西了”。回头看这一年，我手里的待办清单好像没变少，甚至比以前更忙了：以前我只需要盯着自己的执行环节，现在我要从项目启动的时候就介入，要调研用户需求，要和产品团队沟通方案，要跟进上线后的反馈。但我再也没有了以前那种“干多干少一个样，干好干坏一个样”的倦怠感，因为我知道我做的每一件事都不是在给别人交差，而是在给最终的结果负责。上个月做年度绩效自评的时候，我没有像往年一样列一堆“完成了多少个项目、交付合格率多少、响应及时率多少”的执行类数据，而是写了三个我今年参与共创的项目，每个项目下面都写了“我提出了什么优化建议，解决了什么问题，带来了什么价值”。上周和刚入职的新人聊天，他说他现在很迷茫，觉得自己就是个做执行的“工具人”，不知道工作的意义在哪里。我给他看了我三月份写的待办清单，还有十二月份刚结项的那个智能工厂项目的客户感谢信，告诉他我曾经也和他一样，觉得自己的工作就是把别人安排的事做好。但其实我们从来都不是流水线上的螺丝钉，我们是每一个项目的参与者，是每一件事的共创者。当你不再把自己当成一个被动的执行者，而是主动去想“这件事要怎么才能做得更好”，主动去把自己的想法落地，你会发现你的价值从来不是由别人给你的岗位定义的，而是由你自己创造的结果定义的。这一年的转变说起来好像很简单，只是从“别人让我做什么我就做什么”变成了“我想把这件事做成什么样子”，但只有我自己知道，这个过程里我打破了多少固有的认知，跳出了多少舒适区。我不再害怕提出不同的意见，不再担心“我是不是管得太多了”，不再觉得“需求是别人定的，做得不好和我没关系”。因为我终于明白，没有任何一个完美的方案是坐在办公室里想出来的，所有好的结果都是所有参与的人一起共创出来的。我作为离用户最近、离落地环节最近的人，我的声音、我的判断、我的经验，本身就是整个项目里最有价值的部分之一。明年的OKR我已经想好了，我不会再把“完成多少个项目”当成唯一的目标，我要给自己加两个新的K