這次培訓，由於時間問題，很多問題都沒有深入探討，導致我對某些問題理解不深，可能對問題理解有所偏差，首先我這篇文章主要從以下幾個方面來論述的感受。
用木桶效應論述系統思考
原理：
我們知道，一個木桶盛水量是與他最短的相等的，對比做項目，質量與進度就是一個相對矛盾問題，你不能一味的追求進度放棄質量，也不能一味最求質量放棄進度，最後結果就是有進度與質量構成的“水桶”，你的產品的水平高不高，就看你這做木桶用的木頭最短的高度夠不夠。
危害與事例：
在實際做項目中，我們往往做事的時候找不到這樣的系統思維，遠期效應和近期效應相沖突的時候，往往只注重近期效應而忘記遠期效應，比如測試，大家都說忙，忙了半天也看不到代碼質量的提高，bug量一直居高不下，以前的老bug在經過幾輪迭代後又出現，感覺老在失控狀態，但是大量的人力投入後，也不見好轉，投入的資源也不見成效，大夥都有感受這種測試的問題，但是誰也沒有說大夥停一下，我們來檢查下出了什麼問題，爲了照顧進度一味增加人力，但是新人進來也會增加培訓的工作量，又不能馬上進入項目，還有人一多，又會出現溝通管理，績效管理，進度管理等一些管理計劃，方式的變更，最後增加的人力消失在這無盡的漩渦裏。最後項目項目就進入一個奇怪的圈子，增加資源不見起效，再增加資源，還不見起效。最後項目組集體來做測試吧。
分析事例：
爲什麼會出現這樣的問題？那當然是系統思維的欠缺！具體分析如下：
一.首先遠期利益無法與近期利益相結合的系統思考
大夥不顧現在存在問題，一直追求短期利益，盲目測試，沒有長效的測試計劃，及方法，這種不能兼顧長遠期利益做法結果就是，測試們一直很累做測試，但是項目質量也不會有好轉。
二.增加人力與之帶來的成本的系統思考
世界上最複雜的東西不是電腦，不是飛機，而是人，沒有什麼東西比人更難琢磨，沒什麼比人的七情六慾更復雜的了，項目裏在增加人力後，其實人的管理問題就擺上桌面。在項目中。特別是軟件這類的項目，不像生產線，可以批量重複動作（比如我以前待過的仁寶電腦廠，每個員工就像機器人，完成同樣的動作就行），軟件項目是腦力密集型的，很難有重複勞動，(如果有厲害的程序員都會把他自動化掉)這樣就意味着項目中的每個人都很難被替代，也就意味了不是每個人進項目組就能馬上上線工作的，新人加入項目後，會經過相當一段的培訓期，在這期間我們將會發現新員工的優缺點，來安排相應合適的崗位。那這期間的成本，又會拖累老員工的進度，怎麼合理的增加人力安排培訓，我們沒有這樣的培訓計劃，也沒有這樣系統思維，只是口頭上的口號，這是不起作用的，套用老師的話，不接地氣，以前我們新員工到崗，都會有一份員工培訓計劃，比如去年李國強經理給我做的員工培訓計劃（現在還在我文件夾裏），可惜這個優秀的傳統並沒有堅持下來。
三．短期的人力資源短缺與人員職責劃分的系統思考
我們項目老有個奇怪的現象，開發人員即是開發人員，也是測試人員，測試人員測試中，老是無故被開發中斷，因爲開發在測試中發現了bug情不自禁給改了，又上傳到服務器。造成測試環境中斷，最後測試也不是測試人員而是系統環境管理員，開發成了測試人員，又成了開發人員，雖然人手不夠是現實問題，老搞得開發不像開發，測試不像測試，大家職權不清，測試過程亂的一鍋粥。也不是辦法（現在大家也意識到這個問題了），短期我們看來是人力少（到底是不是人力問題上面也論述了，這裏是單講這個問題），但是我們項目似乎又把這個搞成一個傳統習慣的趨勢，每次遇到問題，老是一夥人全部按上去，除了測試工作其他都不做了。這樣測試做好，開發也做不好。
自己對問題的幾點思考和想法
我們已經知道這些問題的根源是系統思考，那麼知道了“道”，但是光有“道”沒有“術”是不接地氣的。我想到的“術”。
如果是我該如何？
1.多問自己爲什麼會出現這樣的問題
很多事情，在你沒有明白其原理時，上去做都會有問題，出了問題不可怕，可怕是不去思考，最後搞死自己。
2.當出現問題，我準備採取措施時候，想想我的措施會不會造成其他管理的變更？變更結果是好是壞，對其影響。
最典型的例子就是，比如我遇到測試人力不夠的問題時,要思考的是
1. 測試組人不夠，開發組肯定加過去。
2. 開發組人加過去怎麼管理？肯定不能讓開發那夥人佔了主導，讓他們隨便亂改，得讓測試組的人領導。
3. 這次就這麼過了，如果下次還這樣搞，那麼我開發人員都得停下手中的工作去搞測試，會影響項目進度。
4. 怎麼讓測試人力充足，在考慮成本情況下，能不能用技術的手段節省人力，比如迴歸測試怎麼自動化。
5. 如果技術手段還不夠怎麼增加人力，招聘需要什麼樣技能的？
6. 新員工進來後，怎麼培訓使之儘快上崗？
7. 試用期後新員工是否符合我的需求？
8. 怎麼將新的人力加入項目組合適的位置？