优先级就是力量 - Triage

项目工作中,你是否留意过这样的对话?

策划A:“小K,功能1做好了没,啥时候能上?另外我需要加个功能,要一起上的。对了,这个列表我仔细考虑过了,这里还是要改下”。(期望:更快更敏捷)

设计S:“小K,这里还能不能给加个特效,就像这样,你看技术上可以做到吗?没问题吧”(期望:更酷)

开发K:“。。。”

测试C:“小K,我刚测完一遍,怎么又改了?本来已经好的功能现在全挂了。版本能不能可靠点,全白测了”。(期望:更可靠)

开发K:“。。。”,其实他更希望捣鼓那些自己喜欢的功能,希望接触些更有意思的技术,希望学到新东西,对于一些技术含量低又非常频繁的需求不怎么感冒。(期望:更高技术含量)

事实上,有多少个人就有多少种想法和声音,各个角色对于项目都有着不同的期望,这些期望本身都是合理的,但却往往互相矛盾。如果没有统筹管理,每个人都会按照自己的理解来选择做工作,整个团队对优先级没有明确的意识,更谈不上共识。

这些分歧和误解最终无疑都会反映在你的产品上,结果看似每天忙忙碌碌疲于奔命,而当你深入了解,会发现有些工作对我们实现项目目标是没有帮助的;而对于项目目标非常重要的工作,由于这样那样的原因,一直没有开始,或者战线拖的太长,到后面渐渐鲜有人问津。


为什么要做triage?  

项目永远是为达成特定目标而存在的,资源永远是有限的,我们不可能也没必要去做所有的事。明确的目标是一切工作的基础,但有了目标,如果没有有效的机制来进行决策控制,项目也会慢慢走向失控。优先级必须体现在项目团队每个人的每项工作中。

进一步,在互联网的大背景下,我们的目标通常是移动的。市场环境发生改变,竞争对手有大的动作或战略调整,公司高层改变了他对于市场的想法,等等。当难以预料的变化确实发生时,你如何确保团队快速适应并跟上变化的脚步?任何有关战略或目标的改变,都要直接反映在相应每件工作的优先级上。伟大的战略与目标,也只有在一次次的决策中落地、并不断调适中,才能真正做到“指哪打哪”。从这个角度上来讲,优先级必须是灵活的。

为实现项目不断变化的目标,我们需要一种强有力的决策机制来控制变更,确保整个团队对所出现的问题给予正确的响应。这种决策机制就是triage。Triage帮助我们排开那些次要事情的干扰,让团队focus在当前最重要的事情上。

实践证明,明确清晰的优先级能将团队的有生力量真正地聚合起来,爆发出最大的效率与战斗力。优先级就是力量!


Triage是什么?

 

Triage就是对项目中的各项任务进行分类定级,确定先做哪些,后做哪些,到底哪个更重要。对于确定要现阶段处理的问题,安排优先级,并指派给相应人员进行处理。

如上文所说,triage的本质是一种变更控制的决策机制。进一步,triage是一种公开的集体决策机制。

公开决策,意味着团队知道什么时候做决策、什么是标准、谁应该参与决策。任何有意见的人,都知道去哪提出他们的需求或建议,及怎样才会生效。

集体决策,意味着triage不是由某个leader自己说了算,而是要参与该工作的相关方,共同讨论,共同决策。


Triage要怎么做?

triage参与人员主要是功能小组成员(即该功能涉及到的策划、设计、开发、测试)。

项目前期在功能开发过程中,由该功能的策划来主导triage过程。如涉及到需求方众多,需求频繁且进度要求不一致的情况,应该由多个需求方共同triage。此时,变更所带来的成本及风险相对较小,triage主要关注用户场景优先级及重要程度。功能开发完成后,对于成本与风险的关注度要逐步增强,项目经理需要逐步参与进来,主导triage过程。 具体如下表所示:

Triage决策标准主要考虑四个方面,优先级、重要程度、成本、风险。

在上面的决策矩阵中,高优先级低成本(做)、低优先级高成本(不做),比较容易做出决策。

