一、為什麼要任務分解
1、情景
在做專案過程中，經常出現下面幾種情況：
（1）研發說：“由於我當初寫開發方案時沒想到這個地方這麼複雜（或者這裡隱藏了很多需要開發的需求），所以想要延長開發時間”。
（2）專案上線後或者提測後發現，研發有些功能或邏輯沒有實現，研發會說：“我開發的時候沒有注意到”。
2、根本原因
上述這些研發的說辭看似解釋了這些情況的原因，其實這只是藉口，並不是問題的根本原因。
對於上述兩種情況，研發沒有想到某些地方存在複雜邏輯以及沒有注意到隱藏需求。其根本原因是：
（1）在需求評審和分析時，沒有仔細分析和拆解各個需求任務的邏輯和功能；
（2）在寫開發方案時，比較粗糙和偷懶，沒有把所有需求任務分解到最小粒度。
總結上述兩個根本原因，就是在需求分析和編寫開發方案時沒有做好任務分解。
3、任務分解的重要性
要想避免由於沒有做好任務分解，而導致專案進度或者專案質量的問題。首先研發需要重視任務分解的重要性。雖然產品經理已經把整個專案的目標和需求描寫清楚了，但是距離研發立馬上手編寫程式碼還需要兩個重要的關鍵步驟，就是需求分析和編寫開發方案。
研發的需求分析，主要是以下工作：
（1）瞭解和掌握專案中的業務邏輯和業務流程，檢查邏輯是否自洽；
（2）研究專案的開發可行性；
（3）將專案拆解模組（這個階段不分解到最小粒度），主要是對專案的業務框架有基本的瞭解，以及對專案的體量和複雜度有大概的瞭解；
（4）將本次專案的重點和難點部分標記出來，可能時複雜邏輯、或效能要求、或公共元件和方法等（在編寫開發方案和開發時需要重點考慮）。
編寫開發方案應該要有以下幾個步驟：
（1）根據需求文件，分解專案任務。
分解任務是一個綜合步驟，具體怎麼分解，下面會講到。
分解任務時，一定要將任務一層一層分解，直到分解不下去。最終的最小粒度任務是可以交給任何一個開發人員，簡單解釋就可與讓該開發人員明白具體要做什麼。
這一步，需要產出一個任務列表（樹狀結構）。
（2）根據第一步產出的任務列表，對專案進行框架設計。比如，某個業務邏輯的實現可以參考哪個設計模式、哪些方法可以抽象成公共方法、哪個業務方法需要使用分散式事務或者訊息佇列。
這一步主要是開發人員對整個專案的程式碼框架進行設計，設計後會得到一個新的任務列表（同樣是最小粒度）。這裡可以對重點部分和難點部分進行著重設計。
（3）根據任務列表，進行排期和分配任務。
透過分解任務和得到的任務列表，對我們有什麼作用：
（1）可以準確且清晰地定義專案的範圍；
（2）方便給開發人員分配任務，以及後續尋找負責人；
（3）可以提高估算開發時長的準確度；
（4）方便排出各個任務的優先順序；
（5）有利於明確專案的影響範圍，最大程度地降低風險。
二、怎麼任務分解
每個研發都有自己分解任務的方法，但是都需要遵循以下分解原則：
（1）分解任務一定要以結果為導向，切不可為了分解而分解。我們分解任務是為了高效地做專案，使專案的最終交付結果符合預期。如果一個小專案，它已經很明確清晰地顯示了各個子任務，那大可不必花時間和精力去做分解。
（2）分解任務要像剝洋蔥那樣，一層一層地往下分解。切不可跳過中間層級，像切洋蔥那樣一步就分解到最小單元。
（3）分解任務一定要分解到最小粒度，分解到不能再細分為止。
（4）從上向下分解，一般是分解某個任務或者功能的組成元素，這樣也符合物件導向的程式設計正規化-組合原則。在最下層可以描述最小任務的具體。
（5）要遵循 MECE 原則。
a、相互獨立，在同一層級上的任務有明確區分、不可重疊；
b、完全窮盡，不遺漏，儘可能窮盡所有的小任務。
分解完成後會得到一個專案任務的樹狀圖，然後根據這個樹狀圖進行程式碼框架設計。設計後根據樹狀圖就可以產出一個專案任務列表，這個列表只是表格形式的任務分解樹狀圖，只是它會有更詳細的資訊，比如每個任務的開發時長、負責人等。