团队士气直接影响运营:员工觉得自己受重视、有干劲,参与度、留存率和工作质量都会有看得见的改善。要让士气一直保持在高位,管理者得在好几个方面持续用心,包括怎样落实价值观、怎样认可成绩、怎样组织沟通、怎样支持员工成长。下面六种做法,分别对应其中一个方面。 关键要点 公司文化要靠行动持续强化,光喊口号不够 尊重、培养和认可员工,能直接提高动力,降低流失率 开放的沟通和对工作与生活平衡的支持,会让团队内部多一分信任和忠诚度 公司价值观保持高士气,先要让公司价值观落在日常做事上,而不只写在宣言里。如果日常运营和决策中看不到价值观的影子,它也就不再是组织可以依靠的准绳。强化价值观的实用方法:
任务积压:如何有效管理和优先排序
一份结构清楚的任务积压,是每个成功的Agile项目日常运转的基础。写完就不再动的待办清单算不上积压。积压是一份一直在变的文档:它决定团队把精力放在哪里,让团队能跟上需求的变化,也是所有项目成员共同依据的唯一信息来源。有的积压能推着交付往前走,有的只会制造混乱,两者的差别几乎全在于怎么搭建、怎么维护、怎么排优先级。
要点
积压是一个随时调整的规划工具,定义了团队的关注点
有效的任务优先级排序有助于用最少的投入换来最多的产品价值
定期精炼、团队参与和清理过时项目能让积压一直好用
引言
在Agile里,任务积压是一份持续变化的清单,列出团队要做的所有事情,包括新功能、缺陷修复、改进,以及其他任何服务于产品目标的工作。所有项目成员都以它为准,优先级因此公开透明,大家的理解也一致。积压里的每一项都代表着可能交付给用户的价值,所以积压的质量直接决定交付的质量。
为什么这很重要
如果任务积压缺乏清晰的结构,项目就会不断欠下规划上的债,最后变成交付失败。一份维护得好的积压能做到:
- 定义方向: 让人看清项目往哪里走,团队在朝哪些目标努力。
- 确保关注点: 团队清楚眼下该集中做什么,也知道之后几个周期会有什么。
- 提高透明度: 谁都能看到哪些在做、哪些已完成、哪些在排队。软件开发团队要想高效协作,这是前提。
- 实现适应: 有了新信息,或者市场需求变了,积压的结构能让团队很快重新排定优先级。这正是Agile方法在实际运作中的一大优势。
- 规划基础: 它是冲刺或迭代规划的起点。带着整理好的积压开规划会,大家可以直接做决定,不用在会上从头摸索。
积压管理
管理积压是一件长期的事,不是一次设置好就完成的工作。
- 单一所有者: 积压应当只有一个负责人,通常是Product Owner,由他对内容、优先级和表述是否清楚负责。多人共管,就容易出现重复和互相矛盾的条目。
- 持续更新: 积压不会一成不变。要定期添加新条目、删掉过时的条目、调整优先级。固定开积压精炼会,更新就能有计划地做,而不是出了问题才临时补救。
- 清晰度: 每一项都要用简单、明确的语言写清楚,让整个团队不用额外说明也能看懂。
- 自上而下的细节: 越靠近顶部的条目(优先级最高)越要写得详细,做到随时可以开发。往下的条目可以粗一些,因为轮到它们之前,计划可能已经变了。
优先级排序
排优先级,是要判断在眼下的限制条件里,做什么带来的价值最大。抽象地看最重要的事,不一定是答案。
- 业务和用户价值: 这是首要标准。哪些条目收益最大?哪些解决了用户最头疼的问题?哪些最直接地推动公司的战略目标?
- 紧迫性: 有没有截止日期或外部因素要求马上处理,比如严重缺陷、监管要求,或者转瞬即逝的市场机会?
- 实施成本: 工作量估算能帮团队比较各条目的相对成本。几个小而有价值的条目加在一起,可能比一个大工程带来的总价值更多。常用的估算方法有故事点和T恤尺码。
- 风险: 高风险任务有时值得提前做,这样技术问题能在影响其他相关工作之前暴露出来。
- 依赖关系: 有些优先级低的条目必须先完成,优先级高的工作才能开始。所以任务之间的依赖关系要一目了然。
结构化此过程的已建立的优先级排序框架:
- MoSCoW(Must-have, Should-have, Could-have, Won't-have): 按交付上是否必需给需求分类
- 价值与努力矩阵: 把任务按带来的价值和所需投入放进矩阵,找出价值高、投入少的机会
- Kano模型: 着眼于客户满意度,区分基本需求、性能特征和让人惊喜的因素
- WSJF(Weighted Shortest Job First): 优先安排能在最短时间内带来最大经济效益的任务,在SAFe环境中是标准做法
优化和精炼
定期的精炼会上,团队和Product Owner一起过一遍积压,把条目写细、做估算、清理无用内容。积压能在实际工作中派上用场,而不只是看起来条理分明,靠的就是这个机制。
- 细化: 把高优先级条目讲清楚,必要时拆成更小的任务,为开发做好准备。
- 估算: 团队估算各任务的工作量,Product Owner据此拿到排定优先级所需的数据。
- 删除过时项目: 已经没有意义的任务直接删掉,不让它们越积越多。否则积压会膨胀到没法用。
- 优先级重新评估: 团队专门讨论一下,上次精炼之后优先级有没有变化,并把新信息和外部条件的变化考虑进去。
精炼会要定期开,也要限定时长。既要保证积压的质量,又不能占用团队太多时间。
常见错误
就算懂得最佳实践,各个团队还是会反复踩进同样的坑:
- 臃肿的积压: 积压一直变长却没人清理,就不再能当规划工具用。那些永远不会去做的条目,每次评审都要花时间过一遍,还把真正的优先级淹没了。
- 缺乏有意义的优先级排序: 所有任务优先级都一样,积压就给不出任何指引。严格、分出层次的优先级排序是积压正常运转的必要条件,跟个人喜好无关。
- 将团队排除在精炼之外: 团队没参与任务的澄清和估算,对工作就理解得少,也不觉得这是自己的事,执行自然打折扣。
- 低质量的项目: 描述不清或者太大的任务会带来歧义,拖慢工作,估算也容易出错。
- 将积压视为固定: 不持续更新的积压只剩下Agile的框架,却失去了让Agile发挥作用的灵活性。
一个有趣的事实
第一次有记录的公开Scrum实践发生在1993年的Easel Corporation。Jeff Sutherland和他的团队在那里首次采用迭代式任务管理,配合结构化的积压、每日站会和每周梳理会议,由此确立的做法后来成了Scrum框架的基础。
相关文章:
想了解项目的战略规划方法和路线图怎么搭,请阅读项目路线图:规划和管理您的项目。
想详细了解Waterfall管理方法,请阅读Waterfall项目管理:循序渐进指南。
想了解Agile背后的基本价值观和原则,请阅读Agile宣言:核心价值观和原则解释。了解更多:任务。
结论
积压管理和严格的任务优先级排序,都是要落到日常工作里的做法,不是纸上的理论。维护得好的积压能让团队专注在价值最大的工作上,遇到变化能很快调整,冲刺执行也有了可预期的规划基础。建立并坚持这些做法需要投入,回报是更稳定的交付、更少的规划负担,以及在情况变化时不迷失方向的应变能力。
推荐阅读
"User Story Mapping: Discover the Whole Story, Build the Right Product"
一本实用指南,教你把用户需求画成地图来整理产品积压,让优先级决策更贴近用户真实的使用路径。
"Inspired: How to Create Tech Products Customers Love"
讲述优秀的产品团队怎样管理优先级、验证想法,又怎样搭建起能持续交付有价值产品的机制。
"Essential Scrum: A Practical Guide to the Most Popular Agile Process"延伸阅读:团队产品管理软件。
Scrum实施的综合参考,详细涵盖了积压梳理、估算和优先级排序实践。