高优先级高成本(需谨慎权衡,评估团队的生产力)、低优先级低成本(这类是绝对的鸡肋,问问你的团队,难道我们没有更重要的事要做了?)这两类任务很容易成为争论的焦点,是triage的重点关注对象。此时,做还是不做取决于标准到底划在哪里。每个阶段的triage标准是变化的,确保你的团队明确知道现阶段的标准。

优先级及重要程度的分级定义如下:

优先级(Priority)

  • P0-Must have. 如果缺失,产品不能发布 

  • P1-Should have. 如果缺失,产品能发布,但不能达到预定目标(功能/性能) 

  • P2-Nice to have. 做了则更好 

  • P3-Neutral. 对产品没有明显的好处,用户不在意.

重要程度(Severity)

  • Blocker,阻碍开发和/或测试工作进行的

  • Critical,程序崩溃或导致死机等问题

  • Major,严重影响用户使用的问题

  • Normal,对程序使用造成一定影响或与需求不符的一般性问题

  • Minor,较轻的功能缺陷

  • Enhancement,建议或意见

Triage决策结果:是否要做? 是否要现在做?何时做?(放在哪个发布周期?哪个开发分支?)

 
Triage带来了什么? 

以我所在的项目为例,所有的任务都必须经过triage并approve通过,才能开始工作。通过项目中的相关实践,我们发现在明确优先级之外,triage还带来了几个额外的好处:

1. 消除误解、沟通不畅。“这个接口上次我们明明说好的,怎么又改了?为什么又要改?”通过triage会议,各方能够增进沟通,每个人对自己每天在做的事情,为什么要这么做,以及和其他人在做的事情有什么关联,有了更加全局的认知。

2. 有助于测试过程提前。“以前测试往往到发布前最后关头,才得知又改了一大坨的功能,完全不了解,一下子那么多用例要加,测到什么时候才能上?”通过triage会议,变更所带来的各方(开发、测试等)成本及风险得到了充分沟通,测试等各相关方能够在变更的第一时间了解到改动涉及到的范围,未雨绸缪,尽早熟悉并准备。

3. 更明确的责任意识,更靠谱的时间承诺。“报了个bug,很久没人理,也不知道是修还是不修,到底做的怎样了?”。traige会议上通过的任务,指派人需要在会议上,给出时间预估,相当于做了个公开承诺,促使问题更快得到解决。

 Q&A

Q:公开、集体决策好是好,但需要那么多人参加,会不会产生很多低效率的会议,反而打断了我们的正常工作?

A:首先,triage的形式有很多,比如popo群讨论,但实践表明会议的形式最为简洁高效(一见胜千言)。

其次,关于效率,triage会议上只关注决策本身,不涉及实现细节讨论。与会人员需提前review待triage的任务列表,以提高讨论效率。会议上留给每个任务的时间原则上不超过5分钟,由owner做简要澄清后,与会人员共同表决是否通过。 

最后,工作中间被各种会议打断,自然是需要极力避免。在项目的不同时期,可以采用不同的频率(如每周、每天、每半天等),但某一时期内的频率最好固定下来,让所有人形成清晰的认知,提前做好准备,并养成习惯。 一般来讲,变更越频繁,triage的频率也越高,接近项目的阶段尾声(如版本发布前),triage就必须频繁进行。Triage的节奏把握非常关键,triage会议的频率要跟随项目的松紧律动,形成一定的节奏。 

Q:大家聚在一起讨论,如果出现意见不一,是否会带来无休止、无结果的争论? 

A:首先,争论是好事,暴露出对于项目目标的理解出现了不同的意见,这正是triage的意义所在。需要注意的是所有的争论必须要有结果。如果一次会议上没有结果,建议停止这个话题,由当事人准备更多的材料,约定下次会议时确定。

Q:有时,大家会容易纠结在一些不重要、但是看起来很酷的工作中,如果代价不大,很难决定做或不做。

A:试着问问你的团队,也问问自己:“难道我们没有更重要的事情要做了吗?”这个方法在实践中证明很管用,值得一试。

评论

© 蓓蓓—PM的修炼 | Powered by LOFTER