記得在神州負責過的一期需求開發， 原本計畫2周時間上線， 結果卻拖延了1個多月， 事後總結的原因就是用人不當。 我們團隊當時有好幾個產品， 除了leader不輪崗之外，其他所有開發人員都實行輪崗制， 恰好這期需求有個工作七八年的女生輪到我這邊了，因為平時工作上與她深入接觸的也比較少，從其他leader那側面打聽到該人做事還行， 以前參與過幾次他們的方案討論，感覺她確實也還不錯，於是這期需求的核心模組我就打算讓她來負責， 結果非常糟糕， 剛一提測， bug就滿天飛， 以致於後來測試部同事每天向所有研發部同事發一封bug列表報告， 搞得非常被動，用測試同事的原話來說就是根本不可測了，問題改1個出2個。
最後沒辦法，只能將之前她寫的所有**全部刪掉重頭再開發，當我扒開她的**後，簡直不可思議，太亂了， 同乙個模組的增刪改查功能原本乙個jsp、js可以搞定的，她卻寫了4個，後台邏輯更是亂的一踏糊塗。
事後，我自己總結得出結論：
1、 一定要相信自己的眼睛
有些人能說會道，但幹活不一定行。 別人說行的東西也未必行，因為有可能別人和你權衡的標準不一樣。 拿上面的示例來說， 原來其他leader給她分的任務都是非常小的簡單的任務，而我分配的是核心的帶有些邏輯性的。
2、一定要根據下屬能力去分配任務
有多大頭分配多大的帽子， 切忌不能分配超過他（她）能力的任務， 如果時間寬裕的話或許他們能夠得到一些煅練，否則的必然會導致任務完成的一團糟，反而人家沒了成就感。 話又說回來了，在軟體公司**會給你那麼多時間呢？ 何況是網際網路公司。
3、任務分配下去後一定要有監控
人都是有惰性的，加上人的能力有差別，任務分配下去後，如果不及時的去監控跟蹤，非常有可能走偏， 一定要及時的去糾正，否則上面領導很生氣，後果很嚴重。 上面就是個好例子， 如果當時每天去check， 可以肯定的是前3天就可以發現她的不足，及早尋找應對策略。
任務分配及管理
前面說到過，剛開始帶小組，接到乙個任務，我就估算了我大概要多少時間，然後小組多少個人就算是多少個我，估算時間 我要的總時間 小組人數 好笨的想法呀，不用時間跟組員交待任務的嗎？個個組員都是我嗎，比我強的還好，頂多做完了休息，差一點的就麻煩了 結果實際時間多了很多，而且小組裡有的人做完了無事可做，有的...
專案管理 任務分配閒談
這件事事實上發生在本週三吧。記得比較清楚是由於我周四要歇息。當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本號的規劃和培訓文件什麼的。事實上當時自己手下也沒有什麼事情。本來是應該答應的。可是當時停頓了兩秒，感覺這件事情不應該是我來做。或許這麼說不恰當，應該說是這件事不應該是交到...
專案管理 任務分配閒談
這件事其實發生在本週三吧，記得比較清楚是因為我周四要休息，當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本的規劃和培訓文件什麼的。其實當時自己手下也沒有什麼事情，本來是應該答應的。但是當時停頓了兩秒，感覺這件事情不應該是我來做，也許這麼說不恰當，應該說是這件事不應該是交到我這裡...