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