故事分析⚓︎

猪和鸡的故事，想必大家不会陌生，中文有很多版本，也有英文的版本 $^{[1]}$ ，只不过大家讲故事的场景不一样。笔者认为这个故事在团队建设中有很重要的指导作用，所以在本章中再次拿出来与大家分享。

猪和鸡的故事版本2.0⚓︎

猪、鸡、狐狸、老虎、鹦鹉合伙开了一个饭店，具体分工是：

动物	角色	工作内容	参与程度	失败后果
猪	员工	提供猪肉（从自己身上取）	全身心投入	血本无归
鸡	员工	提供鸡蛋（自己下蛋）	部分身心投入	损失不大，还可以在别的地方下蛋
狐狸	经理	提供执行建议并监控	智慧投入	学习到了失败经验，换个地方做经理
老虎	董事长	提供资金	钱财投入	损失一些金钱，九“虎”一毛
鹦鹉	局外人	提供咨询	围观	成败与自身利益无关

以下内容摘自《构建之法》 $^{[2]}$ ：

加入一个团队时要弄清楚自己在团队中投入的级别是什么，别人的期望值是什么。人可以在 $n$ 个地方做鸡，或者 $n \times m$ 个地方做鹦鹉，但不可能在两个地方同时做猪，这太难了。在遵循敏捷原则的团队里，成员们并不忌讳谈论不同的投入和负责程度 -- 因为这就是现实。

但是他们一般有一个原则: 重大决定由 “猪” 来定夺。

我们初入公司，公司肯定希望我们都是猪这类的，全身心投入到项目中去。我们的任务也就是做好“猪”的角色。

RASCI 模型⚓︎

RASCI模型明确了团队中的各个角色及其相关责任。笔者认为在任何一个团队中都会有这样的分工，可以和动物饭店以及上一节的木头的团队故事中的人物做类比（这里丝毫没有人格褒贬，只是一个角色上的类比）。

名称	角色	动物类比	人物类比	人数
R - Responsible	负责，具体执行	猪	研究员、工程师	3
A - Accountable	管理，掌管全局	老虎	各个 Manager	3
S - Support	支持，配合工作	鸡	PM 和实习生	3
C - Consulted	顾问，决策支持	狐狸	Lead 技术指导	1
I - Informed	知情，参考指导	鹦鹉	市场和商务人员	2

微软团队工作故事分析⚓︎

有了以上的动物故事和 RASCI 模型做基础，我们可以对木头在团队中的故事做出清晰的分析。

我们先简单看一下人数问题。从表中可得，实际工作的有6人（3名研究员、工程师，1名PM，2名实习生），其它6人属于管理团队。而实际写代码的人只有3人，即研究员和工程师，其它3人属于支持、指导人员。

这样看起来，是不是微软的组织管理太过冗余了呢？我们看看下面的分析就知道了。

研究员和工程师⚓︎

工程项目实施的主力，解决软件工程中所有的技术问题。在一段时期内（比如半年或两年），他们的主要时间都会花在这个项目上。质量好，速度快，下一年得到升职的机会就比较大。

管理者⚓︎

其实大家可以看到，在故事中各个管理者并没有参与技术讨论，实际上他们掌管的项目很多，没有时间精力参与到某个项目的细节讨论中来，只是在项目启动的时候定个方向，给成员们打打气。

在微软，这是司空见惯的，一线管理者不会参与到细节讨论。在一些小公司，有可能管理者直接参与到细节讨论，这也可能是因为中层力量薄弱，或者层级较少。

PM 和实习生⚓︎

这两个角色是对团队的支持，很重要。PM做项目管理，与客户沟通，与公司内其它组织沟通等等。实习生在 Mentor（导师）的指导下，做一些被分解成单元的小任务，按照微软实习生的衡量标准，应该是可以完成的。但是实习生能不能写 Production（生产、上线）的代码，就不一定了，一般是导师把实习生的代码按照标准“包装”成生产代码。

Lead 技术指导⚓︎

实际上这个角色在微软不常见，大家可以看到 Lead 只是提出意见，并没有动手写代码。在这个项目中，Lead 确实提出了很多自己的见解，有些是有用的，可以帮助提高产品质量的；但有些却是节外生枝的考虑，让每个环节的决策都特别困难，增加了工程师的工作负担。

但如上所述，最终的重大决定权在“猪”，工程师可以参考 Lead 的意见，但是不一定采纳，只要拿出理由来即可。

市场和商务人员⚓︎

他们在开始接触联系客户，签订合同，到后期执行时，不需要提出意见，除非是客户需求与合同不符。但是项目的任何进展都应该让他们知道，当他们有意见时，通常会直接给予管理团队，而不是给与工作团队。

参考资料⚓︎

[1] The Chicken and the Pig, Wiki Pedia, https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig
[2] 《构建之法》，邹欣
[3] RASCI Responsibility Matrix, https://managementmania.com/en/rasci-responsibility-matrix