這裏是互聯網團隊協做連載的第二篇--可交付,沒有看過第一篇能夠先去看看 互聯網團隊協做:可執行【連載一】。
這篇既然是繼承上一篇文章的,講的是一個任務能夠被執行的時候,執行完成後成功交付的問題,有些同窗可能會以爲奇怪,已經作完了怎麼會存在交付的問題?我這篇文文章說的可交付是指按照既定計劃按時按量按質的完成成功交付。這種不可交付在工做中仍是常常出現的,最多見的簽收快遞的一種狀況:微信
你買了一部手機要求先驗貨,保證手機的型號正確並無損壞再簽收,而快遞員卻認爲你要先簽收才能拆快遞。這個時候通常是收貨人會作妥協,由於極端狀況比較少見,但也有很多所以退貨的狀況,在我看來這兩種狀況都是不可交付的表現。post
在工做中不可交付的狀況更加頻繁,一方面是工做中的成果交付行爲更頻繁,另外一方面與公司對工做成果交付的規範不一致,有時候甚至會存在不少的我的因素致使交付問題。可交付的意義在於保證任務按照預期進行,不偏離最初的目標。要作到可交付的難度還要大於可執行,由於自己要作可交付就必定要在很高的程度作到可執行,一個沒法執行的任務交付無從談起。cdn
作到可交付能夠從幾個地方着手,一是規範交付產物,包括交付形式,交付時間,交付標準。這裏要考慮到上下游的流程,對交付物的格式作必定的限制。好比產品經理用的mac,交付的需求文檔是Pages格式,開發使用的word,這樣就不太好,這種交付就須要反覆溝通。交付標準上就要看具體的工做了,從產品經理的角度來講,若是其餘同事反饋一個需求竟不能說明需求背景也沒法說明提出需求的具體緣由的話,我會建議他再思考一下,提交這個需求能解決什麼問題,能不能達到他想要的效果?二是養成交付成果的員工要對下游工做對接人責任心,這一點比第一點還重要,若是你們都只是搞定本身的工做,想盡辦法交付本身的任務,無論給別人挖了多大坑,這樣的交付毫無心義。blog
第二篇倉促得很,有問題你們能夠私信,也可添加微信wz11-h!繼承
預告:互聯網團隊協做:可追溯【連載三】開發