網際網路團隊協作:可交付【連載二】

Alkaid發表於2017-04-02

網際網路團隊協作:可交付【連載二】

這裡是網際網路團隊協作連載的第二篇--可交付,沒有看過第一篇可以先去看看 網際網路團隊協作:可執行【連載一】
這篇既然是繼承上一篇文章的,講的是一個任務可以被執行的時候,執行完成後成功交付的問題,有些同學可能會覺得奇怪,已經做完了怎麼會存在交付的問題?我這篇文文章說的可交付是指按照既定計劃按時按量按質的完成成功交付。這種不可交付在工作中還是經常出現的,最常見的簽收快遞的一種情況:

你買了一部手機要求先驗貨,保證手機的型號正確並沒有損壞再簽收,而快遞員卻認為你要先簽收才能拆快遞。這個時候一般是收貨人會做妥協,因為極端情況比較少見,但也有不少因此退貨的情況,在我看來這兩種情況都是不可交付的表現。

在工作中不可交付的情況更加頻繁,一方面是工作中的成果交付行為更頻繁,另一方面與公司對工作成果交付的規範不一致,有時候甚至會存在很多的個人因素導致交付問題。可交付的意義在於保證任務按照預期進行,不偏離最初的目標。要做到可交付的難度還要大於可執行,因為本身要做可交付就一定要在很高的程度做到可執行,一個無法執行的任務交付無從談起。

做到可交付可以從幾個地方著手,一是規範交付產物,包括交付形式,交付時間,交付標準。這裡要考慮到上下游的流程,對交付物的格式做一定的限制。比如產品經理用的mac,交付的需求文件是Pages格式,開發使用的word,這樣就不太好,這種交付就需要反覆溝通。交付標準上就要看具體的工作了,從產品經理的角度來說,如果其他同事反饋一個需求竟不能說明需求背景也無法說明提出需求的具體原因的話,我會建議他再思考一下,提交這個需求能解決什麼問題,能不能達到他想要的效果?二是養成交付成果的員工要對下游工作對接人責任心,這一點比第一點還重要,如果大家都只是搞定自己的工作,想盡辦法交付自己的任務,不管給別人挖了多大坑,這樣的交付毫無意義。

第二篇倉促得很,有問題大家可以私信,也可新增微信wz11-h!

預告:網際網路團隊協作:可追溯【連載三】

相關文章