如何让中国特色的软件团队自主思考

近两年一直在思考这个问题，也特别会留意一些这方面的思路。

几个月前看到过一篇文章，忘记了是不是老外写的了，不知为何记录下来5个英文单词。结合自己实践中的思考发散一下。

situation：当下的形势要理解一致，小团队人数少，沟通容易，好办一些。大团队，层级多，分工细视角多，需要骨牌式层层沟通，有选择的组织宣讲是一个必要的手段。

宣讲不一定是坐在大礼堂中听课，可以是插在早会的几句话，可以插在版本开工的碰头会，也可以是story澄清会议中的开局，甚至可以是一个群发邮件。

这个工作的实施主体是各级主管。从本组织的角度去分解 “我们所面对的形势”。对于员工来说，层级距离比较远的老大们的发言与邮件估计不太会有什么感觉，

但是多少有点信息也能够对整体宏观情况有所传递。越是层级近的主管传递的信息越会引起更多的注意，同时使用的语言也更接近员工的思维。

通过资源线、项目线两个维度的信息传递，员工基本可以获知自己的位置situation是什么。宣讲situation是软性工作，不会立即出成绩，

为何要做也要与各级主管沟通宣讲situation的situation。

task：针对situation各组织（如果是小团队就是每个人）需要分别完成什么样的目标。由于是承上启下，这一部分的思考性工作非常具体，因此还是比较容易操作的。

action：仍然是承上启下，针对task中定下的目标，每个人需要采取什么样的行动去完成。

result、review：最终各级组织通过总结成果与回顾来看做的优劣，有了这个check环节会对前面几个环节的结果有所牵引。

以上这一套操作模式应该说已经比较成熟，不同的公司执行的力度不同，出来的结果有些许差异。但是这不是重点。

东方的历史直到当下仍然贯穿着集权文化,中国的团队特色是被动式的命令分解与执行。软件不同于大多数行业的区别是很多生产要素都不可见。

犹如在大雾中坚守一块阵地，即使是班长，你不去机枪手位置上打两枪都不一定知道敌人是不是上来了，高效的战斗不能只靠Leader。

Leader在团队任务的分解中思考宏观问题，在宏观上把握方向，但是每个具体的战士仍然需要自主决定一些增值活动。

制定task时除了流动的任务型目标还需要附加一个岗位职责responsibility，通过全员公开的方式进行responsibility的review，以评价除了组织分解下的action完成情况，每个岗位是否自发填补了一些需要做但没有规定必须开展的增益活动。这一项可以考虑占总比的20%.初步的构想，有待实践检验.