自我驱动或者自组织团队是现在软件公司努力建设的方向，自我驱动也常常挂在嘴边。但以我的观察，自我驱动或自组织团队建设并没有带有真正的团队生产力提升，反而很易遇到发展瓶颈！
可以简单地通过几个方向来审视我们打造的自我驱动团队，生产力、离职率、沟通的有效性(因沟通不畅引起的问题有多少)。不需要使用多少软件度量方法，做为一个管理者也会有所察觉。然后呢？发现了问题却又束手束脚，思来想去似乎就是不知道如何下手整改？
概括起就是一个本质性的问题，管理职能缺失所致。表现在两个方面:生产力无法提升和管理粗放。
许多人一提到软件开发，就想到敏捷，好像软件工程师个个都是自由斗士。再加上对敏捷方法所谓"反管理(Anti-Management)"的片面理解，导致上上下下都不知道如何去做了。是不是很像父子俩和驴子的故事？这时候别人的各色说法似乎都有道理，偏偏自己是错的。
显然不应该这样。回故一下Mishkin对孟岩说的"自组织团队"，我概括了一下他所讲的自组织团队的三个要点:
1. 沟通与理解
2. 适当的培训
3. 更高层次的指导
我们怎么做呢！前两条很好做。第一条，就是好吃好喝、一团和气。第二条就是积极组织、狂轰滥炸。这就是中国式的做法，咱们自己的做法。效果和效率再说吧。 第三条也好做，画饼，消费未来。来来，我们一起创业吧！至于你现在的问题，你应该自我驱动啊！
我这是夸大了一点，不会是完全这样。
这些好像似曾相识！以前人人争先前(自组织)的年代，天天学习(培训)，同吃同住，多有阶级感情(沟通)。所以这对咱们中国人来说，不用多说都会做。
2. 制度上要保证"高层次指导"落地。
回到软件开发领域，什么是高层次指导？就是实实在在的方向。很多公司都有KPI，想想它起到作用了吗？或者它应该起什么作用？自上而下地细化和落实KPI，以保证达公司预定的战略或经营目标。一层层下来之后，到工程师头上还有多少项是有实际意义的？
概括地说两条:
1. 系统规划技术、人员的发展。
2. 落实结果导向。
关键一点，自我驱动团队不应当放弃有效地管理，只是要调整罢了。软件团队管理上包括行政管理，开发流程管理(特别是配置管理)，产品管理，和项目管理。我们不能只在这些点上用力。弹性的行政制度，到位的衣食住行上的行政服务，甚至还提供帮助终生大事的机会，这是在行政上的管理。完善的开发流程和配置管理也样样齐全，项目流程，产品流程也是一套一套的来，这是研发管理。还有一条应当单独列出来思考的是技术管理，也是对工程师个人最为重要一点。约束理论告诉我们，组织或系统的能力取决于其短板。只有找到短板所在，再对应加以提升才能有效地改善组织的能力。
我以前写过一篇拙文<<团队建设之能力账户>>,也转过一篇<<教导，职业经理人最重要的能力>>。关键的要点是主管要发挥领导力，评估出自己团队的目标及技术方向，再根据能力和志向设定不同的定位和目标。让一个工程师不知何去何从或放任自流就是管理上的浪费。平时不注意，忙时再加班也补不回来。而工程师也可能陷入盲忙的状态，年底回头一想，好像全在解Bug了。自己想做的事，也全是懂个皮毛。这不是浪费吗？
实际操作上，可以参考：
1.首先要理解团队的职责和未来的职责，特别是系统地理解产品和技术对团队的要求。
建议用一个表或一个思维导图整理出团队所需要技术点。
2. 盘点团队的能力和志向。
3. 在团队中加以定位，定义目标。
4. 在工作安排上，安排合适的人去做。要灵活兼顾项目要求和人才培养。
5. 保持周期性的面对面沟通，及时发现问题，修正问题或方向。
至于结果导向，只要想想人人都有，就是没有。
总之，团队管理很不容易。主管要有能力、有眼光，对下属既要指导，又要给空间。既要细致有效，又要避免微管理。如何把握这个度？想想为什么优秀的领导不是培养出来的！好在多思考能让我们找一些方法来补自己的拙。
这就是我的思考，希望这个思考不会止步!
*最近关于两种软件公司的文章很火啊，可是多少有些偏了。电影剧组里很自由吗？其中角色划分仍然是很细致的，也常常是专制的。团队中的角色绝不是那么清晰、简单的就算定义好了。我们常说团队如何如何，那运作的结果和表现，内部如何运作呢？ 与其想办法复制别人的成功，不如好像想想现实中的问题。
自组织团队的困境
问题在哪里？ 我今天终于恍然大悟。这也许也是敏捷在中国一直处于困境的原因之一。简而言之，在自我驱动团队建设上缺少方法和执行力！思想是别人的，而做法仍然是自己的。可以简单地通过几个方向来审视我们打造的自我驱动团队，生产力、离职率、沟通的有效性(因沟通不畅引起的问题有多少)。不需要使用多少软件度量方法，做为一个管理者也会有所察觉。然后呢？发现了问题却又束手束脚，思来想去似乎就是不知道如何下手整改？
概括起就是一个本质性的问题，管理职能缺失所致。表现在两个方面:生产力无法提升和管理粗放。
许多人一提到软件开发，就想到敏捷，好像软件工程师个个都是自由斗士。再加上对敏捷方法所谓"反管理(Anti-Management)"的片面理解，导致上上下下都不知道如何去做了。是不是很像父子俩和驴子的故事？这时候别人的各色说法似乎都有道理，偏偏自己是错的。
显然不应该这样。回故一下Mishkin对孟岩说的"自组织团队"，我概括了一下他所讲的自组织团队的三个要点:
1. 沟通与理解
2. 适当的培训
3. 更高层次的指导
我们怎么做呢！前两条很好做。第一条，就是好吃好喝、一团和气。第二条就是积极组织、狂轰滥炸。这就是中国式的做法，咱们自己的做法。效果和效率再说吧。 第三条也好做，画饼，消费未来。来来，我们一起创业吧！至于你现在的问题，你应该自我驱动啊！
我这是夸大了一点，不会是完全这样。
这些好像似曾相识！以前人人争先前(自组织)的年代，天天学习(培训)，同吃同住，多有阶级感情(沟通)。所以这对咱们中国人来说，不用多说都会做。
自组织团队怎么会这么容易打造？
且不论前两条如何，第三条才是最关键的，难在于两点:
1. "高层次指导"要正确、可行。2. 制度上要保证"高层次指导"落地。
回到软件开发领域，什么是高层次指导？就是实实在在的方向。很多公司都有KPI，想想它起到作用了吗？或者它应该起什么作用？自上而下地细化和落实KPI，以保证达公司预定的战略或经营目标。一层层下来之后，到工程师头上还有多少项是有实际意义的？
除了KPI, 还有各级主管对下属的指导是不是充分？一个工程师努力地花了一周研究一个题目，而这个题目是他自己发挥主观能动性找到的，但未必对公司有什么帮助。这对于公司而言，至少是浪费了两周的人工。虽然你也可以说未来会有帮助的，但显然是缺少了系统的规划和组织的，这是一种无序产生的浪费，很可惜。
所以，有了KPI，有了岗位职责，就能保证团队的产出吗? 没有在共同目标上形成合力，团队的战斗力就会容易遇到瓶颈。
对策和建议
了解了问题，就要思考对策。概括地说两条:
1. 系统规划技术、人员的发展。
2. 落实结果导向。
关键一点，自我驱动团队不应当放弃有效地管理，只是要调整罢了。软件团队管理上包括行政管理，开发流程管理(特别是配置管理)，产品管理，和项目管理。我们不能只在这些点上用力。弹性的行政制度，到位的衣食住行上的行政服务，甚至还提供帮助终生大事的机会，这是在行政上的管理。完善的开发流程和配置管理也样样齐全，项目流程，产品流程也是一套一套的来，这是研发管理。还有一条应当单独列出来思考的是技术管理，也是对工程师个人最为重要一点。约束理论告诉我们，组织或系统的能力取决于其短板。只有找到短板所在，再对应加以提升才能有效地改善组织的能力。
我以前写过一篇拙文<<团队建设之能力账户>>,也转过一篇<<教导，职业经理人最重要的能力>>。关键的要点是主管要发挥领导力，评估出自己团队的目标及技术方向，再根据能力和志向设定不同的定位和目标。让一个工程师不知何去何从或放任自流就是管理上的浪费。平时不注意，忙时再加班也补不回来。而工程师也可能陷入盲忙的状态，年底回头一想，好像全在解Bug了。自己想做的事，也全是懂个皮毛。这不是浪费吗？
实际操作上，可以参考：
1.首先要理解团队的职责和未来的职责，特别是系统地理解产品和技术对团队的要求。
建议用一个表或一个思维导图整理出团队所需要技术点。
2. 盘点团队的能力和志向。
3. 在团队中加以定位，定义目标。
4. 在工作安排上，安排合适的人去做。要灵活兼顾项目要求和人才培养。
5. 保持周期性的面对面沟通，及时发现问题，修正问题或方向。
至于结果导向，只要想想人人都有，就是没有。
一个公司里层层主管都是非常关键的，正是他们将公司目标转化为团队目标，再转化为工程师的个人目标，反过来推动公司目标的实现。可是主管能用"应当自我驱动"来指导吗? 必须了解所谓层次是有不同理解的方向的，但又相辅相成。正是对不同层次的理解才能带来完善的系统。
总之，团队管理很不容易。主管要有能力、有眼光，对下属既要指导，又要给空间。既要细致有效，又要避免微管理。如何把握这个度？想想为什么优秀的领导不是培养出来的！好在多思考能让我们找一些方法来补自己的拙。
这就是我的思考，希望这个思考不会止步!
*最近关于两种软件公司的文章很火啊，可是多少有些偏了。电影剧组里很自由吗？其中角色划分仍然是很细致的，也常常是专制的。团队中的角色绝不是那么清晰、简单的就算定义好了。我们常说团队如何如何，那运作的结果和表现，内部如何运作呢？ 与其想办法复制别人的成功，不如好像想想现实中的问题。
转载请注明出处: http://blog.csdn.net/horkychen
仓促记录下来的，请多多指正！
作者：HorkyChen 发表于2013-2-22 0:15:17 原文链接
阅读：153 评论：0 查看评论