你有没有遇到过这些场景。

场景一

领导：小明，上周组会跟你说的那个A项目进展如何？

小明：啊？还没弄啊，我最近忙疯了正在忙着B呀。这周我抽时间看一下。

一周以后，没人还想得起A是什么东西。

场景二

同事：小明我上周跟你说的A项目做的怎么样了。

小明：我搞定了，发你邮箱了。

同事：我们不是说好了做成那样吗，你怎么这么做啊。

小明：我们之前说的就是这个呀，我还连续加了两天班呢。

同事：......

小明：......

这样的场景是否很熟悉。为什么会这样呢？是小明不靠谱？同事不靠谱？还是领导不靠谱？都不是，而是团队之间的协同出了问题。

最近的事情

最近公司的计算机群需要扩展计算资源。长话短说，我们有两类方案，一类是加机器，不改变构架价格相对便宜。第二类是改变构架，需要添加管理节点，计算节点，存储节点，再加一套全新的管理软件，让它们协同起来，为以后扩展做一些基础和准备。价格比较贵，但是构架有一定优势，对于后续新节点的扩充有更好的拓展性。对于第一类方案，虽然便宜，但是节点越来越多，节点之间通信开销会提高，集中和存储的IO压力也会增大，在某一个上限性能将不再提升，甚至下降。第二种方案优化了管理架构，加机器所带来的性能提升可能会持续的时间长一点，瓶颈来的晚一点。业内专家也认为，有些时候不是堆机器就可以解决问题的。

通常来说，一个分布式计算集群系统会存在几个重要角色角色，管理节点，计算节点，存储节点，网络通信。计算节点增多，管理节点会繁忙成为瓶颈。存储节点加多，网络通信IO有可能成为瓶颈。而集群内部的内部开销会逐渐消耗掉越来越多的资源。而增大一个角色的权重，就会使得另一个角色成为瓶颈。

从集群到团队

不同事物背后的本质也许是完全统一的，团队不也是这样吗。自上而下的组织结构，领导说什么下面听话照做不思考，结果就是领导忙的像疯子，员工忙的像傻子。那放任不管呢，员工自由发展。结果就像集群的机器之间网络全部瘫痪，无法形成像样的战斗力，相互协同混乱不堪。然后管理者基本不知道下面员工在干什么，而员工也不知道大方向在哪里。另一个问题， 当事多人少的时候， 似乎想到的第一件事是招人。 招人很重要，也许是最重要的事， 但招人就像加计算节点会有一个副作用，增大了管理节点的压力。 管理5个人一下的团队， 管理者可以“兄弟们，跟我一起上， 炸掉前面那座碉堡”，人员少，人员间沟通高度统一，内部沟通产生的开销相对小。 而管理50人的团队， 也许就完全两回事。 内部开销会呈指数增长，最终多加了几个人，最终生产力却降低了。 如果加的人不靠谱，还可能造成所谓“污水效应” 劣币驱逐良币。 

一套内功心法，一套刀法，外加一把屠龙刀 

回到最开始的小故事。 这个故事我觉得任何在职场待过几年的人可能都有体会。 基本上每天茶余饭后的吐槽估计也充斥这不少类似的内容， 估计结论都是小明不靠谱， 领导不靠谱， 同事不靠谱， 就是自己最靠谱。 就好比对于网络瘫痪的计算节点来说， 这个世界只有它自己一样。 但本质上不是谁更不靠谱，而是之间的通信协议出了问题。 最近笔者也一直在头疼类似的事情，怎么能让团队知行合一，充满战斗力，并且快速个人提高和成长。 不断摸索中，找到了一套内功心法， 一套刀法外加一把屠龙宝刀。 

一套内功心法： PDCA循环

PDCA循环也叫做戴明循环， 戴明是一位美国质量管理大师，后来帮助丰田获得了巨大成功。 核心理念如下：

Plan: 决定3W（Who do What by When）

会议的本质是用时间来换取共识和结论。 开会之前充分准备，并且确定会议的目的和需要确定哪些议题。最终会议结束后，确定3W。 确定下一步任务是什么。 谁来负责， 预计什么时候能完成。 对于项目级别的大目标进行SMART原则的任务拆分。 只有成为具体任务， 才能有可执行性。 这一步可以说是最重要的一步，开会没有结论，要么开到有结论为止，要么就不要开，否则就是浪费大家和公司的时间。 

Do： 执行

这必然是费时最多的一步。 目的在第一步确定的When之前把计划执行完毕。 

Check：检查点，反馈。 

在截止时间前反馈进展， 是否成功。 如果失败为什么失败。 最差的反馈就是没有反馈。 无论换谁做老板， 面对这样的下属都会极度没有安全感。 “简单的来说就是，交代的事情就不能回个话吗？”

Act： 总结，讨论，处理。 

根据Check的结果进行总结，讨论，解决，或者无法解决进入下一个PDCA循环。  

一套刀法：SMART原则

SMART原则， 我觉得是如何把一个抽象的项目变成一个个可执行的任务的基本功。 不知道你有没有遇到这种情况， 一个看似高大上的项目布置下来， 做着做着越来越迷茫，似乎千头万绪永远没有头绪，最终不了了之了。 团队成员没有明确的目标， 盲目尝试了很多东西，激情消耗完了， 杂事插进来，高大上的项目被搁置在一边，然后，就没有然后了。 

S.M.A.R.T（Specific Measurable Attainable Relevant Time-Based）是一套把项目拆分成具体任务的衡量方法，具体如下。 

Specific: 具体的， 一刀砍掉模棱两可。  

Measurable: 可衡量的， 一刀砍掉标准不一。 

Relevant: 相关的， 一刀砍掉无关目标。 

Attainable: 可实现的， 一刀砍掉不切实际。 避免，折腾半天发现理论上就是扯淡的情况。 曾经有人跟我说，用10多个样本分成四五组还要做机器学习，训练各种高大上的模型就是这种情况。 

Time-Based：有时间期限， 一刀砍掉没完没了的拖延。 

一把屠龙宝刀: 项目管理工具（trello, teambition, tower 等）

在项目管理工具出现之前， 有一种基于白板的团队工作方法叫做scrum, 类似下面这个样子。 

在scrum项目站会的时候大家制定计划，明确分工，每人一种颜色。 把需要做的事情贴在TODO 泳道， 正在做的从TODO迁移到Doing， 结束的进一步迁移到Done。 这样整个团队都可以明确看到每个人的工作进度和整个项目进度。scrum方法其实还有更多的内涵，这里我理解的还比较肤浅，我就不再多说了。 

在当今互联网时代， 涉及到更多的人，在不同时间，地点进行协作。 使用一些工具更加简单有效。 teambition, trello, tower都是很好的工具可以尝试。 目前我们团队刚刚引进了trello， 打开团队看板， 有一种忽然第一次知道大家都在干什么的感觉。 trello的看板大体如下。 

通过这样的看板， 团队负责人可以明确知道每一个下属都在干什么，有哪些问题，有哪些成果。 项目需要的文件共享和沟通记录可以放在每一个卡片下面便于归档查询。 

总结：

1. 团队提高产出不只是招人那么简单， 就像扩充集群不能只是加节点。 

2. PDCA循环和SMART原则， 高效开会，把项目变成任务， 把任务分配给个人。 

3. 项目协同软件和scrum方法， 让团队的管理节点实现高可用。