书接上文：
继续整理技术团队最近的年终盘点，【采用我问他答的形式】主要是聆听，这里是跟第三位同学质效负责人脱敏后的交流。
公司是两地办公，技术管理团队多是3周北京1周成都的节奏，在北京会很情况，所以多数同学不愿意过来，这位同学是公司的老同事，也是主动要求来北京，我们先来看看他一年以来自我认知的变化（美女看手相吗，我们聊聊管理玄学？）：
可以说没有什么变化，是「保持初心」的经典案例了，那么这是为什么呢，我们一起来看看。
你是什么样的人
我是一个接受「变化」的人
「变」这两个字，应该是贯穿我 2021 全年的一个关键词。
在这一年里，发生了太多的变化:
- 组织架构在变化
- 参与的业务在变化
- 在团队中的角色在不断变化
- 工作的时间和空间在变化
- 自己的视野也发生了变化。
这里首先说下业务上我做的一些事情。
业务开发
AB Test
常规的业务开发已经难以提升我们的技能，技术对业务一般来说也不会有什么感知，不过今年有变化的是产品同学一起开发了几期通过「AB test」来验证设计方案的需求还是很有意思，也收到的很好的效果。
整个业务大约持续了三期，主要针对的是用户购买的流程优化，希望通过产品上的改动来提高用户在购买流程上的便捷性，进而提升患者购药的转化率。
业务本身其实不复杂，不一样的点在于这个需求会跟数据有比较强的关联关系，如果要对比不同的方案哪个效果更好，肯定要先拿到准确的数据才能支撑最终的结论。
之前虽然我们的产品里也有埋点，但更多的是把数据记录下来，至于怎么用，其实并没有很好的方案或者体系。
调研下来虽然接入了GIO，但是却一直没有利用起来，于是正好利用这个机会好好研究了一下GIO。研究完发现，我们还真是连皮毛功能都没怎么用。
学习完GIO提供的课程再思考业务的需求，最终创建出了下面这个看板，里面包含了大约30-40张单图，有漏斗转化，也有数据对比（全图过于敏感不能放出来）：
有了数据看板，剩下的事情就简单多了，只要数据采集正常，AB方案的结果就会很直观的反映出各自的效果，最终我们也收到了很可喜的效果，复购率有明显提升：
这个事情有2个点比较有感触 ：
- 数据的魅力
数据能够直观的反映我们所做事情带来的效果是否符合预期，合理利用数据
- 有时候不是工具不够好，而是工具没用好
GIO 本身提供的功能还是比较多的，虽然我们不是尊贵的 VIP 用户，但是合理利用的话还是能够帮助我们看到很多业务上的问题和症结。
你有什么心得
Owner意识
今年组织架构进行了多次调整，自己所在团队的人数也在起起伏伏，在这个过程中，自己也一直在摸索怎么才能让团队更加凝聚，怎么才能让团队更有活力。
在下半年的时候开始让组内每一个同学都去owner一次A级以上的项目，并且要求自己只观察，不插手。
开始还有点放不开，总担心比如 xx 同学刚来，对其他部门同事不熟悉，yy 同学对某块业务不熟，可能会踩到很多坑，但其实一直这样下去，既阻碍了组内小伙伴的成长，同时自己也背负了过多的压力。
某个月底在和组内一个小伙伴做 one one的时候，问他 owner A 级项目的感受，他说最大的感受是信息量很大，关注的点也会变的很多，之前只需要管好自己的一亩三分地，owner 了以后需要对整个需求都了如指掌才能更好的管控项目的进度和质量。
其实当 owner 还有其他的好处，比如可以提高自己的大局观，会从更高的维度去观察这个需求，有时候局限在自己范围内的问题，如果能站在更高层次去寻找解法，往往能取得意想不到的效果。
OKR
今年我作为执行者和组织者共计参与了两个季度的OKR，在执行过程中，体验了OKR管理方法的完整流程，也在过程中体验了OKR是如何指导大家推进和跟踪整个项目的。
在组织过程中，从另一个视角去感受了如何协调一个组织完成OKR的规划和制定。但这2次 OKR 更多的只是有形，但是没神。
我们每次都是从下往上开始收集 OKR 的内容，经过筛选后就开始执行，其实大家并没有完全朝着一个共同的目标去前进。
我觉得 OKR 的精髓应该是帮助参与的人们目标一致，当做的事情与目标发生偏离的时候能够快速暴露并校正，这样才能发挥 OKR 的功效。
而这一切，我并不知道如何处理。
项目管理
之前做技术Owner时一直有个感受，觉得这个角色局限性很大，因为对于一个项目而言，研发和测试其实只是这个项目中的一部分环节，有些时候甚至只是一小部分，它既不是最开端，也不是最终局。
在一个项目中，限制你的因素就会很多，比如整个项目的上线时间会限制你的 deadline，但是你又没法去限制上游给你提供内容的时间（产品，UI），所以一旦遇到待排期的项目，往往下游就变的苦不堪言。
9月份的时候开始参与公司 PMO 的一部分工作，期间突然接到一个任务，需要做集团子公司 ERP 切换的项目经理，虽然之前有一些理论知识储备，但一直也没机会实战一把，正好有机会可以实战，在大致了解了项目背景后就走马上任了。
这个项目有几个挑战
- ERP 之前完全没有接触过，对项目内容本身不熟悉
- 项目干系人多为子公司的业务人员，之前完全没有打过交道，对项目成员不熟悉
- ERP 切换会有哪些风险，在不同阶段需要注意哪些内容并不清楚，这个相当于对项目流程不熟悉
- 对 ERP 中的业务不熟悉，在和厂商对接需求的过程中可能会被“忽悠”
在这个过程中有几个环节印象深刻，也学习到了很多东西：
项目延期
首先是项目延期了，项目没有按计划上线，延期了一个月。
项目延期并不代表项目是失败，因为最初「盲拍」的上线时间有问题的，这是我犯的一个大忌：
我默许了这个时间是合理的，直到进入静态数据整理阶段才发现工作量之大，就算是全员9-12-7这样工作也无法按时上线。
项目进行到这里，我发起了变更，重新梳理了项目流程以及上线时间。
好在这个项目相对独立，因此没有造成太大损失，这里得到的经验是「不要盲目信任接受到的信息」。
作为项目经理，要对项目中的关键节点负责，所以需要对所有获取到的信息进行独立思考，尽早识别项目风险并制定应对措施。
后来发现一些其他问题，比如
A 部门就是帮忙的，还有自己的业务，没法按照预期完成；
B 部门该对事情负责，但人力不足，进度肯定不能保障；
在来回拉扯后，身心俱疲，因为总有这样那样的理由等着我。
虽然我顶着项目经理的头衔，并没有很好的人脉基础，所在前期推行进度异常缓慢。此时我调整策略，由管人转变为管事：
- 任务拆解，把需要整理的数据进行分类并根据重要程度划分优先等级；在表格中体现数据整理进度，一来可以统一大家的协作模式，二来可以通过进度体现每天的工作进展是否符合预期
- 开全员大会，在会上宣讲合作模式并强调这个事情的严重性，然后在会上对所有任务进行摊派，由于子公司最大的领导也参与了会议，所以相当于每个参与的人员都当场做出了承诺
做完上面几个调整后，效果还是立竿见影。几个核心点是：
- 有一个大家都看得到的项目信息窗口
- 有良好的风险预案
- 日会todo能够落到人头上
过程中还有一个事情令我映像深刻，作为项目经理，不能一味靠妥协来维持项目的运转，需要软硬兼施，在关键的节点采取合理的方式来确保项目风险被有效控制，举个例子：
在跟乙方拉扯中，因为前期表现的过于和善，导致后来我们的需求不断被延后，资源上的安排（比如研发支持）也很不及时。
此时我意识到必须改变这种现状，于是再有一次没有得到预期解决的晚上，我愤怒的拨通了乙方总部的投诉电话，对方承诺会在第二天给我满意的答复。
结果之前申请不到的研发资源在第二天协调到位，最终赶在 deadline 前一天完成了所有调试和改造。
总体来说，ERP 切换这个项目还是有很多收获，除了点亮了项目经理实战经验这个技能外，还获取了批发业务进销存的业务知识。
小钗总结
该同学的语文水平不高，交流过程中存在不少冗余，结构也不太清晰，总结里面反思部分太少，确实没有太多认知跃升的点，算是一步一个脚印的扩展能力边界，今年我们需要想办法带给该同学认知上的改变