做性能优化的时候，比较容易想到的一个方法是增加线程数量；做项目加速时，比较容易想到的一个办法就是增加团队or成员的数量。

有效吗？

还真有！

技术架构有所准备的情况，增加线程可以提升性能；

技术架构和团队架构划分合理的情况，增加团队也确实可以缩短工期。

但一直增加一直有效吗？肯定不是。

想象一下，用线程数和性能作为横纵坐标绘制一个折线图，随着线程数增加，性能一路上升，但也必然会在某个点之后开始下降。

阿里云分布式调度系统遇到的5K挑战便是一个很好的例子。

通过技术的优化迭代，这个曲线可以有优化的空间，但曲线的形状会大变吗？

这个曲线表达的意义值得我们进一步思考。

大部分时候我们总是认为多就是好，其实少也是好。

根据实际情况，总会有一个合适的值。团队并行是这样，需求并行也是一样。

再看一个问题，做项目管理时，你会安排哪些例会？

现在很多的项目经理都会使用站会这种形式来完成每天的晨会。

在站会上，每个人会说明自己昨天任务执行的情况、今天计划完成的任务、遇到的问题和需要的协助等等。

这样好吗？

没有对比就没有伤害！

如果你的项目团队之前信息是不透明的，协同节奏比较困难，那每天的站会可以让项目团队高效地完成信息的同步，慢慢地，团队成员之间的协作也会变好。

如果你的项目团队已经应用了看板方法了呢？

因为任务执行的情况在看板上展现得比较直观了，每个人再去轮流说一遍显然不符合工程师的调性。

在这种情况下，大家有机会更好地关注更宏观更整体的情况，站会就可以对更有价值的事情了。

首先，大家可以看项目整体推进的情况，看看是否有瓶颈；其次，可以一起对齐，看看有没有更高优先级的事情发生；最后，观察一下有没有长时间没有被关注到的内容，是否需要调整优先级。

软件项目管理的目标都是追求效率更高，差异在哪？

传统开发过程，一般会把提高职能效率作为主要目标和改进点，比如提高开发的代码行产出效率，提高测试用例覆盖度和提高系统运行效率等等。

在开始时有一定的效果，但随着各个环节的持续优化，容易局部优化过度，最后反而会伤及整体的效率。因为软件项目不是简单的职能相加。

上面提升测试覆盖度的例子，任何一个有质量意识的工程师都会觉得无比正确。

但一旦形成了职能竖井，质量团队只用覆盖度说话，项目进度赶不上合适的业务时间节点，这个覆盖度的追求有意义吗？

精益产品开发方法走的是另一个路径，以流动效率为核心改善组织的运营，最终实现流动效率和资源效率的均衡和可持续的改进。

怎么做？

首先，以流动效率改进为核心，在提高流动效率的同时，保障团队围绕用户价值展开协作，端到端的协调一致，系统改进。

接着，在整体协调的基础上，不断发现和解决价值流动过程中的问题，从而缩短前置时间，并带来交付速率的提升，同步提高流动效率和有效的资源效率。

最后，在承认和拥抱不确定性的基础上，缓解不确定性，并以合理的机制应对不确定性，提升团队的效率边界。