跳到主要内容

保存的文章

资源有限,这是关于流动 -亚傅体育app 不是竞争

杰斯豪耶|龙头
杰夫豪伊 管理顾问
阅读: 资源有限,这是关于流动 -亚傅体育app 不是竞争

拔河

组织努力对其开发资源进行精简,但当涉众竞争这些开发资源时,这可能对组织有害。亚傅体育app关键是管理工作流程。

您如何优先考虑项目,以便组织专注于提供价值与资源的竞争?亚傅体育app

你可以通过在执行层运行看板来实现这一点,看板将整个投资组合中的团队待办事项细化到具体的任务级别。

竞争发展资源亚傅体育app

最近,我与一家开发移动应用程序的小公司合作。这家公司的首席执行官对现金流非常敏感,他知道他需要提高组织的可预测性和生产率。当他阅读和听说敏捷时,他接触到了一些伴随敏捷“推销”和相关的“高效团队”概念的常见指标,这些概念包括提高效率500%和提高团队士气,以及其他好处。这些启示和用“高效”的工具授权他的团队的真实愿望说服了CEO推动他的组织使用敏捷技术。

在组织的几位领导参加了CSM和CSPO课程后,团队重组为“跨职能团队”,由Web、iOS、Android和API开发人员组成,专注于为客户(通常有Web组件和iOS/Android应用程序)构建集成产品。听起来不错,对吧?他没有足够的QA人员在每个团队中安排一个,所以他们组成了一个独立的QA团队,采用后续的“强化Sprint”策略来测试可交付成果。不完美,但很普通。公司有十个主要客户,由三个销售人员管理。他们试图让一个销售人员与一个开发团队保持一致,以减少人员流失率,并让团队专注于为更小的客户群体构建产品。乍一看,这是一个不错的第一次尝试,旨在培养专注于一组产品的跨职能团队。

每个团队都有一个与之相关的待办事项列表,这些待办事项列表可以追溯到团队支持的产品和客户。待定项从Sales团队成员定义的高级Epics开始,并由团队成员分解故事。每个Sprint的目标是让团队专注于为客户提供一个“产品套件”(将交付Web、服务和移动应用程序)。在一个团队支持三个不同销售团队成员的目标的环境中,你能猜出这个团队在实现这个目标方面有多成功吗?

结果是,在几个Sprint中,Sprint的backlog被多个客户的多个产品的多个故事挤得水泄不通(以免三个销售代表中的任何一个看不到一个或多个Sprint的“销售”进展)。在持续的上下文切换模式下,开发团队很快就陷入了混乱。更少的时间用于分解故事以处理混乱和“加速”的节奏。更多的时间被浪费在寻找故事的细节上。对团队来说,这比以往任何时候都更忙,但看起来比过去管理和销售的“瀑布”方法更低效。每件事都是头等大事,迟到,交付质量问题。敏捷做了什么?显然,如果这家公司想要管理他们的现金流或保持可持续的增长速度,他们就不能采用敏捷。无论如何,这就是管理的思想。肯定感觉不到生产率的500%+增长——敏捷肯定是失败的。

整个团队都很沮丧。他们做的每件事都是正确的——写用户故事、做Sprint计划、每日站立、演示和回顾。他们练习了两周的冲刺。他们觉得忙。他们看到进步。他们试图更好地估计每个Sprint,并缓冲“意外”,以适应来自客户或发现的不断变化的需求。但他们也开始希望结构化的瀑布式计划和日期驱动的交接能有“美好的过去”。自我组织的团队、较轻的文档负担、更紧密地管理自己的工作的能力都不值得承受不断感到压力和失望的痛苦——与“高效表现”的目标相去甚远。

在这种情况下你会怎么做?

