4年半的經歷中，軟件工程的全部內容我都有豐富的經歷。同時見過不少風格迥異的PL，PM，部長
之前一直比較抗拒走管理路線，雖然一直以來都知道技術路線在中國不合適，而且，我本人其實對技術不是很熱衷，只是很熱衷於享受解決問題的快感，及決定一個項目實現，需求的認同感。其實最重要的是因爲我本身是一個不好管的人，是一個個人英雄主義比較重的人，怕遇到的團隊成員也是像我這樣。。。
但，既然我已經跨出了這一步，要去做一個pl，就要在各種管理方式及風格間做出一個抉擇，來決定未來2年內我的路
在我的心目中，一個PL是一個項目的核心，他會做出一系列的決定，來分配項目成員的工作內容，計劃，進度管理，並同時需要掌控項目的風險，未來，還有彙報，統計等一系列的雜事，同時做好所有的並不現實，但要以項目爲主，培養人員，使大家都比較幸福比較重要
1.管理風格
我見過的有比較規矩的，比較隨意的，放任自流的，把活兒幹完就行的各種
暗想下，我可能是那種比較不喜歡發號施令，不喜歡開會，不喜歡活躍氣氛，大家一起合作把活兒幹完的PL吧....
2.例會
我一直認爲開會是比較浪費生命的一個方式，會花很長時間都決定不了一件事，而且扯皮的現象會很多。但例會，成員比較少的時候，除外。
以前都沒什麼正規的例會，成員間的工作交流也比較少，直到有一次開會說進度，旁邊同事的進度比我快了很多，我在說的時候很緊張，才明白例會的重要性。進度不是填個文檔就結束的。
例會上可以發現當時工作內容的問題，同時可以鍛鍊組內成員的表達能力。
但，我覺得，可以在例會中減少進度確認的時間，而增加發現問題，解決問題的時間。
●比如，可以做一個小的工具，把每日的任務及時間，完成到何種狀態來劃分彙報，如果PL有不明白的部分，再在例會上確認，同時可以將各個組員的進度彙總，在例會上說明（有圖表的比較好，這樣能看到未來，比較容易統計工作量和工作能力）
3.任務安排
我一直比較討厭耳提面命式，說教式，說明曖昧的任務分配
●任務分配首先應該看這個人的能力，以及他想做的內容，而不是哪兒缺人都可以補上
所以我應該會先了解成員的履歷，看看他們都做過什麼，沒做過什麼，想做什麼，及他們對之前自己的工作的滿意度，再來安排他們的工作內容，當然，不是每個人都有想做的事，或者沒有他想做的事，或者大家都想做同一件事，這樣的情況也是不可避免的，但我覺得如果你做了瞭解這一步，就算當時無法滿足他的願望，也可以在以後考慮他想做的事。
如果能大家坐一起要任務，爭任務就更好了，哈。最好別給我個時間緊迫的活兒，那樣我就是想法再多都沒法實現……
4.進度
其實進度確認是一個比較虛的東西，好多人都想着要把進度細化到可控，但實際上，這東西的的可控性是少之又少，就算把任務細化了，中間會出現何種問題又無從得知，所以難吶。我還有一個問題，就是容易把事情想的比較簡單，而且，容易高估別人的能力。。。。。。還有就是每天不能安排8小時的任務，要有餘裕和休息，還有雜事……
5.角色
一個組裏，肯定會有需求+設計+開發+測試+管理這麼幾個角色，之前的PM說過，一個組5個人比較合適，能專心幹一個事當然是很好，但也得有個什麼都能幹的人，隨時補充。。這樣一個項目才能比較穩定，才能比較高效。不會在工作中被打攪
有關任務分配，我從09年就想寫一個工具，但不幸的是，一直都沒有實現，只是處於設計階段，我想，可以利用這段時間把這個任務完成吧，一個一個的小模塊，會組成一個好用的工具地