工作环境：某日本大公司，公司一侧的3排桌椅空出。一桌坐1人，稍显拥挤。

工作目标：

对cobol自动转成Java的batch程序，进行apache spark化。

具体工作流程，是先解读cobol程序，然后写一个简略的设计书，而后根据设计书，写程序。

团队概要：

30人的大团队，全部坐在一个岛，由5个小组长领导，一组坐一排。

五个小组长的特征：

全桑：朝鲜族人，39岁，有领导力，技术力稍欠。

宋桑：东北人，20后半，日语强，技术力尚可，现场管控能力强。※因年轻容易被团队老鸟轻视

马桑：山西人，40岁，北化工毕业，技术尚可，性格平和，身体欠佳。

董桑：30后半，技术学习能力强，身体好，临事易惧，多谋能成。

森：日本人，cobol技术26年，Java技术不会。做过部长。

五人中，只有森有丰富的cobol经验，董有半个小时的cobol经验，apache spark对大家都是新的挑战，但是好在有实例程序。

团队成员的特征：

小杨：2012年毕业，来日一年，日语较差，技术很强，出活能力非常强。优秀的先锋。

小冷：吉林大学数学系毕业生，30前半。日语较差，技术学习动力和能力都很强。

陶桑：30前半。日语很好，技术也比较不错，稍微安静，因为3月后要回国，所以干劲稍差。

徐女士：30前半。日语技术均尚可。与先生同为成员，两人经常私下切磋。非常能干，偶尔有点攻击性。

小韩：20后半。沈阳人，害羞，可爱。自尊心有点强。不怎么说话，但其实对情况都有掌握。

其它成员：未掌握。

包括组长和成员，基本上cobol和apache spark没有实际经验。因此，学习动力和学习能力就非常重要。

需要做成的这些batch，input主要是file和数据库的数据，output为文件。也就是说，对input的数据根据某种规则进行编辑，进行output。

因此了解编辑规则也是关键。而越早了解规则，越早能对情况有所掌握。因此在写方针书的阶段就了解规则是最理想的。当然，这就需要小组长调动全团队的战力，来对每个成员进行程序解读的支持。

实际的项目进展情况：

董团队的项目进展超前。

其经验：

1.编程之前写方针书，明确规定，对关键部分要写清楚，如果可能，对数据的流向有个简单的说明。

2.组长本身对技术的学习能力和学习动力强，对团队的整体进度有很强的提前完成意识。所以团队成员出现技术难题时，能实时跟踪支持。

森，马团队：

出现进展迟滞。

原因：

1.方针书编写完全是一种形式，关键部分完全没有写清楚。团队成员自己写完方针书，也不知道自己做了什么。甚至程序写完，还搞不太清楚的成员也有。之所以出现这种情况，小组长自身认为方针书只是个概要这种意识是个很大的问题。

2.组长的学习意识不够，并且认为这个东西很简单，陷入一种盲目的乐观。比如x桑，在项目开始的前两天，完全没有解读代码例子，对工作将如何进展，团队中可能出现的问题，完全没有心理准备。却说"这个很简单"。后来团队中出现了很多问题，让x组长陷入很大的被动和心理压力。

3.组长对团队成员的特点和相应的战力布置不够。

比如森团队的冷桑，技术能力非常强，是很优秀的先锋。应该让此人做先头部队，调查出现的技术难题。但组长没有这种认识，导致了战力的浪费。

全，宋团队：

有一定程度的迟滞，加班较多。

问题点：

全团队，有一位疑似技术高手，后经董确认，此人有一定的技术解读能力，但性格异常固执，不能承认自己的错误，沟通非常困难。又因为小组长本身的程序解读能力较差，还以为此人是技术高手。

整体的其它问题：

因为全团队组长之间，技术学习强的人之间，有充分的交流。

因此各组的经验和教训可以实时地应用到各自的团队中。

而技术强人之间的交流解决了大部分的技术难题。但这种知识的共享非常不够。

造成这种的原因：

1.森不会中文，其团队成员不会日语的很多。所以对各成员的情况掌握不够。而各成员之间又没有过合作的经验，陷入单兵作战的情况比比皆是。

3.董对技术学习和自己团队成员的进度非常关心，对其它团队出现的技术难题也实时掌握，但不关心其它团队成员的进度。

4.森，马团队，小组长的技术支持欠佳，成员容易陷入迷茫，干劲欠佳，士气低下。

对策：

1.应该给予董更大的权限，将董组的成功经验复制到其它团队。

2.小组长与技术强人成员之间进行不定期的交谈，小组长直接掌握知识，

或者给予技术强人较大的权限，使其知识尽快被更多成员使用。