厘清结构混乱的产品团队

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

团队是高层的一个 VP 组建起来的，此人曾是最早的开发人员之一。我们后来有了 QA、开发人员、业务分析师和技术支持。技术支持基本上是一个独立的实体。我们跟他们密切合作，得到他们提供的数据，不过他们是自负盈亏的。 我们在美国有 18 个人，另外有 30 个人构成一个离岸团队（这两个团队在同一个时区）。我们有两个业务分析师（不久就扩到了 4 个），3 个 QA，其他都是开发人员。在离岸团队中，有 20 个开发人员和 10 个 QA，不过他们的角色要更为灵活。我们还有两个基于美国本土的承包商担任开发任务。

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

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

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

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

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

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

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

查看英文原文： Structuring Messy Product Teams