責任分散

“責任的擴散”一詞指的是一種心理現象，其中重要的任務被遺棄，因為每個相關人員都認為處理它是其他人的工作。

不幸的是，這種萎靡不振是許多工程團隊的禍根。這就是為什麼僅涉及幾天實際編碼和測試的任務通常最終需要幾個月的日曆時間才能完成。

雖然我不是網際網路模因的主要愛好者，但我建立了一個小影象，我覺得這個影象充分總結了我對軟體開發團隊中觀察到的各種病態的看法：

拋開所有的幽默，有理由為什麼這種事情經常發生。主要原因是整體任務複雜性，以及任務規劃人員無法全面捕獲完成任務所涉及的所有次要子任務。

例如，假設Alice，Bob和Chuck正在網際網路創業公司工作。 Alice負責伺服器程式碼，Bob編寫HTML和JavaScript，Chuck負責devops和部署。他們正在忙於處理一項新功能，因此他們根據分配的角色劃分了他們之間的工作：

不幸的是，正如你所看到的，整個任務中有很多灰色區域，而這些灰色區域並沒有被分配給Alice，Bob和Chuck的工作所覆蓋。

當產品經理問“為什麼不完成任務X？”時，愛麗絲會如實地說：“好吧，我的部分已經完成了”，鮑勃和查克會說同樣的話。

這裡的部分問題是沒有人owns 整個任務。 “擁有”我不是指產品經理;我的意思是有能力採取具體行動推動任務向前發展的人。在我們的假設情景中，沒有人對灰色區域負責，因此工作無法完成。

這裡的另一個問題是Alice，Bob和Chuck都是heavily siloed 。每個人都有一個指定的領域或舒適區域，很少偏離它。 Alice在伺服器程式碼上工作，並且不習慣使用devops或客戶端程式碼; Bob對伺服器程式設計一無所知;而且Chuck對兩者都有所瞭解，但對於闖入Alice和Bob的域名感到緊張。

此外，Alice，Bob和Chuck都在制定不同的時間表;除了這一功能外，還有許多其他工作要做。愛麗絲可能已經儘早完成了自己的工作，但鮑勃正在忙著處理一個高優先順序的錯誤，並且可能不會再繼續他的工作兩週了。在鮑勃的工作完成之前，查克甚至無法開始。因此，即使工作可能只需要一兩天的個人努力，完成專案所需的時間為三到四周。

另一個問題是所涉及的個人可能甚至不知道灰色區域存在。在上圖中，顯而易見的是，有三大工程師沒有涉及大量工作。但是大多數任務描述都不是圖表，它們通常是專案符號列表，電子表格中的行或者票證跟蹤系統中的任務。他們往往看起來更像這樣：

以這種方式呈現，完全沒有明顯的任務缺失部分。

這就是為什麼“全棧工程師”近年來成為如此備受追捧的角色的原因之一。當一個人在整個任務上工作時，他們不僅創造已識別的單個部件，而且還迫使他們實施所有將這些部件綁在一起的“粘合劑”。

（當然，缺點是單個人不能擴充套件。本週只有這麼多小時。）

沒有能夠做任何事情的“超級程式設計師”，另一種方法是更好地分割任務，以便不遺漏任何東西。如果涉及將客戶端程式碼與伺服器API整合的工作，則應將其包含在任務列表中。

避免這類問題的最佳方法是要意識到它們會發生，並在規劃期間嘗試對它們進行補償。人類是錯誤的，這就是為什麼我們發明了諸如複式簿記和科學方法之類的東西：幫助我們彌補我們的認知缺陷和觀察偏見的技術。負責人的擴散