13
16年5月份入职，大约几个月就走向负责岗位试炼，17年始带团队。组员从起初的12号人左右，到18年底团队成员已经有30多人。期间有过失败，工作摸不清楚主次，团队关系没有处理好，曾经一度怀疑自己，产生过放弃的念头，觉得自己不适合做管理，还是咬牙坚持下来，在摸索不断进步，到18年下半年慢慢找到感觉，学会独立解决问题，学会把握工作重心，下放工作机会，学会与团队相处，学会在组员与领导之间怎么做好一个桥梁，自己的性格脾气这期间慢慢变得不那么浮躁。19年是自己工作上更游刃有余，更上一层楼的一年，有精力去反思工作这些年，自己做了什么，有哪些收获，积累了哪些核心竞争力的工作能力与经验，也有了去尝试学习新技能的心情与时间。回顾总结下17年-19年这两年的工作：
一、搭建组内效率目标
18年我开始制定了效率目标与效率合格值。背景是有次产品反馈我们的效率比较差，曾经一度在让我把效率数据发到组内群同步给同学，当时已经是下班时间了。晚上我跟哥哥分析，哥哥也认同是我们的效率有问题，我们每天积攒的广告，总是第二天早上就能处理完，而不是积攒了一天、两天的大量，我们总是追着业务跑，跟业务是一前一后，跟着业务的尾巴，可能组内有效率低的人员，稍微提升一下整体的效率就赶上了。此后我开始主动关心效率，制定效率目标，不再被动。而合格值要定多高，区间在哪里，用什么方法，我在思索。领导之前给过意见可以做压测，我也咨询了哥哥的意见。这次采取了不低于团队均值的5%为个人效率合格值。之所以是不低于团队均值的5%，而不是团队均值，因为团队均值是一个浮动数据，每天、每周都是变化的，而在不低于均值的5%和10%之间，考虑到高目标要求，最终选择5%为准线。此后每周会把全员的工作量数据，合格值数据，低于合格值人数，进行公开邮件同步，某种程度上督促大家。当时也犹豫，专门调查，是否愿意想把自己的工作量同步出去，有的支持，有的觉得自己清楚就好了。最终站在业务角度，选择客观呈现出去数据。
此后我一直把重心放在业务的效率上。团队效率，团队成员效率，积极关注数据变化，同时也会根据数据变化及时调整工作安排，同时开始思考，导致数据有这个变化的原因是什么，关注数据背后。比如2小时时效数据变化，我会思考是什么导致它的变化。
18年产品细分行业，根据业务量数据，组内调整，搭建了2个大组，及时关注两组的效率数据，基于细分后的业务特性，开始思考定不同考核指标，目标也随之考虑如何调整。当时也开始下放工作任务，每个组内定对接负责人，组内的咨询，排班等事宜，组内自行讨论安排，我把重心始终放在团队效率。
二、搭建质检模块
真正打开自己做质检的模块化思维，是一次去成都出差，学习其他项目组的业务，看到别人的质检模板，后来我们开始恢复质检了，按照学习的经验，结合我们的情况，搭建了一个简单的模块，质检同学本身学习能力比较强，比较细心，沿用的也比较好，就这样质检模块就顺利跑起来了。这次之后就像思路被打开了，越做越优化起来了。
考试方面，制定了开卷考试的模式，因为目的是让大家去讨论，去查询，去解业务，开卷有益。后来我们组是开卷，其他组是闭卷，领导统一说都可以采用开卷，就这样一直被固化下来。
在考试合格分制定上，我们约定初考试是80分，后面逐步提升到85分，后面也形成了复考考核要求分90分，希望引起大家对考试的重视。这个模式也被领导采纳，并在其他组普及约定下来。
考试试卷是围绕日常质量内容，近期更新的业务，基础业务等展开。分为判断题、做答、选择题等形式。
三、执行绩效考核
绩效考评，考核指标根据日常的合格数定制准线，有些是已经有的标准线。第一次做考核，做评语的时候，哥哥给我意见，从贡献程度上分为突出贡献，较大贡献，稳定贡献，依次是五星、四星、三星，在人员比例上，我们百度了大公司考梯次的比例人数。
四、搭建规产品管理
随着业务量的变化，产品越来越细，为便于执行，便于质检也顺利展开工作，18年我开始着手产品文档搭建供内部使用。搭建了1个通用模块、4个行业模块，每个模块涉及的具体业务对标注清楚时间来源，便于追踪。后面这些文档提供新团队延续使用做参考。
五、搭建信息同步群、搭建咨询渠道、搭建输出板块
随着业务信息流变多，尝试过邮件、文档各种方式信息同步，而文档和邮件都不便于快速追踪，尤其是紧急信息，如遇到有人休假之类的，信息同步就更成为工作中重要的一环。后来我们组建了一个信息公共群，这个群只用于同步信息，便于大家及时的搜索检阅，这个确实方便了很多，并一直被后来的团队延续使用。信息群适合紧急重要的信息，也可以看到哪些人没有关注，及时跟进。
六、产品打杂
一是搜集一线的需求反馈给产品，包括产品问题和产品建议。如是自己不熟悉的场景，搜集上来的问题，自己会先使用、感受一下，明确实际的问题，然后尝试描述场景，刚开始基本是对需求“复制粘贴”，上报上去，后面慢慢接触产品的工作习惯，也学习把需求分类，考虑需求的重要优先级，影响范围，适用场景，发现日期，开始”需求管理“，再后来，发现有些需求开发时间，排期过久，也尝试想临时的替代方案，需求管理表开始增加一栏“现处理方式”，再后来也有点经验了，也尝试想想自己的思考方案，需求管理表又增加“产品方案意见”，还有需求的进展管理，已实现，未解决等。
二是新功能上线或者系统改版，做测试体验，帮助反馈使用体验问题。基本是用户的角度反馈产品问题为主。
有时候作为用户，我们比较想产品采纳我们的建议方案，觉得产品不够真正理解我们的，比如我就希望可以做一个某某功能，比如走到哪里审哪里，我们的“半解决方案”，产品只是一旁笑了。从用户的角度也会吐槽：为什么我们觉得重要的，有助于业务，也需要的功能为什么不做，不优化，而做些对我们用处不大的功能，尤其是每次新旧系统改变，作为用户的我们都要经历一次习惯变化的阵痛。
我们作为用户，容易陷入自己的主观判断，想当然。现在对产品工作多少有些了解，产品做什么，不做什么，做多少，怎么做，慢慢谨言慎行，多观察事物。
想到工作中产品与开发之间相爱相杀的写照。我问哥哥为什么开发修BUG的脑回路如此清奇，如下图。哥哥说开发每次修BUG在悬崖边上，一个BUG可能带来新的四五个BUG，开发一直在解决问题也在制造问题，制造一系列的灾难，直到后面代码改不动了（此处哈哈哈）
七、第一次危机处理
第一次危机处理是组内发生重大安全风险。当时紧急排查了问题，发现隐患埋藏久，涉及人员范围广，觉得自己日常风控做得不够到位。后面紧急开了预警会，强调事情严重性，排查追踪，新订单有遇到类似情况，让大家及时@我，自己主动去库存复盘待处理单，和已处理单是否还有隐患。事后分析，总结整个事件的背景，事件的处理情况，事件原因分析，解决措施计划。真的是记忆犹一次危机处理。
八、说说与团队、领导相处的经验
刚带队的第一年，自己手忙脚乱，情商也比较低。
比如对业务有不同看法，直接找领导，把领导的回复截图放到群里，以此证明我的意见是对的，现在想想过于激进，没有照顾到别人的感受，是情商比较低的表现。
有段日子，业务处理不完，组员天天加班，我跟另外一个负责人，也没有主见，大家长期累积，怨声载道，直接在领导群吐槽，后面领导跟我们说，加班的事情我们自己要拿捏好，把控好。后面自己总结经验，比较好的方法就是就隔三岔五的跟大家提前招呼加会儿班，一般也会控制在8点左右，比如周一、周三、周五这样的节奏。当然也有人抱怨，有的人吃饭时间过长，我们应规定吃饭时间时长，有人提前释放工作应追究是谁释放了，也有被这些意见摇摆，后面想想，还是没有做这些强制规定，顺其自然了，当然我会把工作情况及时向上同步。
组员有不愿意加班的，托辞说身体不舒服，因为连续多此使用相同的借口，我没有理会，组员直接找到了上级领导，领导说不愿意加班就不强求；后面有遇到此类情况的，我是让同学报备一下，群里周知一下。有误解也会及时沟通清楚。
还有次，新产品上线，产品咨询上线后的变化，由于组员的习惯还没培养成，大家多是抱怨，我当时也不清楚情势，直接把组员的意见回复了，大家都觉得没有改版前好，产品当时就回复说“作为管理者不应该过于从众，被牵着走”。后面自己做问题反馈，产品反馈，都在组内反馈意见上，结合业务目的综合评估，自己真正先去了解，思考清楚。
有老组员想调换位置，我没有很爽朗答应。其实是个人情绪，觉得大家都不喜欢跟我坐一起。哥哥就开解，要换个角度看事情，比如可以直接说，你干嘛换位置，不喜欢跟我做一起吗，可以很幽默玩笑的与组内同学沟通。而且老同学跟着一起奋斗那么久，还比不上没有来的新人吗。说的我好惭愧。哥哥说心怀豁达一些。
还有一次，误以为某同学没有报备提前走了，一时情绪化问：某某是哪个公司的？一副盛气凌人，高高在上，在握生死大权的阵仗。好不羞愧。哥哥说人要保持善良，出来工作都不容易，不要摆架子，大家都是平等的。
还有次，组内离职的同学又想回来工作，领导问我的意见。当时也没有多帮助争取，比较直接说日常表现一般。哥哥觉得碰到别人面临生活机会的时候，能够善良就善良。后来我又跟领导说该同学离职的原因是希望学习新东西，如果愿意回来，如果可以工作至少1年以上也还是可以接受的。领导回复已经招到合适的人选。后面好像是去了隔壁项目面试，隔壁项目组来咨询该同学的表现，相对只说好的表现，客观表明离职原因。
哥哥说我就是个桥梁角色，要学会平衡处理。这个真的是一门情商课。
