由于开发成员均是从其他两个team抽出来的、测试也是从测试团队抽出来的，过去半年，在NIO是一个非manager的team leader，但是由于互相信任，除了无manage权限，其他没有任何区别，而且自认为做的还是蛮好，作为回忆录记录了。
当然下面的实施起来跟平台还是有很大关系的，毕竟同事的专业素质还是够硬的。
一、背景
中央网关迭代到060版本后，发现bug井喷了，软件发布计划一再delay，最终领导意识到了之前团队管理的一些缺陷。团队本来已经有两个开发leader，考虑到2个开发leader需要面对的开发太多了，进而又划了一个团队给到我这边。我们团队组成一开始是5个开发+3个测试开发+1一个系统工程师+若干外包人员（流动性略大）。团队整体年龄偏年轻，系统工程师93年，5个开发分别是95、92、88、69以及85年的，测试开发（下用测试代替）也是30左右，而我自己是95年的。
作为一个零管理经验的开发，再加上有其他团队领导的指导，经过大概4个月的左右时间，我们team基本上已经运行的比较好了（甚至比另外2个team都好一些，当然有一些其他客观因素）。从需求管理、到需求实现、到bug修复，再到最终交付，基本上都能够自驱进行了。在过去和蔚来的一周年中提到了，正是由于各个成员的给力支撑，让我每天只需要花不到2小时的时间在团队管理中，从而有很多的时间做一些中长期计划以及自己coding。回首已经过去半年了，转眼由于一些客观和主观因素，我也即将离开NIO这个平台；但是真的很感谢这段经历，不仅让我更加的理解了领导的一些难处，同时也让我略懂需求管理、团队管理以及软件发布管理。下述会有很强的经验之谈，并且由于经验略浅，可能会浮于表面；同时NIO作为整车厂，本身有自己完善的流程，所以肯定会有较大的局限性。
同时我们team跟其他team不仅仅是面向交付，我们还做了很多平台性质的开发，服务于功能个交付，但是却不是只为了功能个交付。
在团队运行5个月后，bug和需求基本收敛，p0、p1 较少出现，出现了也基本能日清；我们在日常交付中，不仅能够实现需求，甚至能够预测需求。
二、小团队运行流程
之前思考过，小团队管理中是管事还是管人？说白了，其实我迷茫的是，应该以事情为导向还是以人为导向。
刚好隔壁团队（感谢@泽哥，他对我的影响和帮助都特别大）是专业管理出身的，但是技术却是小白了（领域内），所以他们是以更多的以事情完成为导向；而我基本能够cover较多的技术内容，所以我一开始选择以人为导向作为团队管理的开端。以人为导向，我的做法是，事情指定到具体的人身上（技术栈最近原则），比如开发负责需求实现，测试负责测试用例开发，而我作为管理者负责协调两者的进度，具体做下来发现，虽然我能够了解其中很多的来龙去脉，但是同时大大增加了“内耗”沟通，让是团队整体变的低效。所以一段时间后，我基本放弃了这种方式，我选择把自己了解任务、需求的前因后果放到更加前期。
同时定下了团队目标：开发进度整体随着（整车）版本进度走，但是team内需要较大的buffer来缓冲不利因素，以及给组员有更大空间拓展一下面，更好的互相备份。
想通过一些具体做法拆解我在小团队运行管理中的具体做法。
1. 需求分解
前面提到，我会根据每个人的技术栈背景，将任务安排到具体的开发和测试身上。这会导致实施时沟通成本变大。所以后续做了改变，每两周跟TPM做planing时，我会决定哪些任务能够在哪个版本上实现。我的原则是：开发任务最多只占开发时间的50%，超过的任务无论不接受，但是可以根据重要、紧急程度来进行交换。只接受50%任务负荷的原因，我想让团队有更高的自由度以及更好的软件质量。待任务commit之后，系统工程师（下用SE代替）会找具体的FO（Function Owner）了解清楚背景，然后SE会约我的时间做一次较为详细的planing，根据详细的需求内容，我评估出大致需要的开发和测试时间，以及进一步确定前期是否有误判，如果有误判则需要及时向TPM提出；同时在交流的过程中，我不仅知道了需求的细节，同时也在脑中有了大致的实现方案；最后在跟SE交流的过程，会初步明确合适人选有哪些。当然这个过程，需要识别到跨团队任务，并及时跟其他team的开发leader做好沟通。
这一步总结下来就是team leader一定要做到心中有数，为后续开发过程可以通过很简单的交流沟通，就能够知道事情大致进度以及风险做好铺垫，这样可以更好的解放自己。
2. 保护团队成员以及任务安排
作为开发最讨厌的是什么？是打断！！！！尤其是会议的打断，所以保护成员的第一步是避免开发陷入到会议之中。尤其是无效会议（人多且长）。我首先从团队内部做起：
- 每天进度同步会定在下午17:45，只留15分钟，超过则成员赶不上班车，所以就会大家只说关键的。这就要求成员需要有一定的准备，进度同步会可以作为叙述能力的一种锻炼。
- team内部，超过半小时的会议需要提前预约，会议时尽量不要做其他事情，提高会议效率。
- team外部的非紧急bug不允许直接拉开发，需要与我沟通后，做一道过滤，决定是否需要内部成员进一步分析；尤其不允许售后的bug直接到开发，这种会议人多又长，动辄n*小时。
同时，保护成员，还需要从需求方面入手，未经SE和我评估的需求，是不允许直接assign给开发；避免让开发陷入到无序、无计划的开发中，这其实也是一种打断。
任务安排不能太满，同时充分相信工程师自己的判断，比如我评估需要2天，工程师评估需要3天，一定需要相信工程师！！！如果偏差过大需要跟工程师做一次同步，评估出双方是谁误判了，为下次纠偏积累经验。不要把纯需求实现，占满工程师的所有工作时间，需要给工程师自我拓展知识面的空间（50%）。比如我们团队之前有一直focus在mcu上的成员，作为team leader需要了解到她现在的想法，比如是否觉得一直做mcu开发很无趣，是否有兴趣转到linux开发等。如果得到肯定答复，后续需求安排，务必时刻考虑这一点，比如在linux环境上的一个小需求可以给到她来做，同时即使她耽误了，保证自己上手后短时间内能够快速解决。
所以保护团队成员，不仅是保护成员不被打扰，同时也需要给团队创造空间成长，避免成员一直在做一件事。既容易枯燥乏味，易离职，又不利于团队成员互相backup。
3. 提升测试人员的地位
包括自己以及了解到的，开发总是有点傲气的。但是作为开发、测试在一个团队里的，team leader本身是开发背景的。一定需要提升测试人员的地位。我的做法是：在出现争执时，适当偏向测试人员。
上面需要长期坚持，做到潜移默化，同时也需要体现在实际行动中，证明需求实现并不是开发的专属。比如我会把较大的任务让测试人员来leader，让测试人员梳理整个需求点，并整理成ppt，给开发、SE做分享，进一步同步三方的认知，保证是一致；后续也是测试驱动开发，比如由测试追踪开发的进度。这一过程主要是从技术层面告诉开发，测试人员理解的需求并不会比开发差，大家只是分工不一样而已；另外测试驱动开发，有助于bug提前发现，提高软件质量。
前面提到了，我们的测试人员比开发年轻，他们的积极性也更加的高。所以测试驱动开发不仅提高了测试人员的地位，同时也让任务推进的更加快速。
并且开发一定需要自测，如果不自测，测试人员有权拒绝流转任务；同时测试脚本最好能够以代码的形式提交，让测试人员复用。自测的目的是，是保证初始提交代码的质量；并且提供测试代码，可以让测试人员进一步的了解到开发细节，尤其是一些测试人员难以测试的case。
如果上述三点能够较好的落实，团队就会处于比较好的自驱状态了，作为team leader每天的团队管理时间，也会有处于较低的水平，比如我自己后期，平均到每天基本不到2小时。
4. 永远不要忘记修改丑陋代码
有时候，由于需求上线的时间点，会对方案做妥协。比如用全局变量、hard code去快速实现等；又比如手动执行测试用例，而不是自动化测试。无论针对开发和测试，一定需要提醒团队不要让一时丑陋变成永远丑陋。前面提到了，给开发们（开发和测试开发）留buffer，一部分就是为了改丑陋的代码，如果丑陋代码一直在，只会让代码越来越丑陋，并且埋下bug隐患。个人认为这是060软件版本，bug井喷的关键原因。
为了达到这一步，team leader一定要做好代码和测试用例review，允许暂时的丑陋，同时需要将代码做减法作为考核的一部分。我自己会经常在计划较为长期的迭代计划，比如我会在100阶段定好我需要做哪些软件改善，然后最终在110版本上线（100和110时间上查2-3个月）；期间在实现需求时，会把优化提交到其他分支上，等某个阶段merge到develop分支上，经过develop日常regression，发现问题则解决，等110分支从develop上拉出来，则进入release测试阶段，既保证了迭代了，也保证了质量。我也经常拿我自己的例子，分享给团队。
作为管理，我经常私下里去比较开发人员某两个大版本间的代码改动，看是否有迭代的痕迹，作为评判工程师习惯的一部分依据。
5. 一定要找到rootcause，但需要关注过程
作为team leader遇到bug，需要以身作则的拿出态度：不能途中遇到芝麻，却忘了西瓜。看过好几次团队成员在解决概率性p0、p1 bug时，在查看日志时，发现了一个小问题，赶紧提代码、测试、qa一条龙，流畅无比。但是真正问rootcause时，却经不起推敲。印象很深刻的一个bug：什么，linux用户进程被挂起了? 这个问题发生时，我刚好在休陪产假，又正值SUD冲刺阶段，又是概率性很低的问题，团队成员在解决这个问题时，发现了日志上有一个其他小问题，对着这个小问题快速解决后，以为原本的bug则被解决了。但是后续去追问rootcause时，却处处解释不清楚。当然这个问题，本身太有迷惑性，很难想到进程会由于日志输出被挂起，也因为这个问题，我有时间去阅读《Linux/UNIX 系统编程手册 》这本书。但是我想说的是，作为team leader一定要关注关键问题的rootcause，守好开发质量的最后一道关，避免问题反复出现，拉低团队质量评价。
关注西瓜，是否意味着，我们能够把芝麻丢掉呢。软件一定存在bug的，有些bug需要很多Corner case才能复现，并且产生影响。很多时候发生了，但是却由于负负得正或者被系统鲁棒掉了，则不会体现出来。作为开发，分析bug时，是我们关注日志最多的时候，这个过程我们需要关注我们的程序状态。作为team leader，在与团队成员分析过程中，需要保持足够的敏感度，在遇到异常日志时，需要及时提出来了，从我实施下来，让很多类似问题都没有等到测试来发现。在这个过程，针对年长的开发，需要保持足够谦虚；如果开发本身欠缺这方面的认知，正好可以通过这个过程给他们树立很好的榜样。
6. team leader要为迭代计划负责
team leader对于开发来说，是需求的来源，在成熟的组织架构下，他们是无条件信服你的。这个时候，我们就需要为整个团队的计划负责。
我们需求会来自两部分，外部和内部的。外部的前面提到了需求分解和任务安排，对于这部分，team leader主要是需要面向对交付，保证交付节点，我们需要时刻关注任务进度以及bug修复情况，甚至时bug趋势。在我看来，这部分是最简单的，较为有挑战的是内部需求。
内部需求，首先需要团队内部产生，在团队成员不在一个认知水平时，内部需求大部分是来自于SE或者team leader，如果团队成员本身有这个认知的话，会自己产生需求给自己。那么内部需求的目的是什么？我觉得有两点：
- 改善软件质量
- 为后续需求铺好路，我更喜欢称之为预知需求。
改善软件质量，是为了避免陷入的bug泥潭中，对我来说，一个工程师如果一直在修bug，有很大概率是他的做事方法有问题，而不是他很优秀。前面提到了，永远不要忘记修改丑陋代码。其实方法很简答，就是我们在实现需求时，需要随时去迭代我们设计有缺陷甚至是妥协的代码。这不仅仅要求开发，同时对team leader和测试也是一个挑战。team leader需要跟开发一起评估好影响，做好回归，然后team leader需要跟TPM商量交付计划，并给交付的测试人员提供测试方向。从我实践下来，只要team leader有想法做好这个事，并坚持下去，只需要经过2-3个月的时间，我们就能看出很明显的成果：bug在收敛。但是具体的效果，又强依赖与团队成员的技术素质。
什么是预知需求？我定义的预知需求是：需要以开发软件平台的思维去实现需求。举个具体例子；接到doip over tls的开发需求时。最简单的方法是：我们针对具体ip和port加上tls的属性。但是有没有想过，为什么一开始没有上doip over tls？后面会不会有doip over tcp和doip over tls并存的状况，如果有，如何保证工具端能够很好的切换？tls的验证是单向验证还是双向验证，后面会不会有些ip和port是单向，其他的又是双向的？
是的，理论上FO需要考虑这么多，但是大部分FO不会考虑这么多的。但是站在team leader甚至开发的角度来看，我们是需要考虑到上面的情况的，会预知到，随着后续软件的迭代计划，一定会出现上述case。那如果我们仅仅是简单实现，等需求来了时，我们怎么办？另起炉灶，再来一套？亦或者魔改？显然是不可取的，我觉得正确的做法时，在接到需求，从开发角度，评估出后续场景，尽量以面向对象的思维搭好基础设施，为后续需求留好接口和分支；甚至做成configuration。这样等真正的需求来临时，我们可以花更短的时间实现需求。其实针对预知需求的成果，基本上不会超过半年就能看到很好的效果，我们会发现面对同等难度需求时，开发时间一直在缩短。
当然上述两点，关键在于team leader；同时成员是落地的保障，如果团队没有磨合到一定默契，推进也是较为困难的。
总的来说，如果团队较小，team leader的想法、做法和态度更加关键，如果方法正确，即使新团队也可以在较短时间内完成磨合；在团队有一定默契时，很多事情推进就更加顺利，一直形成正反馈。当然team leader也能从其中收益，即从团队管理任务重抽出来，做一些更加长远的计划。比如我在过去和蔚来的一周年提到的两个重构，就是在有管理任务时提出，并一步步落地，而我基本都能够有时间深度参与其中。
三、小团队管理什么
我自己经验总结下来，小团队中的管理，对于team leader来说更多是以下几点：
- 需求和bug管理
- 团队氛围管理，开发、测试互补
- 给团队成员提供空间成长，这个对于不同年龄段的工程师可能述求不一样。比如年轻的会更多的追求自我成长，而年长则更加希望能够得到尊重和待遇医生，需要区别管理。其实我更加愿意称之为：创造条件以自驱。
- 关注关键的细节，但是又避免陷入琐碎的事情中。这个更多的是需要过程中灌输自己的方法论，当然永远记得保持谦逊和学习其他人好的idea，最终团队成员和team leader认知和追求的相近甚至一样的。
- 团队中需要有中长期计划，比如代码质量改善、平台开发。最终达到的目的是：开发进度整体随着（整车）版本进度走，但是team内需要较大的buffer来缓冲不利因素，以及给组员有更大空间拓展一下面，更好的互相备份。
不管如何吧，上述更多的是自己的经验之谈，本身也缺乏系统的管理知识学习，team leader的时间也不那么长，虽然现在结果很好，但也许是过于顺利以及是在NIO这个平台下面，掩盖了一些问题。而且团队成员也很给力，尤其是SE，需求理得明明白白的，很幸运拥有过这么优秀的小团队。后面自己肯定是主开发了，但是过去半年了，也知道了，其实管理并没有那么容易，当然也不是管理就一定需要抛弃技术，之前自己一直有妖魔化管理这个角色。
最后关于优化和重构。首先是重构，过去一年对我来说，重构是一个最关键的标签，但是我还是想说，如果软件运行稳定，不管实现多丑陋，不要轻易选择一下重构，最好的办法是逐步改善（当然有时候的确是无法做到）。因为重构涉及的不仅仅是技术方面的原因，首先你怎么能够保证测试之后就一定能够比之前好呢？其次还有测试、资源协调、项目管理、如何无缝上线等诸多与技术无关的事情，但是每一项都是重构项目不可或缺的。另外就是优化，优化最好是在平时，在问题堆积不太多的时候，否则堆积之后，优化就无从谈起了。
A fascinating discussion is definitely worth comment. I do think that you ought to publish more about this topic, it may not be a taboo subject but typically people dont speak about such issues. To the next! Many thanks!!
I really like it when individuals come together and share thoughts. Delmer Olson
Well I definitely liked studying it. This article offered by you is very effective for accurate planning. Wilone Parnell Warton
I was examining some of your articles on this site and I conceive this site is really instructive! Retain posting. Rolando Reinholtz
Itís difficult to find knowledgeable people about this subject, but you sound like you know what youíre talking about! Thanks
Excellent post. Keep writing such kind of information on your site. Scotty Estimable
I am perpetually thought about this, thanks for putting up. Jospeh Billinsley
This is my first time visit at here and i am really pleassant to read all at one place. Reyes Tep
Usually I do not post on blogs, but I would like to say that this article really forced me to do so! Thanks, really nice article. Ricardo Canterbury
As the crowd rushes toward the quarterback, the other players walk freely across the campus. Bo Cayer
Just wanna comment on few general things, The website design and style is perfect, the articles is rattling good :D. Werner Stucke
Make sure you utilize tags in your blog posts in a careful manner. Cleo Dikeman
Hi, after reading this remarkable piece of writing i am also glad to share my know-how here with mates. Virgil Mizzelle
As the Reels Turn is a 5-reel, 15 pay-line bonus feature video i-Slot from Rival Gaming software. Rayford Lybert
I love being near waterfalls! There are beautiful falls in Vermont. Weston Mannschreck
Good post. I learn something totally new and challenging on sites I stumbleupon everyday. It will always be helpful to read content from other writers and practice a little something from other websites.
אני מאוד ממליץ על אתר הזה כנסו עכשיו ותהנו ממגוון רחב של בחורות ברמה מאוד גבוהה. רק באתר ישראל נייט לאדי <a href="https://romantik69.co.il/">https://romantik69.co.il/</a>
Hi i am kavin, its my first occasion to commenting anywhere, when i read this post i thought i could also create comment due to this good article. Merle Gudino
Thanks to my father who told me regarding this web site, this blog is truly remarkable. Bart Maniccia
Usually posts some quite exciting stuff like this. If you are new to this site. Murray Banyas
What a information of un-ambiguity and preserveness of precious familiarity about unexpected feelings. Kurt Avilar
Good post. I will be dealing with many of these issues as well.. Dirk Fahs