关于团队的一些思考
目前在字节也待过几个项目了。虽然没有直接参与管理。但也算是没吃过猪肉但见过猪跑了。趁着现在新项目刚起步，正处于团队建设的关键时刻。谈一下自己的看法。希望能对新项目有所助益。
健康的迭代节奏
从几个项目经历里，我觉得想要团队和个人以及产品能得到良好的成长，最重要的、没有之一的前提，就是建立健康有弹性的迭代节奏。就像一个乐队，能不能配合的好，全看鼓手。如果在前期没有合理的控制节奏，导致团队陷入了一种疲于修Bug的状态。就会陷入穷人困境（只能从事时薪非常低的工作。所赚的钱永远只刚够生活，于是必须拼命工作才能生存。陷在一种危险的平衡里。就像跑圈的仓鼠。跑的越快就越累，一停下就会被甩出去。）而解决穷人困境的钥匙，就是一笔富余的资金。这笔资金可以用来再培训，掌握生产技术（穷人送小孩去上学就是这个道理）。或者购买生产资料（比如自动化设备，将自己从繁重的劳动中解脱出来）。
这个问题在计算机领域也有类似的例子。人眼要看到连续顺滑的图像，一秒钟大致需要60帧。也就是说你的手机需要在1秒钟之内刷新60次屏幕。那一帧的时间大概要控制在16ms。这也差不多是CPU准备一帧图像数据需要的时间。那现在市面上高刷新率的手机是如何做到一秒钟可以刷新120帧的呢？要知道8ms的时间是不够CPU准备好一帧图像数据的。你可能想不到，问题的答案其实很简单。就是延迟一帧的时间16ms。在第16ms的时候才开始渲染。如下所示。1B代表第一帧开始准备，1E代表第一帧准备完毕。
0ms8ms16ms24ms32ms40ms48ms
1B1E
2B2E
3B3E
4B4E
5B5E
渲染序列：
12345
可以看到。通过延迟16ms渲染。我们就可以达到每8ms渲染一帧。从而提高了一倍的刷新率。就是这么简单。这么说可能比较抽象。你可以想象成一个煎饼摊，有两个锅。每个锅要摊出一张煎饼需要16ms。那么0ms我摊第一张煎饼，8ms我摊第二张煎饼。就这样轮换。那是不是从第16ms开始，我每隔8ms都能拿到一张煎饼？
这个关键的16ms，对于穷人来说，就是第一笔富余的资金。而对于团队来说，就是健康的迭代节奏。
业务需求就好比是一辆火车，而开发人员就好比是铺设轨道的轨道工。刚起步时，火车速度慢，技术人员铺设轨道的速度也慢，两者刚刚匹配。而随着产品人数增多，市场规模变大，需求这列火车的速度就会越来越快。假设轨道工在火车加速的过程中唯一做的事情就是尽量把轨道铺的远一点，那用不了多久，火车就会脱轨。而如果轨道工在铺设轨道的时候不断的提升了铺设轨道的速度，那么这趟火车就可以持久的运行下去。所以如果是我带团队的话，我可能会要求团队成员8点钟之后都不允许做需求相关的东西，而是去思考，去总结，去学习。因为只有这样才有可能达到质的改变，而不是量上的提升。
因此我觉得无论如何强调节奏的重要性都不过分。前项目在这一点上我觉得做的还是不错的。很重要的一点是因为当时团队内几个重要成员对于保持健康的迭代节奏都有强烈的共识（也就是砍需求的时候比较团结）。这就引到另一个要素，强烈的共识。
共同的信念
说到共识，我想先说一下共同的信念。公司一直在强调愿景和使命，其实也是希望大家有一个共同的信念。因为信念是一个判断的准绳，类似于内心的道德标准，让你知道怎么做才是对的，这样子团队才会在多方面能够形成共识。同时他也是一个方向性的指引，让你知道有哪些是该做的。
当团队成员都拥有把自己团队打造成最优秀的信念后，很多事情就会不言自明。比如该不该写文档。该不该严格要求CodeReview等等。该不该包容团队成员的个性等。无需再过多赘述。
然而要求每个团队成员把愿景和使命来当做信念，我觉得还是有很大难度的。一则因为愿景和使命太过抽象，并且通常过于宏大。对于大部分人来说，还处于穷则独善其身的地步。可能确实没有兼济天下的胸怀。因此我个人私底下有个更接地气的信念。就是能够工作的更舒适一些。这既包括能早点下班。也包括良好的团队氛围。和迅速的业务发展。我觉得在这一点上，可能大家都更容易抱有相同的信念，也更符合人性。并且这个信念和愿景和使命是毫无矛盾的。因为我想早点下班。所以我必须想出能够提高可复用率的方式。因为我想早点下班，我的质量一定要得到保障，避免返工。因为我想早点下班，我就必须产出足够的文档，避免跟别人口口相传。因为我想早点下班，我就必须想出证明我们不靠堆时间也一样优异的方式。
所以如果是我的话。我可能会把下班时间和crash率一样作为一个衡量指标。严防死守避免劣化。并且逐步优化。而现在大家对提高效率并没有太大的热情。可能本质原因就是因为抱着：“无论如何提高效率。下班时间是不会变的” 这种消极的观念。
如何衡量团队的成长
曾经在周会上简单讨论过一个问题。如何衡量团队的成长。因为这个话题过于宽泛，所以当时只是一带而过。但当时亮亮提了两个点。一是技术指标的提升，比如crash率。二是承接需求的能力的提升。我觉得这两个维度还是很有参考意义的。
第一点自然不必赘述，看得见摸得着。
第二点则自然隐含了技术的提升，PM PRD设计能力的提升，效率的提升，估时准确度的提升，配合度的提升，或者纯粹加班体力的提升等等。因此他是一个很好的的统计出口。
但问题在于，我们并不具备度量承接的需求总数的能力。目前来看，并没有这样一种可以把需求归一化的方法。大多数时候我们只能计算需求的数量，而忽略掉需求的复杂程度及其价值。这种数据显然就和代码的总行数一样，毫无意义。而这种度量能力的缺失，也就让RD估时成为一件更依靠经验而非数据的事情。虽然看起来delay的频率也不高，但可能是因为RD发现实际进度和预估进度有较大偏差时，发生了大量的赶工而已。因此找到度量需求的方法，是衡量团队成长的前提。我能想到的一个可能可行的方式就是建立几个基线需求。计算出当前阶段实现该需求需要多少人天。再计算当前总共耗费了多少人天。从而换算出总共做了多少个基线需求数。这部分PM提到他们团队之前用的是SCRUM故事点估计法。等我看完之后或许有新的想法。
除了难以度量的问题之外。还有个问题是承接的需求总值只是一个最终的结果，我无法知道究竟是哪个因素导致了其提升，因此也无法做相应的优化。因此在我看来，需要一些更细粒度的指标。比如
需求评审的完成度
当团队面对需求细节不确定以及频繁变更的时候。最常听到的话大概是：“如果需求评审时PRD文档完善度不到一个阈值的话，你们可以不接这个需求。”但最大的问题是，PRD的完善度也是一个非常难以衡量的维度。大部分情况下，RD只在前一天收到需求，可能充分浏览的时间不足一个小时。之后便是需求评审了。在这种情况下，想要在需求评审会的短短一个小时内，充分理解并考虑到需求各方面的细节。我觉得这是不现实的事情。要知道PM的思考时间是以周为维度的，而我的思考时间是以小时为维度的。至少我自己，除了非常明显的逻辑漏洞或者异常流程缺失，其他的都是在实现时才发现各种问题。这就会导致在进入研发阶段时，需求仍然在变更，仍然花大量的时间在和PM沟通上。我觉得这其实是赶工和delay的源头。然而很少看到团队会对这个做什么改进和提升。各个团队的流程其实是相似的，关键在于执行细节。然而大部分人其实无法定义团队的问题究竟出在哪里，也就只能在流程上做文章。
所以，为什么不在一开始就让PM设计出完善度更高的需求呢？其实所谓完善度不高，就是缺少了程序员的视角，比如安卓手机的权限申请流程是什么样子的，比如安卓的通知机制是什么样子的，比如网络请求是需要时间的。这些概念其实并不复杂，也只是个有限的集合。在程序员的帮助下，我觉得PM完全有能力去学习这些。这对PM也有相当的助益。他设计的需求越完善，返工和变更的情况就越少。实现质量就越高，速度就越快。同时RD也会更乐于接受他的需求。这显然是一件双赢的事情。
【关于团队的一些思考】因此，建立PRD完善度的衡量方法，并且帮助PM逐渐去提升完善度。我觉得也是一件非常重要的事情。我粗略的想法是针对各种典型场景，RD都需要整理出最终实现发现的细节和异常流程缺失，以及一些坑点。再总结一些设计类似需求时的checkList。这有两方面好处。一是，有了不同场景需求的checkList，RD就有了框架可以遵循，就可以对号入座。这样子即使是初级的RD去评审，也不会相差太远。二是，换做其他团队设计相关需求时，也能进行参照。而现状是，PM在设计类似公司其他app已有的功能时，通常的做法是观察一下该app的流程，除此之外，并没有太多可以复用的东西。这显然是有问题的。有大量的细节可能埋藏在流程之下。于是一个团队踩过的坑，另一个团队也仍然要再踩一遍。最典型的就是图片分辨率和视频的分辨率码率问题。每个项目的PM，UED都要讨论一遍。真的很没有意义。
估时的准确度
估时，我觉得也是没有一个团队做的好的。除了凭经验之外。似乎大家并没有什么方法论。这样的问题很明显。缺少框架下的仅凭经验出发得出的值是不可置信的，可能不同的阶段同一个人得出的结论也是完全不一样的。于是赶工就不可避免。并且delay会永远存在。因为没有一种方式可以告诉我，我这次估时的准确度大概处于什么水平。我也没有任何依据去对我估时的策略进行调整，从而让其不断逼近真实的用时。
除了这两个之外，自然还可以有其他许多的指标来衡量一个团队是否成长。比如团队内信息传播效率，文档沉淀度等等。只有不断细化维度并进行衡量，我们才可能找到优化的方式从而让团队进一步成长。否则整个团队只能停留在感性上有一个好，坏的区分。就像Java Crash，Dart Crash， Native Crash要进行区分开后。你才知道你要去做些什么。
团队如何成长
集中力量办大事，单向突破
小团队，没有足够的人力，但又不想长期的处于堆业务的状态怎么办？
我觉得之前的团队，短期内想做的事情太多。每个事情都感觉很重要，于是摊下来每个都只能有一到两个人负责。这样做的好处很明显，同时几件事情都在推进。但是坏处也很明显，在团队规模较小的时候，每件事情的推进速度都非常慢。并且效果也不会好。
如果是我的话，我会更倾向于，把所有团队的力量都集中在某件事情上，集中突破。一来这样子更容易聚集大家的思想，碰撞成意料之外有意思的东西。二来可以增加团队凝聚力，快速突破一件事情，也有利于鼓舞士气。三来从最终来看，并不会多花时间。反而效果会更好。因此，当重要目标可以依靠人力加速完成的时候，我会选择投入足够的人力先解决掉。再调转枪头狂轰滥炸另一个目标。
先富带动后富
小团队技术实力较弱，想要提升技术实力怎么办？
这其实是和第一点是一脉相承的。其实，我们生活中已经有这个问题的答案。先富带动后富，你是全村的希望。把所有的资源投入到某个人身上，尽全力让其成长起来。然后让其反哺整个团队。为此可能团队长期为其承担业务的压力。当然，这显然需要团队内成员互相信任才可能办到。其实父母为孩子谋求最好的教育资源也是类似的道理。
多吐槽
每一个吐槽当中，都隐藏着可以改进的空间。也意味着我们有着敏感的感官。因此我们要多吐槽。比如这个流程为什么这么复杂。做这些重复性劳动真没有意义等等。能不能让我只关心我想关心的部分。从吐槽，到认真思考，再到解决问题。不断解决旧的吐槽，不断产生新的吐槽。团队就能不断的成长。
像我做的版本管理脚本，ET代码生成，Channel代码生成等，都是我觉得这些事情真的是在浪费生命，才有的想法。
勿以优化小而不为，勿以劣化小而为之
不要期待一开始就能给出一个完美的解决方案。解决方案也一样是可以迭代的。1.0版本可能很难用。但是没有1.0，就不会有2.0。没有用户，你就永远不知道你的方案问题在哪里，而你的用户想要的是什么。因此即使是不完善的解决方案，只要能解决80%的问题，就已经可以采纳了。
完善的新人引导
这也是前项目给我的一个启示。没有完善的新人引导，团队之前的优秀实践很可能就会被打破。比如新人不知道去哪里找到可用的基础组件又羞于请教。结果就自己新建了一个轮子。团队各方面就很容易劣化。因此建立完善的新人引导，不仅仅是在帮助新人。同时也是帮助团队。使团队成员的认知始终保持统一在一个较高的水平上。另一方面，有完善的新人引导，新人可以快速有产出，从而被团队认可其价值，感受到被需要。
我理想中的团队
每个人对团队都是不可或缺的，就像篮球队，每个人有自己的角色定位。谁也不能取代谁。同时每个人也有非常明确的成长方向。
你们，是最强的~~~
推荐阅读
- 热闹中的孤独
- JAVA（抽象类与接口的区别&重载与重写&内存泄漏）
- 放屁有这三个特征的，请注意啦！这说明你的身体毒素太多
- 一个人的旅行，三亚
- 布丽吉特，人生绝对的赢家
- 慢慢的美丽
- 尽力
- 一个小故事，我的思考。
- 家乡的那条小河
- 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量