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