DevOps转型需要这样的自治产品团队
本帖最后由 陈小宝 于 2020-8-4 21:18 编辑我一直认为产品管理是一项团队运动（product-management-team-sport/）。但是，只要一个组织中有多个团队并且需要它们彼此交互，就会引入摩擦。团队之间的这种摩擦，就是我们现在会存在如此多项目管理书籍和方法、收件箱和发件箱、依赖项管理等等的原因。摩擦会杀死动因，摩擦会杀死速度。
如果你删除团队之间的依赖关系并引入自治产品团队，就不会产生摩擦。
一、跨职能团队
首先，要确保每个团队都有执行目标所需的全部技能和专门知识。除此以外，你的团队是否还有诸如客户成功、市场营销、合规等职能的需要？请详细考虑团队真正需要什么技能以取得成功，并考虑如何绘制出多样性，确保团队拥有不同的背景、经验和见解。
下面的蜘蛛图是一个供参考的模型示意，当你开始确定团队成员时，你可以快速查看他们有哪些重叠，在哪些方面具有不同的经验和技能互补，以及哪些地方需要填补。
这种多样性，不仅包括性别和背景，还要有技能、经验和背景，这对于消除对其他团队的依赖至关重要。并且，团队中涉及的背景和观点越多，就越有可能拥有同理心去理解客户。
我最喜欢的案例来自在线货币兑换平台Transferwise。它的团队负责新增货币兑换类型，例如将USD转换为GBP。可以想象，这比仅在下拉菜单中添加选项要复杂得多。这意味着要在目标国家/地区开设银行帐户并更新条款，以符合当地的反洗钱和证券法要求。
在任何其他组织中，这恐怕都需要团队去法律部门寻求有关条款和限制要求的帮助，然后去银行部门寻求与帐户有关的帮助。
但是Transferwise的看法有所不同。在Transferwise，他们在团队里不仅拥有设计、工程和产品，也有银行家和律师，并嵌入到团队中。这意味着团队成员无需去另一个团队或是部门寻求帮助，而是可以专注于完成自己的目标。
相比之下，我最近遇到了一位出色的数据科学家，他曾在《财富》 50强公司任职，他自豪地宣布自己曾在研究与洞察部工作。想象一下，负责研究和见解的部门，是不是听起来棒极了？整个部门！汇集这么多聪明的人和惊人的资源来进行开创性的客户研究、人种学研究、调查、数据收集等，这应该是多么惊人的研究啊！
但是，仔细一想，这事实上是一个部门壁垒引发的官僚噩梦。思考一下，禁锢的资源，在与所有其他部门之间进行共享时所需的各种申请表、优先级和批准流程。再想象一下，为了进行研究所需的业务案例而建立的商业案例…
二、自治
我们并不是在棉纺厂或工厂工作，为什么我们要使用它们产生的管理风格？指挥和控制的模式，只有当所有的知识和技能仅掌握在少数的高层管理人员时才合理，而此时人力资源仅仅是字面意义上的资源，因此可以加以管理。
我们今天使用的大多数敏捷方法和精益方法都来自丰田生产系统。如果你设计了一辆汽车并希望它尽可能的便宜，可以高效且无错误地制造它，那么采用丰田生产系统会很棒。但是我们别忘了，一开始设计汽车的团队是不能那样工作的，以生产系统的方式管理设计团队是无法奏效的。
归根结底，你的团队比你更聪明，拥有比你更多的信息，比你更接近问题，比你更接近客户。那么，为什么需要你告诉团队该怎么做呢？
相反，我们需要增强团队能力，我们需要拥护自治，我们需要让团队利用所有这些惊人的知识，经验和技能来持续的解决客户问题。
2.1 动机
大多数人认为，激励的最佳方法是像金钱这样的奖励，即胡萝卜加大棒的方法。Daniel H. Pink说，这是一个错误。在他的著作《驱动力》一书中（并且也在TED有精彩演讲），他借鉴了过去四十年的科学研究，认为动机的关键是人类对自己生活的深刻需求。
他的研究表明，一旦你被支付了足够的薪水，额外的财务激励措施就不会使个人或团队更有动力，更具创新性或感到更加成功。
取而代之的是，我们受到自治、精通和目标的激励。自主是我们渴望自我指导的愿望，它增加了对合规性的投入；精通是提高我们的技能和掌握我们的工艺的冲动；目的是对做有意义的事情的渴望。
2.2 自治意味着保持敏捷
真正的自主权意味着消除任何依赖关系以及对共享资源或中央团队的依赖。正如我们从Transferwise示例中看到的那样，确保每个团队都拥有所需的一切，意味着不必担心依赖于其他团队的优先级。
不仅于此，如果产品的目标得以实现，那么所有团队都应该能够对其进行更改。例如，营销不必等待产品来构建所需的产品，他们应该拥有建立页面，更改用户流或执行其目标所需的其他一切操作的完全访问权限。真正的成长型营销团队不能只停留在目标网页上，他们需要能够按照他们的队列进行完整的转化和留存过程，以了解渠道或 是否真正奏效。
2.3 自治意味着每个人都可以参与其中
真正的自主权还意味着团队中的每个人都可以参与进来，并利用他们的技能来应对团队面临的所有挑战。只有共同创造，我们才能真正将所有这些技能和观点带给客户。
正如Marty Cagan所说：“如果仅使用工程师进行编码，那么你的价值将只有一半。” 我认为这对我们所有人都适用：如果仅使用设计人员堆像素，则只能获得其价值的一半；如果你仅使用产品经理来整理待办列表，那么你只能获得其价值的一半；等等。
因此，请你的工程师参与设计，让你的设计师参与工程讨论，让每个人都参与客户研究。因为洞察力、灵感和出色的产品创意来自未曾预期的角落。
三、一致与自治
现在，许多人听到自治权，就会想到混乱或无政府状态。他们认为这意味着每个人都可以做他们想做的任何事情，建立他们想要的任何东西，然后随心所欲地来去。
但是，成功的自主产品团队的关键是要承担责任。仅当团队不仅感觉到自己是流程和他们所建立的东西的主人，而且他们也感觉到自己对客户结果负责时，它才起作用。因为那样，他们将为这些结果而生或者赴死。
领导力在设定团队执行的愿景、任务和目标方面仍然扮演着重要的角色，以使这些自主团队在其中运作过程中拥有边界和护栏。
领导力最大的职责是确保这些团队之间保持一致，以便每个人都知道他们的目标是什么，他们如何与公司目标联系在一起以及其他人正在做什么。
著名的Spotify小队和部落模型背后的敏捷和组织教练Henrik Kniberg用一张2×2的图表来说明这一点。与任何良好的2×2矩阵一样，你希望位于右上角，因为高度一致和高度自治是你建立创新组织的方式。
四、归纳总结
我记得，作为产品经理，这可能依然是我职业生涯中最骄傲的时刻之一。许多年前，我在伦敦的一家SaaS公司工作，构建协作软件，而我们正在尝试这种新的工作方式。
我们建立了一个由产品经理、前端和后端工程师以及设计师组成的半自治团队，尽管我们是一家小型创业公司，最初只有两个团队，但我们还是按照业务流程对他们的日常工作和重大新功能发布进行职责轮换。
有一天，我们启动了一项重大的新功能，完全重写并重新设计了产品的核心部分，并且首次的，我们在sprint 0的前两天召集了所有相关人员，明确说明了我们打算做和构建什么。
我说的召集了所有相关人员，是指真正的所有人。当然会包括产品经理、工程师和设计师，与此同时还有销售代表、市场经理和客户服务经理。
当我们向所有人简要介绍了项目目标、要解决的客户问题以及针对如何验证该客户问题的研究后，事情就自然而然的发生了。
我没有写什么用户故事，也没有为该功能绘制任何线框图。团队提出了解决该客户问题所需的所有想法，最重要的是，一位初级开发人员提出了基石功能——最终只花了几个小时进行编码，结果是它解决了80％的客户问题。这是我永远无法独自想到的东西。
永远不要忘记，作为产品领导者，你和你的团队一样出色，建立成功的自治产品团队并为他们提供达到最佳状态的空间将是你和你的产品成功的方式。（翰纬科技）
页:
[1]