我会建议你开始在这种情况下是创造史诗在销售层面上为每个客户/产品和运行它们通过一个基于优先级的几个标准看板time-to-cash-flow等战略措施(比如那些可以用于识别重复出现的业务,战略关系,亚博vip9通道等等)-根据公司的价值管理积压的工作。我甚至建议你从一个基于现金流的开始。这个销售级别的看板成为开发团队待定事项的馈线队列,限制了流程中的工作,提高了整个销售(收入产生)组织的优先级,并帮助识别组织交付能力中的瓶颈。关于注入新的“史诗”(例如,为新客户或现有客户提供新产品)的对话必须发生在销售团队和执行层,才会影响到交付团队。每个销售代表都有机会说:“看,我在飞行中或预定工作中有这个工作。如果你想要添加一个新的史诗,它会导致这个工作暂停。告诉我这对公司有什么好处。”关于现金流、优先级和承诺的讨论被提升到组织的正确级别。我们已经让销售部门在每一次销售影响到我们的开发/交付团队之前,对每一次销售进行论证和优先排序。 This will allow the organization to prioritize their limited resources around what is most valuable. The world of managing expectations, contracts and sales would need to evolve around this, but we’ve implemented a mechanism to focus on Cash Flow with a limited capacity. Metrics at this level would allow the organization to make a real case for managing expectations at the current capacity, model revenue/cost options to increase the capacity of the teams and make decisions about the long term.

现在,你们中的一些人将要和我讨论你们将对团队结构做出的改变。我也会做出改变。但出于一些原因,我不打算在这篇博文中重点讨论这些问题。首先,我相信,如果没有解决跨组织的工作流程管理问题,在这种环境中仅在团队级别进行更改是毫无价值的。第二,对交付团队结构的改变并不是我的职责;当然,我会提出一些建议,提出一些想法,但我的敏捷教练希望回到让团队检查他们的能力,根据有意义的情况调整结构,并围绕结构的未来迭代进行自组织。

要解决潜在的问题,第一步是让Sales在有限能力的环境中根据关键业务驱动因素(在本例中是现金流)做出优先级决策。亚博vip9通道消除对资源的竞争,为团队设置较少的上下文切换,并开始识亚傅体育app别瓶颈、增长机会和系统中的限制,以便随着时间的推移解决。工作流程得到改进,衡量进展(以及支持增长的需求)的指标开始出现。团队能够基于组织层面的优先级专注于交付(而不是内讧和与三个或更多的销售代表谈判谁的销售在这个或下一个Sprint中更重要)。

它可以工作吗?

是的。这是另一个公司的例子,产品经理在争夺他们的开发资源。亚傅体育app这个组织有16个开发人员在40个产品上工作。有40个产品所有者在争夺16个开发人员。我们创建了一个产品负责人团队,其中有一个首席产品负责人。这就形成了一个“产品漏斗”,其他39个产品经理的想法和需求必须通过产品负责人来获得开发资源。亚傅体育app

有了这个构造,他们被迫根据组织的优先级来管理投资组合,再加上发布计划,平衡能力和需求。这是一种非常不舒服的情况,因为产品管理组织总是承诺比他们实际能做的多很多倍的工作。当他们开始用交付能力来衡量整个需求组合时,他们意识到只有能力支持他们的10%想要在他们的目前的状态下提供。想象一下,作为产品的高级副总裁,看到了这个现实 - 看到你的能力只有10%所需的痛苦。想象一下痛苦,但想象力...优先考虑到哪个优先考虑,如何与技术团队的领导能力,以提高能力,如何在制定客户预期方面沟通销售领导。强迫这种投资组合风格的计划并强迫组织能够一起工作的痛苦是痛苦的吗?绝对地。它是否存在似乎不可逾越的问题?是的。团队是否能够解决能力问题,最终提供所有40个产品经理的需求和需求?是的。

结论和我对你的挑战

敏捷不仅仅是Scrum。敏捷不仅仅是跨职能团队。敏捷是一个管理工作的系统,并持续改进该系统,以管理工作背后的流程和交付引擎。这不仅仅是关于人;这是系统本身的问题。如果你正因为类似于这里提到的原因而与敏捷斗争,我希望我已经启发你看看你是如何组织确定项目的优先级,以及如何管理将优先级的工作传播给开发团队。如果你没有管理看板,我建议你去做(无论是在板子上的便签,Trello或其他更复杂的工具上,只管去做)!如果您擅长在整个组织中划分优先级,或者在项目组合级别上运行看板,那么如何改进它呢?

