关于团队结构的随机思考

我之前写过关于团队结构的想法。 我是以产品为中心的团队的忠实拥护者-多学科团队将功能小组的成员纳入同一个团队,他们全都一起创建和发布软件产品。

团队进化

在某个时候,一个团队可能会成长到足够大的规模,因此您希望分成几个较小的小组,每个小组都集中精力。 您仍在构建单个产品,但是现在您拥有了一个以产品为中心的团队,致力于特定功能。 你是怎么来到这里?

  • 随着团队规模的扩大,团队变得越来越难以管理和协调。
  • 产品驱动程序使开发人员专注于其功能似乎很困难。

我已经能够在两种情况下工作:以产品为中心的单个团队和基于功能的多个团队。 我的首选仍然是基于单个产品的团队。 基于功能的团队的缺点超过了优势。

  • 团队变得孤岛,不再专注于整个产品。
  • 没有明确所有者的问题将成为别人的问题
  • 随着创建更多的小组,跨团队的交流变得更加困难。
  • 个别团队的野心无意间稀释了产品的主要重点。

康韦定律告诉我们,组织倾向于根据组织的结构来构建产品。 使用几个专注于特定功能的小组,将对最终产品产生影响。 这可能不是理想的效果。

正念师

我不建议团队人数超过7至10人。 有大量的文献和经验告诉我们这将是不好的,甚至效率会更低。 但是如何划分团队很重要。 有些划分比其他划分更自然:

  • 按平台 (台式机,Android,iOS,Web):确保跨平台的产品具有一定的一致性。
  • 通过前端/后端 :确保双方都是定义交互API的一部分。
  • 通过应用程序/ UI小部件 :确保双方都是定义组件API的一部分。

这些分隔是干净的,易于识别。

特征生存

以产品为中心的团队将我们带回到以产品驱动力为焦点的问题上。 我认为这是一件好事。

通过一个团队实施功能时,您需要善于确定优先级。 向产品中添加所有小功能并不容易。 通过使所有功能争夺优先级,您可以确保最佳功能得到关注。

我相信这会使产品更坚固。


最初发表于 严厉的评论