厘清结构混乱的产品团队

  • Mark Levison
  • 郑柯

2009 年 5 月 7 日

话题:敏捷文化 & 方法

作为敏捷咨询师,像很多咨询师和经理一样,Cory Foy正在对付一个现存的组织结构,该组织结构是并购之后出现的,并且逐渐演变成了一个怪物。团队的状况是:

团队是高层的一个 VP 组建起来的,此人曾是最早的开发人员之一。我们后来有了 QA、开发人员、业务分析师和技术支持。技术支持基本上是一个独立的实体。我们跟他们密切合作,得到他们提供的数据,不过他们是自负盈亏的。

我们在美国有 18 个人,另外有 30 个人构成一个离岸团队(这两个团队在同一个时区)。我们有两个业务分析师(不久就扩到了 4 个),3 个 QA,其他都是开发人员。在离岸团队中,有 20 个开发人员和 10 个 QA,不过他们的角色要更为灵活。我们还有两个基于美国本土的承包商担任开发任务。

成立之后,除了做各自原有的项目之外,团队成员能完成的工作很少,因为没有多少时间。而且,发布周期也是典型的瀑布式生命周期,为期 12-18 个月。也有好的一面,QA 和开发人员已经可以在一起和谐共事了,而且也没有“隔墙扔东西”的心态(throw it over the wall mentality【译注】)。他还指出:在中层管理中确实有些难点,这些中层不习惯在一线产品团队中工作。

Robin DymondInnovel 的管理合伙人,向他们推荐了 Larman 和 Vodde 的Scaling Agile And Lean Development一书,特别建议给功能特性团队和产品负责人看。他也指出:看来发布周时是最明显的问题。

Cory 解释说,无法使用短期发布周期的问题在于:产品要翻译成多种语言。不仅包括法语、西班牙语和德语,还包括俄语和希伯来语等等。

Dave RonneyMayford 科技的敏捷咨询师,他建议:内部的发布周期使用 3 个月,对外的发布周期要视业务需要越快越好。

Hillel Glazer注意到了潜在的管理问题,指出:Cory 是资深管理层引入的,因此他可以报告当前的进度,同时强调道路上会遇到的风险和障碍。Hillel 强调:要用尽量客观的方式来点出这些问题,这很重要。“不要‘责怪’中层管理人员。你也许应该去应对‘有冲突的优先级’或是‘不一致的信息’之类的东西。“

Cory 说,组织会在当前的发布周期结束之后,也就是 8 月份开始实行这些变化。

译注:throw it over the wall mentality,是指把项目或难题抛给其他人或部门,却既不去征询对方意见,也不协调有关交接方面的工作。参见:http://www.wordspy.com/words/throwitoverthewall.asp


查看英文原文: Structuring Messy Product Teams

敏捷文化 & 方法