现在轮到你了!您有一些改进优先级的其他方式是什么?

下一个;了解您的项目组合中的风险

评论(4)

  1. 克里斯汀•
    回复

    嗨,谢谢你的帖子。

    我只是没有得到这个位:“Sprint Backlog从多个客户中充满了多个产品的多个故事”

    什么组织会把不同产品的故事混在一起?对于一个经验丰富的团队来说,这是一个多么疯狂的想法啊,更不用说任何一个刚接触敏捷的团队了。首先要做的是保持独立的backlog,并为每个产品确定一个sprint ?当他们这样做的时候,将sprint的长度减半,这样就可以每周为单个产品交付一次sprint。这样,团队就可以专注于交付一个产品的业务目标,并在任何时候满足一个产品所有者。亚博vip9通道当这个“冲刺”运行时,项目经理、产品所有者(包括销售)和其他涉众(包括客户)是时候完善他们自己的待办事项列表并做好准备,这样当“冲刺”开始时,就能以最大的效率完成任务。我想说,大约25%的努力可以投入到这个阶段,所以它不是“浪费时间”。

    然后,团队可以在一周的预定义的时间内从他们的冲刺中退出,所以没有惊喜(我们喜欢在星期三下午做一小时),并在出现的故事上进行规划扑克(或任何其他尺寸的会议)以下冲刺。这个叶子周四和星期五为非生产团队进一步改进并优先考虑他们的冲刺和几次冲刺后,他们可以基于对生产团队吞吐量的良好理解(只要他们捕获)数据)。

    从我的经验来看,团队对球队有明确的了解,并允许他们在没有竞争团队的情况下允许他们努力工作。然后,他们可以共同努力,在短时间内满足这些目标,并在本周结束时留下满足,以至于他们对他们一直在努力的产品的重大改善。

    回复
  2. 杰夫豪伊
    回复

    Kirsten,关于积压的伟大观察 - 无论如何询问问题“为什么有人这样做”以及提供以周到的方法管理积压的选项。这么多的团队首先“学习”Scrum或Kanban,以至于他们必须针对1个积压 - 并得出结论,他们将扔掉一切,厨房汇总到一个列表并称之为积压 - 即使它需要持续的上下文切换。通过规划,协调和清晰度地设计对主题和“价值包”来管理流程和焦点的概念,以管理流动和焦点“和”价值包装“肯定会确定将敏捷实践纳入更大的成熟度水平的阶段。Like you, I’m a big fan of pre-scheduled, regular and recurring times for the relevant team members to participate in Story Telling, Backlog Grooming and other activities that allow us to practice good product and project management as part and parcel of our agile practice. Thank you for chiming in!

    回复
  3. Jerilyn
    回复

    嗨杰夫,这句话让我感到震惊:因为他们开始衡量衡量提供能力的整个需求组合,他们实现了实现能力只支持他们想要在当前国家提供的10%。

    我想知道他们是怎么测量的。他们使用故事点了吗?他们有实际的开发团队评估这些史诗吗?

    回复
    • 杰夫豪伊
      回复

      好问题Jerilyn !epic被开发团队分解成Stories并在Points中进行评估。组织已经习惯了谈论点数而不是时间,并且理解了速度的概念。看看你的吞吐速度,比如说,100点/ sprint是非常有用的。当你看到有2000个你想在一个月内“完成”的待办事项时,什么是可能的,什么是不可能的,就会变得非常清晰——这样就可以讨论优先级和权衡。我一直非常喜欢让那些完成工作的人评估工作。这些承诺比让第三方在他们不负责交付的点的粒度上“评估”工作要可预测得多。其他亲和估计,如t恤尺寸或理想周数,可能对进一步的规划和路线图链有用,但在需要承诺的级别时就没用了。

      回复

留下你的评论

您的电子邮件地址不会被公开。必需的地方已做标记