乙個專案需求確定了（需求這個東西永遠沒有確定的哪一天，時時刻刻都是在變化,但是經理認為確定了那就是確定了:p），然後專案經理給了乙份需求文件就算真是開始開發了。大致用了一天的時間資料庫就由乙個開發人員設計了出來（其實對於這個速度我還是比較「驚訝」的，一天就把資料庫設計出來，可見資料庫中丟字段、字段設計不合理等等問題一定在後面等著我們），資料庫經過大家統一「審查」過一遍之後沒有什麼異議（時間這麼緊沒有認真的去研究怎麼會有異議呢？也只有到真正開發的時候才能發現問題），然後專案經理就開始分配任務準備進行開發了，但是這個分配任務也是大有學問的，筆者今天要談的不是前期需求也不是資料庫設計而是關於專案開發過程中對專案經理分配任務的感觸。
好像「業務」這個詞是開發過程中提到的最多的乙個詞彙了，但是依然很多的團隊在沒有搞清楚業務的時候已經開始動手碼**了（後果不堪設想啊）。這裡要說的是分配任務一定是在充分了解業務的基礎之上，最尷尬的事情就是一項任務或者是乙個技術難點要麼沒人做，要麼多個人同時都在做。沒人做的結果是最後整個團隊抓瞎，多個人同時做的後果就是浪費了人力資源。所以說分配任務之前一定要充分的了解業務，然後將業務合理分解，最後才是將任務分配下去，最後的最後才是動手碼**。
專案經理直接和業務需求打交道，而且負責團隊中資源的調配，
所以說分配任務這項工作一般情況下是專案經理的職責。也就是說專案經理能不能充分的了解業務決定了任務分配的是否合理。
團隊開發的最大優勢就是將大夥的力量集中起來，所謂的「集中力量幹大事」就是這個道理。但是前提是將任務合理分配，不能說
a童鞋的任務要依賴
b同學的任務，最尷尬的局面莫過於在b童鞋做完之前a是不能開始動手的。要是這樣的話合作開發就沒有什麼意義了，原本是乙個多執行緒同時進行的工作由於任務分配的不合理，於是就不得不變成分時復用的情況。這就要求專案經理對整個專案有乙個巨集觀的把控，先幹什麼後幹什麼，什麼是根本什麼是枝葉，這些都是需要專案經理非常清楚的。把這些搞清楚了再去分配任務就不會出現有的人忙死有的人閒死的情況。最好的辦法就是將整個專案的流程製成甘特圖之類的進度計畫，先後主次一目了然。歸根到底一句話，分時復用不可取，保證並行才是王道。
分配任務一般是兩種方式，按照任務型別分配、按照業務分配
按照類別：
好處是某人固定負責這一類的工作，由於是一類固定的工作所以熟練度肯定越來越高，於是幹活的速度也會越來越快。缺點是這個人只負責自己這一塊兒的東西不能保證乙個業務流程整體邏輯上的正確性
按照業務：
好處是某個業務中的邏輯性能夠得到有效保證。缺點是但是由於乙個人往往要負責多個技術難點所以開發效率自然就會相應的慢一些。
兩種方式各有利弊具體採用哪種方式（或兩種方式相結合）需要根據具體的專案來看，如果專案或者某個模組兒對業務邏輯要求比較高那麼最好將任務分配給個人；如果專案中對業務邏輯沒有過多的要求而是各個技術獨立分明則最好將一類的技術配給乙個或幾個人。
分配任務之前專案經理不單單需要對專案的業務進行了解，還要對自己的組員有乙個充分的認識，一定要給自己的組員分配他最擅長的模組，盡量保證每個人都做自己最擅長的地方（雖然這種可能性很少）只有這樣整個專案的進度以及工程的質量才能有所保證。有些組員想挑戰一些新的技術，或者想嘗試不同層次的開發，這其實沒有問題的。從專案經理的角度來說鍛鍊自己的組員更沒有問題的，但是貿然把乙個組員不熟悉的東西交給他這是對專案不負責任的表現。其實鍛鍊組員可以採用經驗共享的方式，通過
共享讓乙個人的經驗變成多個人的經驗，最終的效果就是組員中每個人都是萬金油，遇到什麼樣的問題都可以解決。
專案管理 任務分配閒談
這件事事實上發生在本週三吧。記得比較清楚是由於我周四要歇息。當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本號的規劃和培訓文件什麼的。事實上當時自己手下也沒有什麼事情。本來是應該答應的。可是當時停頓了兩秒，感覺這件事情不應該是我來做。或許這麼說不恰當，應該說是這件事不應該是交到...
專案管理 任務分配閒談
這件事其實發生在本週三吧，記得比較清楚是因為我周四要休息，當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本的規劃和培訓文件什麼的。其實當時自己手下也沒有什麼事情，本來是應該答應的。但是當時停頓了兩秒，感覺這件事情不應該是我來做，也許這麼說不恰當，應該說是這件事不應該是交到我這裡...
任務分配及管理
前面說到過，剛開始帶小組，接到乙個任務，我就估算了我大概要多少時間，然後小組多少個人就算是多少個我，估算時間 我要的總時間 小組人數 好笨的想法呀，不用時間跟組員交待任務的嗎？個個組員都是我嗎，比我強的還好，頂多做完了休息，差一點的就麻煩了 結果實際時間多了很多，而且小組裡有的人做完了無事可做，有的...