项目开发中的权责分配
在软件项目开发中,角色众多,常常有权责不明的问题,事后抱怨也是家常便饭。有人加班加点,有人悠哉悠哉,多做事的反而错的多! 即使公司有一套制度,这样的问题也是一再出现,究其原因还是在R&R的定义是不是在项目开始时定义清楚了。
在项目开发中涉及的角色主要有:项目经理(PM),项目协调,组长(TL),开发人员,测试人员,市场人员,产品规划人员以及其它辅助单位的同事。要做的事情也是项目管理中规定的一系列步骤。这些对很多项目管理者都是清楚的,但是在谁对什么负责的问题上却是模糊的。比如需求文档的撰写就包括以下细节:
1.谁来写? 谁来提供相关信息? 遇到困难或问题时,可以咨询谁?
2.谁来定义时间表? 包括撰写、审查的时间。
3.谁来审查? 谁来组织审查? 谁来确保审查结果的执行?
4.撰写完成及审查时,需要通知哪些人? 由谁来通知并收集反馈意见?
5.如果发生争议,谁有裁决权?
6.谁对文档撰写进度及质量负全责?
通常我们会定义清楚前三项,而后三项却是模糊的,往往问题就发生在后三项。如何避免这样的问题呢?
有一个方法可以尝试:ARCI矩阵! 使用它来定义出在每一项活动上的四种角色:当责者(对结果负全责),负责者,咨询者及被告知者。而不是在单一活动上只简单的定义为谁来负责。以下是一篇相关的文章,跟大家分享:
ARCI四種角色、四種責任
張文隆在《當責》一書中提及,李‧波曼(Lee Bolman)與泰倫斯‧迪爾(Terrence Deal)在1984年的著作《認識與經營組織的當代之道》(Modern Approaches to Understanding and Managing Organizations)裡,首先提出「RACI」的概念(通稱為銳西矩陣(RACI matrix)或銳西法則),目的在於協助澄清「誰該負什麼責任?」畢竟,唯有清楚界定一項任務所有參與者的角色與責任,才能避免權責不分或推諉塞責。
然而,隨著RACI法則的應用範圍日廣,RACI本身的用字次序與用意,開始引發爭議,舉凡英國資訊工程基礎建設學會(ITIL)、顧問業者及企業,均主張「是ARCI,不是RACI」。
根據以下對於ARCI分別代表的4種角色和責任的定義,應可進一步理解「A」與「R」的排序為何如此重要?又如何有助於找出在推動工作時,究竟誰該負起什麼樣的責任?
1.當責者(Accountable):必須負起專案或任務的全部責任的人,通常只有一個人可扮演此角色。他擁有決定權與否決權,以及伴隨著權力而來的責任,不但要「把對的事情做到最好」,更要對自己所決定與否決的事情,負起最後成敗責任。
2.負責者(Responsible):在當責者領導之下做事的執行者,團隊中可有多人扮演此角色。執行者的首要之務就是擁有100%的工作責任感,並且將自身責任往外延展,致力於追求「個人當責」與「個體當責」。
在團隊中,當責者(A)與負責者(R)的互動密切。「A」必須與數個「R」溝通協調,以及設法提升「R」的能力及熱誠。而「A」如果想成功,務必對「R」授權、賦予能力(empowerment),激勵「R」樂於「多做一點」(one more ounce)。
3.諮詢者(Consulted):當責者在做出重大決定前,向他尋求建議或徵詢意見的對象,彼此進行雙向溝通。諮詢者可能是顧問,也可能是頂頭上司或資深主管;簡單說,就是防止你闖禍的人。諮詢者的責任在於清楚傳遞自己所知的資訊、經驗及觀念。
要注意的是,諮詢者(C)是給建議的人,千萬不要自己跳下來做決定。如果真的很想更改當責者(A)的決定,應藉由個人的「影響力」,切忌越俎代庖,以免責任跳回自己身上,甚至讓「A」認為自己只是在執行老闆的旨意。這樣非但無法強化部屬的執行力及對成果的負責力,也無法培養部屬的領導力,還可能對部屬的信任和信心造成傷害。
4.被告知者(Informed):在決策做成或行動完成後,必須被知會的人,可能是人資部門人員,要幫你尋覓人才;可能是財務部門,提供你所需經費;也可能是往後要接你棒子的人。當責者與告知者的溝通是單向的,只需事後報備,無須事前報告。
很多政府單位缺乏「當責」的概念,常常是由一個「委員會」作決策,由8個人來共同承擔責任。只是,當有8個人需要負責時,其實就等同於沒有人來負責。在管理上,不要說「三個和尚沒水喝」,只要兩個和尚都會沒水喝,團隊中,只能有一個人當A,運作起來才會產生執行力。