[Day16] 团队管理:Role & Responsibility

角色与责任

任务开始前,先确立好RACI

团队朝向事业目标努力时,每个成员都会是高度协作,「角色与责任」(R&R)通常会默默发生其中而不自知,不论最终团队是否有达标,「角色与责任」的效应均在团队中发酵。如果R&R在成员之间的定义是模糊的,就代表责任界线不清楚,谁是多协助成员的?谁是受帮助的?往下要探究的,谁应该因为团队支援受得额外的奖励,谁应该了解在任务上的安排有在能力上的问题,需要调整任务或是强化任务?都会无法妥善定义和执行,影响最大的是,团队彼此合作上的观察也会失衡,无法察觉落後的人应该要赶快追上,厉害的人也无法妥善发挥。即便团队是成熟的,R&R都需要在一开始被对焦,清楚应当要负责的业务和责任,让团队运行是公开而透明无模糊地带。谈论R&R的时候,RACI (有些因为权责顺序,会调整名称是ARCI)是一个很简单快速可以划分权责的工具:

  • 当责人(A: Accountable):对於最终结果的最高负责人。在一个任务小组下,仅能1人,因为其负责整件事情的推动、进度管理与最重要的决定权与否决权,当责人把对的事坚持到最後最好,也为错误的决定负起最大的责任。
  • 执行人(R: Responsible):以高工作责任感执行任务的人。在一个任务小组下,会有1个以上的人,对於授权於当责人的任务与职责,会尽其专业与自我要求,让任务顺利完成,其包含在执行过程中专业资讯的收集、资讯的分析、意见的给予、风险的告知与执行完成。
  • 谘询人(C: Consulted):不参与任务,但给予建议的人。在决策判定前或任务被执行前,可以让团队徵询意见的对象,主要就以任务内容来看,可以降低风险或减少走冤枉路的人都可以是谘询人,像是顾问、主管或是有类似执行经验的同事。
  • 被通知人 (I: Informed):任务事件的被通知人。是唯一在任务运作时,以单向沟通为主的角色,初步划分成两类:资源的提供者和成果交棒者,在运行任务前,一定会先召集所需的资源团队或交棒团队,在执行过程中的新决策与新成果,必须在适当的时间(例如:接手团队所需的前置准备时间)知会他们。

在任务准备开始前,我们一定要先确认这些角色的共识,也鼓励团队成员将角色的讨论,在团队会议中,好好讨论。初合作的团队需要再多对焦一下这些角色的定义,等团队有默契後,只要简单确认角色,就可以各自发挥了!

R&R不是自扫门前雪

好的团队是知道彼此职责,愿意补位,但不会只补位

过去在推动团队,我吃了R&R不清的大亏,一来无法清楚的评论团队成员的优点与可以更好的地方,团队成员也会因此糊在一起,看不见彼此的职责,工作毕竟是力求每个人有效发挥才能有好的团队效益的地方,虽然大家彼此愿意互相照护很好,但是以整体来看,就会弱者恒弱、强者受限,对个人、对团队都不是健康的合作方式。後来,在团队之中,我特别强化R&R的意识,可能和当下正处於低气压有关,所以容易负向看待R&R,最常被提到的就是,「R&R是在摧毁团队合作」、「R&R不让我们帮助成员」。如果严苛一点,我们在公司里面,就像是打仗,打仗时,不就是都会分配好每个人应当要负责的项目吗?这样会是不团队合作?如果医护兵,不在岗位上照护伤兵,也冲进第一线抗衡敌人,那原本需要受照护的伤兵,要如何?R&R,应该是让我们更紮实看到自己状况而让团队合作更稳固的元素,因为我们扮演好我们的角色,所以团队可以前进的更轻盈,在我们要支援成员的时候,我们也会清楚知道,该做的事情是可以完成的情况下,才帮助的,被支援成员的困难,也才会被看见,才有机会可以被解决。以团队合作为前提,R&R帮助职责厘清,不会限制成员之间的补位,补位成员的有效补位是被鼓励的,团队也不会止於补位,而是从中发现问题,为下一次的更好做调整。


<<:  Day 16 - SNMP、Banner Grabbing 与 Firewall Rules

>>:  Day 18 | 万年范例-TodoList

[NestJS 带你飞!] DAY24 - Authentication (下)

上一篇已经处理好注册与登入的部分,但一个完整的帐户机制还需要包含 登入後 的身份识别,为什麽登入後还...

DAY26 - CSS命名规则 - BEM

不论是哪种程序,都会遇到命名这件事~ 关於CSS的命名有什麽规则可以依循呢? 也许你可以试着了解看看...

前端工程师也能开发全端网页:挑战 30 天用 React 加上 Firebase 打造社群网站|Day3 建立 React 网页

连续 30 天不中断每天上传一支教学影片,教你如何用 React 加上 Firebase 打造社群...

[Day24] Marketplace

对於初学者来说,自动化的部属真的是一件非常累人的事情,从云端架构开始就有一大堆东西要学,再加上昨天提...