最近發(fā)現(xiàn)一本有意思的項目開發(fā)書籍，晚上睡不著的時候讀，特別提神。
為了不金玉與內，特摘錄其中一些片段，供大家玩味，書名叫做《大道至簡》，作者是誰，大家網上查一下就知道了：）
以下為引用,雖然不是每句都對，但可以帶給我們思考： (覺得不過癮可以參照附件，不過請下班后再看哦)
1.一接到任務就開始Coding的程序員，通常就是加班最多的程序員。
記住：積極工作和勤于思考都要占時間。
2.做管理起碼需要能承擔責任，這是最基本的素質。
3.你的項目經理職位又沒有讓給別人做，你拿的經理級工資又沒有分給別人，那項目失敗了，你為什么要把責任推到別人頭上呢？
4.經驗豐富的工程師能盡可能接近地預估工期，但沒有辦法保障(預估的)工期是絕對合理的。那么進一步的推論是，由于沒有絕對
合理的工期，所以項目的完成時間可能總是
被進度變更所修正，所以項目也就總是不能“成功”。項目工期的問題不能解決，就不能保證項目成功。只有經驗更加豐富，才能
更盡可能地逼近“合理的工期”。因此在此之前，項目
經理面臨的就是失敗。這個失敗可能不是項目經理本身能力所決定，或者也不是團隊成員的工作所決定，而是在一開始，那份給客
戶的項目協(xié)議就簽錯了。
5.軟件工程中有專門的學科來研究項目的工期問題。學者們試圖尋找公式來計算項目的復雜度，從而計算出所需的工時和人月。然
而在實踐中，這被認為是不可行的
6.如果員工在工作中出了紕漏：
沒有制度，你沒有辦法和依據來懲戒員工，因此是管理者的過失；
有了制度而沒有懲戒他，是執(zhí)行者和監(jiān)督者的過失；
一而再、再而三地犯錯，又一而再、再而三地被懲戒，那就是教而不改，就真正是員工的品性和素質的問題了
7.在任何錯誤被歸咎于員工之前，管理者應該先想想是不是自己的問題。是的。你可能很快發(fā)現(xiàn)問題出在了管理者。因為管理者沒
有
確定組織機構模式，或者沒有為組織中的成員進行角色定位和分工。如果這樣，出現(xiàn)“既不能令，又不受命”的人就是必然的事了
8.一個至少由三個人構成團隊：項目經理，開發(fā)經理和開發(fā)人員。其中，在開發(fā)經理和開發(fā)人員之間，既存在主從關系，也存在協(xié)
作
關系。而項目經理，則在團隊中處于領導者、組織者和團隊保障者的地位。如果非得要精簡到兩個角色的團隊模式，那么這種情況
下，通常是開發(fā)經理兼任項目經理，因此這位開發(fā)經理一定要能清楚地區(qū)分這種雙層角色的身份：在任何時候，明確自己是在進行
“團隊內協(xié)作”、還是“團隊管理(和組織)”、還是在與“團隊外交流”。如果這個開發(fā)經理總是混淆自己的角色，那么，我建議
，換人吧。
9.團隊真的需要管理嗎？
這經常是“經營”開發(fā)團隊的管理者最容易給錯答案的問題。這些管理者兢兢業(yè)業(yè)，試圖細化每一個管理環(huán)節(jié)，將自己的意愿貫徹
到??EN，CPU里去。
實際上，開發(fā)團隊并不需管理?；蛘哒f，在你還沒有弄清楚狀況之前，不要去管它。
10.稟性難移，要改變一個人都難，何況是改變一個團隊的既定習慣。
如果有一群開發(fā)人員象螞蟻一樣辛勒地工作著，那么，先不要打擾他們。你應該跟隨他們，看看他們是如何做的。發(fā)現(xiàn)規(guī)律，分析
這個規(guī)律的價值，最后再嘗試改變它們(的一些負面價值的規(guī)律)。
11.盡管彈性分工非常有效，然而真正做彈性分工卻并非易事。
更好的選擇是明確分工，而不是彈性分工。你應該明白，重要角色的更替通常是極具風險的，例如項目經理或
者開發(fā)經理；頻繁的開發(fā)人員的調度也會直接影響到工程的質量和進度。
12.維護舊項目比做新項目更難，許多人深有同感。然而這些“有同感”的人又何曾想過，自己在做“新項目”的時候，要為“項目
維護”這種還不存在的角色，留下一個溝道、對話的渠道呢？
我把項目的History作為跟這種“不存在的角色”溝通的一種方式。History的豐富和準確為項目的后繼開發(fā)、維護提供了可能。
13.UML的確是解決溝通問題的最佳手段之一。然而如果項目一開始就不能用它，那么強求的結果必然是痛苦的?！孶ML在一個
沒有經過相關培訓的團隊及其各個角色之間用起來，幾乎是不可能的事。即使用得起來，也存在經驗問題。千萬不要指望僅僅一個
項目，就能讓你的組員深刻的理解UML的思想。使用與不使用UML，其根本的問題在于溝通方式的選擇。只要是行之有效的、能在各
個項目角色間通用的，就是好的溝通方式。
14.流于形式的溝通，可能是使得你的項目被不斷推翻和不斷延遲的最直接原因。
15.相對于瀑布模型，V模型有改變了什么嗎？是的。源于實際的需要，它把測試(和評審)階段抽取出來，于是就成了V模型。
16.用RUP用不好的人，總會說自己終歸還有一堆文檔模板可以抄
17. 如果懂得了所謂的模型原本都演化自那個簡單的瀑布，那么文檔是按XP寫還是按RUP寫，也就可以應時、應需，因地置宜，擇善
而從了。
18. RUP中，真正精髓的東西，既不是那個R(Rational)，那是人家的招牌；也不是那個U(Unified)，那是人家的廣告。而是那個P
(Process)，那才是實實在在的東西。
19.無論是你的團隊成員，還是你的老板，對重復的錯誤以及可預料的錯誤都是不會寬容的?！谝粋€團隊中，失去了組員的信任
比失去老板的信任更為可怕。所以回顧每一個項目，或者項目中的每一個階段，以及與每一個團隊成員交流的細節(jié)，是你的日常工
作。
20. RUP其實就象一個雜物箱一樣“包容”了全部的已知理論。
21. 總之一件事，沒有人會跳出來說：我們原本就錯了。然而事實上可能真的出在源頭：我們把目標定錯了。
我們看到，在項目的平衡三角(時間、資源和功能)中討論的是目標問題，但并不討論質量問題。也就是說，經典教材中總是關注：
如何更快的完成項目，并減少資源占用，以及實現(xiàn)更多的功能。然而，即使平衡了這種關系，項目的結果仍可能產生一個天生的殘
障。
因為目標可能在平衡中確立，但質量卻要在過程中控制。即使在時間、資源和功能三者中取得了平衡，即使客戶、項目組和公司同
樣滿意于這個平衡“目標”，它仍然有可能是“不能實施”的。
如果原定的目標(的整體)本身就過大，那么無論如何平衡這三者之間的關系，其結果仍舊是保障不了質量。
22.大多數情況下，管理人員有責任去審核、評估其它成員的工作成果。這個時候可以討論“細節(jié)決定成敗”這樣的問題，因為這決
定了產品的最終質量，而質量是工程的目標之一。
而在另一些情況下，例如管理人員做事件的決策的時候，就必須要學會忽略枝節(jié)問題。
23. 從慣于“實做”的程序員一路走來的工程人員，很難分清自己什么時候是在“工作”，而什么時候又是在“決策”。
因此我只好用最笨的方法提示管理者：別管它是細節(jié)還是枝節(jié)，只要你感到你的腳趾已經沾上了泥淖，就快點回頭。
用腳趾去感覺，有時比用頭腦去思維來得有效。
