康威’s Law 这是一个古老但有用的想法:软件开发团队的组织结构反映在他们产生的代码中。例如,创建一个“platform”开发团队和“applications”团队通常会使用Platform API。关于是否有趣的模块属于一个组还是另一个组的争论(“我们的团队可以建造它”“另一个团队去做有趣的事情”)。技术架构逐渐看起来像组织结构图。从广义上讲, 我们如何组织人员和划定团队对我们生产的产品产生真正的影响.

在进行产品分配时,我发现此概念很有用。产品经理(像我们所有人一样)最深刻地思考问题的各个部分’已分配给他们。他们自然地认为自己的部分很重要,并且大多认为“in the box” that we’ve given them.

Imagine, for example, the Director of 产品管理 for an e-commerce solution who aligns her 4 产品 managers with the 4 development teams covering (a) buyer experience and workflow, (b) pricing, check-out and financial transactions, (c) seller sign-up and reporting, and (d) scalable 平台 architecture. 什么 should she expect?

  • 子产品箱深层思考“inside the boxes.” 负责买家经验的产品经理和开发团队(管他呢)迅速成为他们所在领域的专家。他们吃喝玩乐,梦想着消费者的工作流程。他们更多地专注于解决方案的一部分,而不是公司级的目标。毫不奇怪,这四个团队各自都有自己的积压工作,直到明年。
  • 隐式资源分配。 通过组建四个旨在在中长期保持在一起的专家团队,我们’我们默认将25%的技术精力投入到体系结构上,将25%的精力放在卖方工具上,等等。想象一下,如果我们对下个季度的全机可扩展性战略需求有战略性的话。我们的产品管理总监可能会动容–来自高级工程师和产品经理。为什么其他团队在扩展方面的效率只有一半时,为什么要搁置他们急需的用户体验改进或卖方门户升级呢?
  • 团队边界上的技术/政治问题。 可以预见的是,定价团队将购买量下降归因于消费者工作流程中的问题,工作流程团队将其归咎于价格查询不一致。两个开发团队相互怀疑,他们的产品经理感到有责任站出来。看似合理的技术解释恰好支持双方’的情绪状态。
  • 重复计算收入。 产品经理知道,即使消费者购买可以’(仅)体系结构或(仅)体贴的用户体验或(仅)定价引擎来完成。每个产品经理都认为自己的工作非常有价值……并根据该信念建立业务案例。因此,我们经常高估改进的影响。每个团队都将收入增长归功于其工作,并预测更多的增长。

拆除墙壁什么’一位产品主管要做什么?主任推倒了墙。她对产品经理进行交叉培训:互相集思广益’s个小盒子(在大盒子外面)。她力求知识上的诚实和现实的商业理由。她发现了促进更大利益的机会:偶尔混合任务,在人造产品边界上分享成功,并鼓励她的开发方同行也这样做。有时,她必须解决一些棘手的跨境问题,她的个人产品经理可以’自行谈判。有时,当策略遇到现实问题时,她要求跨团队重新分配工作。她是上级仲裁员。

所有这些都需要期待。 我们的女主人公知道组织必须有一定的分工。然后 每一个劳动分工都可能产生狭narrow的思维,边界冲突以及资源分配效率低下。 所以她’不断提供广阔的环境并关注问题。让她的产品经理回到更大的视野。鼓掌承认其他团队可能对下一个新员工的需求很大。提前解决问题。精通组织行为。

并且(当然)这发生在每个级别。产品线经理使用他们所有的稀缺资源来推广自己的产品线– and don’分享。业务部门副总裁将人员重新分配到其业务部门中,但从不愿意将人员放弃给其他业务部门。领导跨业务部门举措的高管需要胡萝卜(资源和收入抵免)以及坚持(经常取得进展证明)的举措才能产生任何结果。

因此,无论您处于何种水平,都需要记住自己的作品如何融入更大的整体。注意不正确或过于狭窄的决策。促进产品和开发同行之间的跨境思考和奖励系统。在盒子外面偷看。

声音字节

以产品为重点可以帮助我们在该领域提高生产力和专家水平。它’但是,容易变得过于专业化并失去远见。 定期地, 我们必须提升自己以考虑客户’的端到端问题和整体解决方案.