自我驱动或者自组织团队是现在软件公司努力建设的方向,自我驱动也常常挂在嘴边。但以我的观察,自我驱动或自组织团队建设并没有带有真正的团队生产力提升,反而很易遇到发展瓶颈!
可以简单地通过几个方向来审视我们打造的自我驱动团队,生产力、离职率、沟通的有效性(因沟通不畅引起的问题有多少)。不需要使用多少软件度量方法,做为一个管理者也会有所察觉。然后呢?发现了问题却又束手束脚,思来想去似乎就是不知道如何下手整改?
概括起就是一个本质性的问题,管理职能缺失所致。表现在两个方面:生产力无法提升和管理粗放。
许多人一提到软件开发,就想到敏捷,好像软件工程师个个都是自由斗士。再加上对敏捷方法所谓"反管理(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
仓促记录下来的,请多多指正!