一直希望有时间进行回顾和整理一下最近几年的工作经历，刚刚好五一期间，不用外出，就静下心来进行梳理，也算给自己三年来做个小结。这三年来的经历，真可谓是丰富多彩，虽然有遇到了很多挫折，也时常感到无力，但是从个人能力成长方面，还是有不少的收获。既然有收获，就做一次系统性的复盘，反思问题，下次遇到同类问题可以做得更好，并且给到其他新同学整理一些结构化的经验，如踩过的坑，所做过的选择，将过程中自己浅显的思考进行总结。不管怎样，希望能对后面新同学有些许启发作用吧。
整体来看，这三年多以来，自己的运气还是不错的，一开始跟的项目也比较稳定，一开始也得到了信任，亲身经历了从前端到后台，从UI设计到数据逻辑闭环，仿佛亲身经历了一整套极其复杂的系统。说其复杂，其实是站在历史角度来看，随着人员和版本的更替，各种逻辑相互交替，逻辑相悖。说其复杂，也是业务方向不够明确，自身经验无法覆盖，都是在摸着石头过河，前面还相对孤单。因此，围绕着顶层抽象设计->业务模块设计->具体功能设计->持续迭代打磨的过程，进行一次系统性的复盘，相信每一位亲身负责过一个版本迭代的同学，都整个流程有比较深的理解。这过程中充满了挑战和挣扎，本人运气好，碰巧遇到一些靠谱的自研同学，好的领导，从他们身上得到反馈，不断学习如何进行业务抽象，快速理解业务逻辑，也跟着公司的发展情况，不断摸索如何做多方协作横向项目的管理工作。
第一：先从项目背景明确问题点
我们从事的项目是泰国项目，面对泰国的政治，经济，技术，文化，都得深入地了解，才能做得更深入。然而碰巧这几年疫情期间，全球经济萎靡，泰国当然也不能幸免，甚至更差。再加上国内业务在不断出海，整体的竞争越来越大，这就是项目的残酷背景。鉴于此，我们如何通过数据来识别问题，提升效率，指导决策，如何整合上下游的资源，通过系统的联动，提高迭代效率，提高项目转化效率，显得格外紧迫。然而我们公司这些年来，在这方面积累的方法论不多，可以说没有比较好的应对经验，可以说每一个问题都是第一次遇到，，只能不断的适应和优化。主要问题点如下：
人员流动较多，需要大量的沟通
业务逻辑复杂，专业知识积累不够，大多数在执行成员的脑子里，需要通过沟通获取
版本周期过长，功能过多，不够敏捷
参与角色众多，但是负责人不明确，诉求差异较大
协作方经验和能力参差不齐，异常考验沟通协作能力
多数情况下产品不是真实用户，同理心很困难
第二：从问题点出发塑造能力模型
鉴于这些问题，从事情本身抽象出来，这几年下来我自己深刻的体会到，产品运营的自身能力提升是关键，特别是在当下我们公司现状情况。所以结合公司给到的一些进阶资料，我自己进行了内化，简单整理出产品运营的能力模型，进行了抽象总结，同时也多次提交给组内同学进行查阅，提供给大家成长路径。如下所示：
通用能力：
学习能力：
互联网有大量的知识需要学习，学科包括数理知识，设计知识，心理学知识，甚至政治哲学等，如何快速学习掌握关键知识，结合过往经验，发挥价值是关键，在此声明不是什么都需要学习，而是在用到的时候，能快速的检索出来，这些和平时我们大量的阅读，好奇心，爱琢磨等有比较强的关系。
执行能力
执行能力是比较基础的能力，在协作环境相对复杂的项目中，执行力体现在扛着压力争取将资源效率最大化，将事情干成，难点在跨团队合作上面，这个和自身的耐受力有比较大的关系。
沟通能力
很多时候，搞定人是最重要的。特别是创业公司，先搞定人，讲人情比较重要。发展时公司讲究奖惩，大公司最后重制度。所以如何在创业公司跨团队协作的时候，在复杂环境下表达清楚自己的诉求，这个是比较基础能力。公司多次要求大家多聚一起讨论，多一起吃饭，也是基于这个出发，先熟悉相关方再解决问题。
ownership
版本负责人和产品负责人就是ownership角色，因为如果自身都不关心自己负责的产品，相互推脱，私下摸鱼，基本就没有人站出来解决问题了，所以这个角色必须明确。出问题，谁负责最终责任，明确到每一位相关方头上。
版本管理
在还没有PMO横向拉起所有团队预期之前，优先级和产品设计都依赖着产品经理，包括版本的管理，这个难点在拉齐所有版本相关方的认知。认知不在同一个层面上，无法做好版本的管理，因为需求方不一致，一开始方向就错了。
技术实现
针对技术实现，大量的配置化设计，各种功能模块的解耦，基于规则聚合实现复杂性的业务逻辑。这个时候产品经理在一定程度上要了解技术实现逻辑，数据流转逻辑，数据合规逻辑，产品文档不止要做业务流程图，还要做时序图，甚至还要对数据入参出参进行定义。只有这个，产品设计方案才是完整的，当然过程中需要研发的配合，近几个月来从数数平台搭建方面Spencer整理的需求上体现感受得比较强烈。
同理心
产品经理本身可以是用户，但是不可能覆盖到全部的用户，特别是坐在办公室进行设计，是很难做到和实际用户同理心的，所以务必深入到作业一线，看大量的用户反馈等，才能知道用户需要什么，担心什么，遇到什么，这一块明显能感受到我们没有做到位，还需更加努力，主要是认同。
专业能力：
工具使用
原型制作工具，数据采集和分析工具，数据分析工具等，实际工作中需要使用的工具，数据量大的时候还需要MySQL，Python等
产品设计能力
拿到一个需求和一个项目后，如何去进行设计解决方案的能力，因为业务流程一般都很复杂，可能涉及到多个功能系统的联动，所以对产品方案的设计能力要求较高。这部分设计更多是在各种资源限制下的解决方案限制，简单来说，在当前的人力资源允许情况下，如何将需求目的做到最优解，效益最大化。
产品抽象能力
同一个需求，同一个节点可能衍生出非常多的分支需求，所以需要高度抽象同类的需求，只有高度的抽象，才能做好配置化的设计。从设计之初就考虑到后续的复杂性和扩展性，这样才能降低后续开发的难度。这个抽象的前提是对业务的深刻理解和熟悉，对系统的底层逻辑的掌控。
业务分析能力
这个对每一位版本负责人都有比较严格的要求，在我们的需求筹备过程中，我们会收到来自各方的需求，我们不能直接拿来使用。而是需要对业务做细致的拆解，理清楚需求目的，才能提交给到开发。因为其他同学提的需求，可能仅仅站在他的角度，甚至影响到其他的系统功能。
用户与竞品研究能力
我们一般感受到的竞品体验是看其他游戏怎么设计的，我们照着抄。其实背后的逻辑我们是不清楚的，所以我们必须要对目标设计去抽象，找到设计的本质是什么，然后通过这个本质去设计参考，谁说我们游戏后台系统不能参考电商后台管理系统呢，所以尽可能的找到相关设计体系，去获得一些意想不到的启发，深度体验才是最重要的。
协作方管理能力
整合管理，进度管理，质量管理，成本管理，沟通管理，相关方管理，风险管理，资源管理，老板预期管理等，都要学会去协调
管理能力：
人才培养
从管理角度看，人才培养极其重要，只有找到靠谱的人，放到对的位置上，管理者才能释放出精力去完成架构设计和服务抽象。否则每个需求都跟进，永远做不出，这就要求尽快拉升跟进同学的能力了，否则一堆bug后期还是得管理者跟进。
知识传承
某个功能点会做持续的迭代和优化，这些长期下来，如果对应的员工离职了，很多知识点就丢失了。后续有新的需求点需要联动优化，就需要找开发从代码层面去推导逻辑，非常痛苦。这个最好在需求管理层面上面直接做好，放在树状结构中维护，确保产品知识的传承性。
方法论建设
每个产品经理在工作过程中都会不断的积累自己的经验，阅读大量的图书，这个过程中经过抽象加工后就成为了自己的方法论，如果将这个方法论放在团队范围内分享，肯定会对整体同学能力有所提升。降低后续协作的成本，毕竟认知已经通过分享，拉到同一水平了。
项目管理能力
从管理角度看，项目要做好分级，每个管理者或多或少都管理着几个项目，如果做好工作协调管理等一系列动作，保证各个项目按时，按质，按量上线，管理者负有不可推卸的责任，包括后期的核心任务效果反馈
第三：执行方面苦口婆心经验之谈
第一个：保持敬畏的心，信息的全面性和真实性
很多同学都只知道干活，从来不去思考为什么这么干，为什么会有这个需求，顶层设计是什么，核心逻辑支撑点是什么，这样逐渐工作越来也没有激情，失去动了，变为了工具人。
要想了解明白，尽可能获取更多的信息，真的深入了解各方的需求，理解到真实诉求，只有想清楚这些，才能有全局观，才能让真正的需求落地，才能最终让知识点产生福利效应。
刚刚进公司的时候，我负责的模块就是负责9K的运营，那时候我发现无从下手，只能去结构游戏的每一个功能，从后台经济数据分析开始，然后构建整体业务版本的全局视野，在后续的横向项目中的作用，帮助很大，动脑子干活很重要，这也是在近期我不断要求大家对后台数据分析下重功夫的原因，而不是为了分析而分析。
第二个：保持敬畏的心，信息的全面性和真实性
还记得刚刚开始跟进9K项目的时候，针对相互添加这个功能才成为好友，改为主要关注就能成为好友。这个后面改完后，很多用户反馈自己一直被跟随骚扰，后面甚至将这个功能改了不下3遍。
后来才知道，这个功能之前改过一次，就是将关注改为相互关注，后面又被我改回去了。所以，刚刚加入一个公司或者团队，要了解公司，项目演进的过程，是如何一步步走到现在的，需要我们去识别真假需求。给新同学提个醒，对信息敏感，掌握了多少信息，就掌握了多少话语权，因为真实有效的信息，可以辅助做出正确的决策。每个人表达的信息都有自己的偏见，也隐藏着更深的诉求，要有自己的判断，多想多问，既有助于快速融入团队，也有助于完善认知地图。别急着设计解决方案和改变，先获取更多的信息，否则很容易无头苍蝇般横冲直撞，最终将自己的信誉度减低。
实际上，当前看到的所有不合理，大概率都是各方利益进行博弈之后的结果，如可能因为行为惯性存在不合理的点，但一定有其合理性。如果一个人完全不熟悉其演化过程，刚刚进来就掀桌子，推倒重来，结果也很可能差强人意。不要把其他人当傻子，要对业务和当前的事实保持敬畏，想要改变可以，慢下来，深入到所负责的业务中，了解清楚再思考如何改变。
第三个：系统性的思考，不要一叶障目不见泰山
每个功能模块，都会和其他功能系统或多或少有关系，例如每日签到系统，可能就和任务系统有关系。假设任务系统有累计签到30天的任务，每日签到却改为了签到7天即重置状态，那么任务系统的累计签到30天的数据上报就会出现问题，永远无法完成。举这个例子，是想说明，在做具体功能设计的时候，需要对上下游的功能逻辑都有所了解，需要有局部到完整的视图，包括前端类功能，后端类逻辑等等。否则当其中一个功能出现变化时，你的容错率就会异常低，同时也会错过很多机会。
第四个：拥抱变化，对需求的变更保持初心
在日常的工作中，我们会发现多方的需求管理过程中，出现不断的需求变更，耐性不足的时候就会很反感，出现埋怨的情绪。一方面，我们没有做好需求变更管理，另一方面，我们没有想好需求点，不断变化。这些都是可以优化的，从一开始就讨论清楚。但是世界上的事情，永远不变的就是变化，特别是在互联网行业，越敏捷的节奏，就变化越快。所以后面自己也释然了，只要需求的初心不变，需求的形式变化在范围内可接受，并且也是当前的最优解，这个就开心的接受即可，不要带上任何情绪。把控核心，找到变化中的不变，抓住真正的需求和机会，做出真正有价值的项目，远比情绪重要。
第四：管理方面回顾同步
这两年来，带过各种各样的新同学，也协同过各种各样的横向管理，一样米养百样人，整个过程中如人饮水，冷暖自知。所以，先过了心态这一关，渡劫。
刚刚成为leader的时候，其实没办法很好区分执行者和管理者之间的差异，甚至还一度去为每一位同学整理每日工作内容，累得不行。然后也无法从清晰认知到P型管理者和M型管理者的区别，无法大胆的要求下去，会畏首畏尾，生怕影响到下属的情绪。曾几何时，会自我质疑，难道真的不适合做管理吗？
经过近两年的不断学习和反思，得出了以下的一些经验建议：
管理主要是管人，先管人再管事，要获得下属的信任，启迪为主
管理者要利他，让下属和同级，真正感受到初衷为善，言行一致
管理者要严格，量化要求，该喷的要直面去喷，事后一起解决问题
管理者要善于倾听，不要着急辩解，先接收信息，分析后再沟通解决
管理者要做好上下级的联动，将上级的意见，细化到下级能力理解的程度传达
管理者核心技能，勇于承认错误，我基本上每周都会承认错误，的确没想到位
很多人一开始都容易有一种想法，只有我比下属厉害，才能管好他们。我之前也一直有这种想法，导致自己累得不行，没有自信。但实际上，管理者未必是所有领域的专家，而是要作为团队的催化剂，可以激发他人采取行动就好，当然，有精力去成为专家是肯定最好的。
当前我已经做了三次下级评分考核，每次考核都能看到下属有比较大的进步，这个也是在自己的职业生涯中比较深刻，估计也比较难忘。结合自己的上级对我的管理方式，我整理了下要打造高效的管理团队，应该要有以下几点
方向明确
明确的方向和目标，可以让整体项目组凝聚力更强。从时间维度上分为短期，中期，长期，滚动性规划。视图化展示，包括战略目标，业务目标，团队成长目标。特别是在小公司，或者是业务不稳定的情况下，优先谈团队成长目标，会让团队的凝聚力更强。
魅力领导
领导不是万能的，也会犯错，也有很多不懂的地方。但是如果这个人是有足够魅力的，不管最后是成了还是败了，都会获得团队成员的无条件追随。临危受命这个很能构建领导的魅力，这种魅力，单纯靠砸钱，是砸不出来的，更有钱的人多了。
合理分工
每一个考核阶段最后，我都会针对每一位下属同学，认真分析他们的能力模型，针对能力模型和他们自身深入沟通，进行分工。然后将大家的分工都同步出来，让组内同学相互知道自身和他人的工作职责，这样的透明度，让每一位同学都知道，自己的能力模型到底达到了什么级别，还需要如何才能升级，升级后能获得什么回报等等。这些都需要结合每位同学的性格特征，结合RACI模型，给他们配置不一样的任务。（RACI为PMP模型，2021年为了备考学了一段时间，有兴趣自行百度）
关系真诚
提升团队的真诚关系，可以多组织团建，团建不单是吃饭，吃饭只是形式。如何让大家的关系更真挚，相互理解，加强沟通，这个才是目的。日常中也可以在一对一非正式谈话中获得反馈。要让大家觉得我们是一起的，有事有我在，大胆的去尝试，努力工作，开心工作。
高效执行
高效执行需要默契，需要真诚的关系，需要合理的分工。如何通过一些规定，文档化路径等，指导团队的成员行为，如会议规范，运营规划，OKR北极星指南等，人管人始终是很累的，要学会科学的利用一些制度来管理人。例如，发版本前，要同步风险评估。发版本后，多少天后必须要同步版本效果。日常数据版本负责人要定期监控，每月的20号，要同步月度运营规划等等，这些都是硬性要求，没有做到的明确影响年终考核，没得商量。
持续成长
从个人角度来看，每个人都有自身的职业规划和诉求，有的人是模糊的，有的人是清晰的。做管理的必须让大家明确自己的职业规划，并且有责任为大家解惑，如果公司的发展和自身职业规划不匹配，甚至建议下属跳槽，这种利他的心态，往往能获得下属的信任，反而最终曲线救国，和公司发展方向调整自己的规划节奏。从团队的角度来看，管理者还得想清楚，2年后团队的蓝图背景是怎样的，当前还差什么，能力缺口在哪，是否需要外聘，如何构建团队的学习制度，如何学习，学习什么内容等，都需要潜移默化的影响组内成员。
第五：管理工具整理
日常的工作：每日晨会，每日晚会，每周会议
晨会晚会：
晨会：同步当天的工作内容，前一天遇到了什么问题，今天需要追加的资源和协调，是否存在延期风险等，一般时间较短，避免过度深入谈某一问题，仅同步，不讨论
晚会：同步当前的工作进展，是否完成了工作安排，更新版本开发进度情况等
每周会议：
有周会或者双周会，主要是对齐组内的工作，最好是上级先写周报，同步给下级。
上级周报上面包括了本周做了什么内容，下周主要的计划是什么，leader对组员交付，组员根据leader的安排，进行调整自己的工作
这样组员按照leader的工作安排完成了工作任务，整个组的工作任务就算完成了
运营规划会议：
下一个月的运营规划，在上一个月的20号必须梳理出来，提前安排好其他组配合，需要开发的，还是需要美术的，都提前列出需求
组内项目过多，多个项目一起，可以讨论更多的运营方案，让整体团队效率更高，明确各自负责的项目，各自的工作范围，做好分工。
版本需求会议：
产品运营需求研讨会：
需求池上面的需求，抽出来整合为版本内容，版本内容产品内部先统一过一下，取得内部一致意见，是否需要优化和调整，是否是真需求等。每版本确认前，都需要经过讨论，主要是产品和运营一起讨论，其他需求相关方也可以申请参加，例如需要同步信息的技术需求。
在开会之前，相关方务必要熟悉待讨论需求的内容，否则无法探讨出一个所以然。
版本迭代会议：
一般每两周组织一次新需求优先级对齐会议，主要是和研发相关方一起进行，一般需要可以拍板决策的老板或者需求方在场，否则就是撕扯会，没有意义。优先级分为P0，P1，P2，重要级别分为S0，S1，S2，基本上已经在研发的需求不做调整，当出现特别紧急的问题或者bug，可以通过后期PM0拍板处理，无需决策。
明确理论上，不经过产品运营需求研讨会的需求，不要插入版本迭代会议，除非特殊情况，需要PMO做好决策。
版本回顾会议
版本发布后，需要进行整个版本回顾会议，在版本开发的过程中，遇到了什么问题，后续需要如何优化等。参与这个版本的全部相关同学一起参与。
版本后，在N天内，整理出版本效果分析，包括运营效果和产品质量，客服反馈等，给到研发同学对应的反馈。
其他规划会议
项目月会
同步项目的近期数据情况，当前遇到的问题，后续应该如何配合解决，同步接下来的1~2个版本的迭代计划和目标。
这个会议主要是和其他组进行互动，同步项目信息，让大家明确近期目标，优先级，做好工作协调。
组内OKR会议
所有组员静默评审上两个月的产出，做的功能或者价值是否达到预期，做好上阶段的复盘，做好打分。
再根据项目组leader的意见，梳理出下个周期的OKR，预期核心数据和指标表现，确定优先级，有点像军令状，承诺和行动一致。
组员需要进行
年度规划会议
规划会开始对之前的工作进行概述和总结，公司战略带来泰国市场和缅甸市场的当前形势，做好定量和定性分析，针对公司的当前情况，做好半年度明确目标，年度方向目标。
从数据上，展示当前的各个项目现状，从目标上，表明需要大家配合协调的方向，结合团体资源，细化具体执行方法。一般这些是在半年度和年度会议上同步给公司所有成员。
各个项目组在会议后面，根据战略方向，制定每两个月的OKR目标和方向，量化接下来的这个周期的OKR指标方向，展示给全部组员，提交给公司领导，进行确认
第六：最后，跨学科思考
我们常常将事情一开始就想得很具体，很复杂，然后具体表现出来的却很简单。
我们常常将事情一开始想得很简单，然后具体表现出来的却很复杂。
体现的是思考的系统化和全面化，通过深入理解现状，遍历出所有细节和可行方案。从去年末开始，我已经不再惧怕复杂的问题，我就怕将复杂的问题没有思考到位，想得简单了。再复杂的问题，只要我们将发散回归到简单，通过抽象思考，从表象到本质的过程中，也就是从片面到整体的过程。近些日子以来，也受到Spencer和Vincent的影响，不同的角度，看待问题就不一样。比如从一个需求可以想到一类需求，甚至可以预判即将衍生的其他需求，基于此设计的方案，一定比只是针对一个需求场景所设计的方案更具有扩展性。
比如，我需要做一个大象场的策略后台管理系统，发现我们的hilo玩法和龙虎玩法从某些层面是可以互通的，我们就得将暴击方案一起抽象出来可配置的随机，而不是配置具体绝对值等。所以当业务极其复杂时。最好是先抛开已有的复杂角色，回归到业务最本源的业务流程中，从核心需求点触发，遍历每个节点上的核心功能，边做边思考，边思考遍聚合，这个过程收到经验等一系列因素影响，不同的人可能聚合的结果不一样，但是不能因为现在没有经验，就不去思考这个方向，因为这个产品抽象能力和架构能力，就是从一次次这样的思考中积累出来的。多请教多沟通，是一个比较快速的强化全面认知的手段之一，不要惧怕别人嘲笑自己不懂，别人也只会嘲笑不懂装懂的同学。
上面说的聚合，不是说越聚合就越好，聚合的灵活度需要有一定程度的控制。就拿现在的SKM来说，局内SLOT这个配置，就是过渡灵活，每次配置都异常困难。这种极端灵活的配置化里面，隐藏着大量的定制化，对后续产品的迭代和产研运维都极端不利。后期因为不同的人，有不同的理解，新增时更没有控制，就导致了实体泛滥。所以从产品设计之初，考虑配置化是可以的，但是字段级别的唯一性定义要留在产研级别，核心节点的定义权在产研，确保基础服务标准化，在标准化的基础上在配置化，系统的健壮性会更好一些。
例如，后台开发的同学，能更深入地理解到产品给到的后台功能需求。不要过度依赖UI和UX，从产品层面深刻理解，什么场景下使用什么样式的弹窗，搜索，筛选器等设计的规范的，不管多少个开发同学，都统一起来。关键在亲民性，复用性，对齐，比较等，这些在《写给大家看的设计书》里面都有比较明确的描述，可以让发好好研读一遍，进行总结和思考，也能提升后期的高效组织能力。比如：页面需要展示哪些些信息，如何分类，需要突出什么，弱化什么，那些使用高频，那些使用低频，好的设计将极大降低学习成本。
如果觉得整理的还可以，请关注微信公众号：良明同学，会不定期更新更多干货哦