团队管理之性能实施团队日志8

带这个团队快有一个月了，我觉得内部磨合以及外部沟通基本上形成了固定的策略。

    性能实施有两个重要的worker阶段。

1. 写脚本、做参数、定场景；

2. 分析、调优。

    我觉得第一个阶段整体感觉上没有问题了，除了还出现一些服务配置、数据之类的问题之外，压力上除了有两个系统还没有压起来过之外，其他的都基本上把性能问题在慢慢的暴露了。

    那这最关键的分析调优的阶段就必然要跟上节奏了。

    分析调优要做到什么程度呢？如果能有下面这样的响应时间对比图，那就明显不过了；

   还是要说调优的思路，因为这几天我在跟8个项目组沟通。而有些项目组中基本上是靠蒙的。突然之间就想到要改某个参数。如果能蒙一次对了、蒙两次也对了，我绝对相信这是个巨牛逼的人了。但是一次两次的失望，我觉得有点承受不了。

    在我们这个临时拼凑出来的小团队中，我也是这样要求的，跟别的团队的沟通，要证据确凿！没证据，跟人说瓶颈在哪儿，那太不像是专业的性能分析团队该干的事了。

    今天我看一个项目组说，要把jdbc从40改到1000。可是据我所知，这个数据库根本没几个忙的线程。我就不理解为什么要调jdbc？就问他们为什么要调，他们说：从日志里看到取不到线程池，所以试试。我说，那你们把证据发给我看看，我想知道你们分析的思路。结果也没给我发出有力的证据。我只能怀疑这个又是蒙的。而这个项目组，我已经眼睁睁着他们的方向性错误，好几天了。

    而PM还要关注的是整体的状态，昨天我看了一下问题。问题出现率还是挺高的。总问题已经记到141个了。其中也有功能问题，但是70%以上是性能问题。对8个系统来说，一个系统十几个性能问题，从经验上来说，似乎差不多了。但是真正的测试还没有开始。

（之前有78个问题没放到jira中，所以在jira中只能看到63个。）

    预计这个项目中出现的问题，会走过两百了，至少。对一个性能团队来说，能发现这么多问题。也已经算是多的了。

    从8个系统的各进度来看，整体上来说，有一个团队的进度非常有风险，其他的还尚在可控范围之内。

    这两天因为有一个培训，所以又要离开项目组两天。走之前我安排的本周工作目标是：每个系统都能把混合场景跑起来，要是跑不起来，那就加班。把相应的开发组拉着加班。

    今天是6月15日了，从上次移了两次项目计划来看，我们的整体计划还是非常有可能推迟到7月中旬，如果那样的话，我觉得就非常危险了。从我带性能项目的经验上来看，项目推迟半个月，从PM的角度上来说已经是失败的项目了。

    可是性能项目就是这样，它不仅依赖着开发团队、基础设施（或数据中心）等团队，还依赖着领导层的重视力度，这个领导层的含义不仅仅是最上层的领导，还有中层的领导以及中低层的领导。

    有些小leader的技术和思路还没有那么完整，问题的理解和团队的沟通都不够深入。经常出现你说你的，我说我的情况。

    中间总是有那么一小段双方都不送过去。就像前几天出现一个写Cache之后取不到的问题。基础架构那边说，你业务方写进去了成没成功是有返回判断的呀？业务方说，我写成功了呀，但是你cache取不到，当然是你cache的问题了。这一段车轱辘话说了两天，两方都仍然不往前走。最后在我开会的时候又说了一遍。实在忍不了这种的沟通方式。

    从我的经验上来看，我觉得沟通比技术难题耗费的时间多得多。技术不行，还能上网查查，再不济还能找人问问。

    但是沟通产生的时间消耗是和每个人的处事方法、思维能力、说话能力、品质都有关系。同一件事情，不同的两个人沟通，可能是1:10的差距。

    然而悲催的是性能项目（其他项目也应该类似）需要的沟通尤其的多。

    上次开PMO会的时候有三个项目组的人迟到大概10分钟左右，房间里有20多个人等着。我想这种情况应该比较常见。但是如果太常见了那就不正常了。

    鉴于前几次开会总是有人迟到的情况，于是会上我说，后面我们会发正式的meeting request（之前是约定俗成的时间，开会前在微信群里喊一声），每周的固定时间开会，同时我也把开会的时间从之前的一个小时缩减到30-40分钟。会议分成三个阶段：1. Brief；2. 过问题列表，但是一个问题如果讨论超过两分钟的就停止，移到会后或另开会讨论；3. 各项目组对性能实施的意见或建议；这一句我每次开会都问，但是没看到有人提出异议。

    并且如果以后还有人开会迟到导致有些事情没有听到就讨论完了，那也只能按讨论的结果来做。这就可以默默的给人安排活了呀。哈哈。

    前面提了好几次，我觉得有问题的点，我看到有人觉得我小题大做了。比如说，我提到没有完整的系统架构图和overall架构文档。他们一直告诉我，有的呀。之前每个团队都有画呀。我说我要看到物理拓扑架构图和逻辑架构图。而之前各团队画的都是简单的几个机器的简单的物理拓扑图，也没有系统间的connection、数据流转说明之类的。而逻辑架构图就更不用说了，我就没看到过。  

    难道现在做项目连架构图都可以不用画了吗？还是说我落伍了，这种overview picture是不需要的？

    后来他们问我，你说的架构图是啥样的哩？我默默地搜索了一个linux的内核架构图给他们看了一眼。看，就这样的。

    带团队还要注意的是团队的能力结构，可以拆分的事情尽量拆分。但是要注意拆分之后的前后衔接，这个衔接的动作要PM来完成。 如果明显觉得团队能力不够了，那就要想着迅速提升，或者让他们知道一些常规的判断问题的手段，能取出数据来也好。

    如果实在带不起来，也只能认命了。毕竟人生苦短。

    带团队有辛苦，也有乐趣，关键是团队要有成长。