# 被几个月代理leader
# 背景
凡事都有个背景那就先说说背景吧。
公司的业务一共由几大部分组成，分为 admin端、商户端、买家端、骑手端。在此之前一共只有两个leader，难免的就需要一个leader兼顾多个端的开发。随着公司业务的扩张和人员的扩充，原有的团队编制已经渐渐变得有些臃肿和难以把控，一个leader显然是无法兼顾那么多的迭代任务和人员分配的，于是乎公司新招了两个leader分别负责admin端和商户端，原有的两个leader分别负责买家端和骑手端，这样的分配似乎跟我没什么关系。
我所在的组是骑手端，新来的leader还不熟悉当前业务同时还有一个任务重心是骑手端需要合并公司越南地区现有的骑手业务，需要重新开发和整合。基于我对当前骑手端的业务比较熟悉，赶鸭子上架那是必须的了，所以后续的迭代需求基本都由我来掌控了。
# 干的事情
# 需求评审
纯搬砖的阶段需求评审也是有听的，但是不会过多的关注细节，大多时候听个大概，下来看看PRD再扣细节，评审会议不需要跟别人讨论，不需要发表自己的见解，因为上面还有leader。但是当自己来干这件事的时候发现完全不一样了。会议上随时会被别人点名，比如：“这个点是如何实现的逻辑是怎样的”，“这里这样设计合理吗”，“这个点需要客户端支持吗”等等。一开始卡壳是常有的事，甚至有时候为了回答当时的问题随便做出了一个回答，显然整个过程慌得亚皮。后来好好反思了一下整个过程中我欠缺的是什么。发现几个问题:
- 对以往的业务不熟悉，当提到相关的业务点时并不能全局的思考问题。对此恶补了以前的prd，至少做到了知道这个业务点的大概逻辑。
- 会议之前没有先对prd做预评审，prd会议更像是讨论，讨论的前提是参加会议的人都事先知道这个事情的脉络，讲的什么。如果没有预先的了解别人说什么肯定是跟不上的。
# 任务拆分，人员分配
对于新的需求点往往是一个大的面，需要拆分出细的点和线，这样做的好处是 1. 不容易漏掉细节。2. 方便评估工时，如果一个任务超过了三天就要想想是不是可以拆得更小一些。
对手里现有的人力进行评估，并不是每个人手里都没活儿干，合理分配任务让人力得到充分的发挥。当然这也不是唯一的标准，在进行人力分配时需要考虑相关性，也就是当前这个任务跟这个人之前的相关性，如果这个人之前就是做这一块的那也应该尽量分配给他因为他更熟悉，也许读者觉得这难道不是理所应当的吗？但我在工作中确实遇到过让不熟悉的人去做不熟悉的事，原因是有利于熟悉整体业务，但是个人认为弊大于利。还有一点是有些任务是只适合一个人去完成的比如前后逻辑是串联的，对于独立性更强的模块多人协作才能发挥更大的作用，并不是人越多越好。
# 方案设计，与 PM 进行 pk
对于需求中的实现难点提前提出来进行方案设计，例如:
- 对于复杂的业务逻辑可以提前画流程图或者时序图把这个逻辑脉络理清楚，这样方便后续开发对照以免有漏掉的逻辑。
- 对于技术难点提前进行方案的调研，同一种结果往往有多种实现方案，多种实现方案之间往往各有优缺点，所以需要权衡当前的实现需求更适合哪种等等。
对于不合理或者实现代价大且性价比不高的点及时提出来与PM进行讨论甚至PK，有时候还需要据理力争，“这个功能做不了”那是有原因的。
# 排期
排期要结合人力情况，各端时间。有时候人力就是不够，PM 要求的deadline又特别急，那这个时候就把问题抛出去让PM自己去确定优先级，只有这么点人力刀架在脖子上也干不完，只能挑急的先做。
确定与各端的联调时间，一般是各端同时进行开发，例如确定与后端的联调时间那么就需要把这部分时间预留出来。
# 突发事件的应对和处理
PM 需求变更 PM 临时变卦估计大家都遇到过，在所难免的，如果是业务方的需求变更那该改还是得改（如果变更太大只能往上反馈打回重做重新走需求评审）。如果是PM想“炫技”，那对不起走下次迭代。
Bug 跟进 Bug 这玩意儿没有则好一出bug属实是难受，这个就不细说了种类繁多。对于线上bug，解决后还需要给出一份详细的说明，造成bug的原因是什么，这个bug的影响面评估需不需要走紧急hotfix，这个bug的解决方案是什么等等。
日常工具人 不管谁有什么问题第一时间一定是找到你，还得不厌其烦，有时候会被几个人同时狂轰滥炸。这也没办法，当然是微笑面对。
# 发布前的期准备
- code review，这个每家的标准都不同就不细说了。
- 发布计划的填写，本次发布了哪些内容，便于后续追踪
# 发布后的工作
项目发布了并不意味着就完事了，还需要跟进后续的验收，有没有bug等等。当然项目不是裸奔的，有接入监控系统，发布后需要关注监控数据的反馈，及时发现异常。
# 感悟
缺点：
这一套下来说实话想码点代码，那是真的没有时间。时间都被耗费在了那些零零碎碎的事情上。大脑需要多任务作业，不同任务之间需要来回切换，心儿累！
优点:
- 全局把控能力显著提升，以前搬砖大多时候只局限于局部，现在视野放宽后对事情的全局认识有了很大的提高，认知不同视野不同能做的事情当然也不同了。这也解决了长期困扰了我很久的问题，为什么有些新招的leader刚来不久就能快速的上手业务游刃有余，个人觉得全局视野相当重要。
- 学会主动正向思考，这一点也是我觉得最大的收获，成长从来都是自己的事，不要想着等着谁来培养你，要多发挥自己的主观能动性，多想想如何利用自己手里现有的资源和工具提升自己的工作效率。也不要想着“等我到了那个位置再思考那些问题”，事情往往是相反的，大多数时候是因为你具备了这个能力你才能到那个位置。
- 作为一个leader的向上向下沟通，沟通是最费时费力费情商的一个工作。向上要权衡什么事情需要向上推进，有些事情可以自己做决策，但是没有把握的事情一定要向上反馈和寻求解决方案，这不是为了出问题了不背锅（当然这也是很大的一个原因😄），上面的决策者的视野更广资源更多人脉更丰富解决方案当然更多，如果一味的隐藏问题或是羞于启齿，到时候炸锅了大家都难看。向下沟通要注意把控自己的情绪，做到就事论事，清楚地分配和传达任务，切记颐指气使，居高临下（被人这样对待过的知道有多难受）。
- 如何让你的兵能开心顺畅的搬砖，以前我也见过很多这样的场景，任务已经开始开发了底下的人还跑过来问：“我应该做什么？”，作为一个称职的leader这是不应该发生的事。任务开始开发之前需要将任务做细致的拆分，拆分过程中想想需要注意的细节以及有没有实现难点，如果有难点提前提出来小组内讨论，拍版确定方案，至少保证开始开发的时候没有方向性错误。努力将杂乱的活儿揽在自己手里，自己写业务代码的时候最讨厌就是有什么事情把自己打断导致思维不连续，所以让自己成为一个团队的入口，什么事情都先从自己这里过，自己再根据手下人的情况进行分配或者自己就解决掉。
- 不要露怯，这一点个人感觉尤为重要，我觉得是作为一个领导者的基本素质，不管你对与错，如果错了就大方承认。作为一个team的领导者，底下的人都是以你为行为目标，不管事情本身的对错，底下的人都是需要一个目标的，有了目标底下的人才有往前的方向和原动力，如果你都慌了底下的人更慌。