已經學習了《大道至簡》兩章，我們了解了程式設計的本質和「懶人」造就了方法。書中沒有提供給我們程式設計的技巧，捷徑，而是從別的方面為我們講解了程式設計的精義。第三章就為我們引入了「團隊」這個概念。
我們乙個人的時候是個體，兩個人的時候大家互相依賴，互相支撐即二人互立，這也不是團隊，當三個人的時候就是團隊了，而且有了團隊的一些基本特性：主從、監督和責任。乙個人的時候可以通過自身努力取得成功，兩個人的時候也可以互相幫助、依賴獲得成功。但是三個人的時候就要選乙個領導者來管理這個團隊了，選擇乙個有領導能力的，功勞大的來擔任這個角色。而擔任管理者角色的這個人最起碼要做到的就是能夠承擔責任，這是乙個管理者最基本的素質。書中借李離伏劍的故事為我們講述了這個道理「自己該承擔的責任不可以推卸給別人」。所以想要做乙個領導者除了有領導能力、有功勞最重要的還要有承擔責任的勇氣。
但是接到乙個軟體工程的時候，預期的工期不總是可以完成的，這可能無關乎專案經理的能力，或者團隊的工作能力，可能在一開始就估計錯了，所以專案經理往往在開始就承擔了犯錯的風險，這跟他們的經驗有關；那這個時候專案經理雖然有責任，但他們卻是可原諒的，因為他們需要時間來變得成熟，變得有經驗。
書中通過iso
質量體系的教訓教給我們又乙個道理，先確定團隊模式，才能尋求相應的管理制度，並且才能把這樣的制度實施在團隊之上。有人把這次的失誤歸於體制的問題，但這並不是十分正確的。「體制」有體有製，只是把管理制度分發給每個員工，是絕對不能成事的。所以在轉型期，第一要務是解決「體」的問題，也就是「組織機構建設」的問題。沒有確定的組織機構，當然也不能指望管理制度合乎人情了。
總之，在組織模式確定的同時，相應的制度也應該隨之建立。先做制度才是明智的。這樣就有辦法來維持你的組織模式，監督員工，懲戒員工。而對於乙個已經規範管理、體制健全的公司，不容許員工反錯是沒什麼錯的，只要有制度有法則在先，有公平性的制度在先。制度是不可以講情面的，如果有一次網開一面，那就有可能規矩變成了虛設，被公司員工作為笑柄，沒有任何威懾力可談，那這個制度也就離崩潰不遠了。這個時候重要的就是制度的修訂和補製了。所以毀掉制度的往往是管理者而不是員工，所以在制度面前既要做到「人性化」，又做得到「公平性」，管理者才會待得更長久吧。
在有了制度又有了可以程式設計的員工的時候，很多人就會說「那我們就開始吧」，這就是操之過急的結果了。因為還有直觀重要的一點需要管理員來做，那就是角色的分工和定位，這樣就不會出現那些不知道做什麼的人。作為乙個管理者，不是要去管理開發團隊，而是團隊協作，首先跟隨他們，找到他們的規律最後做一些有意義的改變，這才是王道。
作為乙個管理者，只需觀察他們，而不是加入他們，觀察之後彈性分工，將效率提高到最大。
看了《大道至簡》
無意間在網上翻到這本書，粗粗的看了一遍，有點感觸。可以研究細節，但不能陷入，可以一時陷入，但不能一世陷入。當然，這對技術狂熱者或許是除外的。如果要解決問題，那麼無論何種程式語言，都是一種工具，要做的是對於當前的問題選擇適合的工具。任何一種工具都是在某個情境下才可以區分孰優孰劣。中國的一些理論，很少放...
讀大道至簡
軟體開發 方法 過程 工程 組織 演算法 結構 方法 面向過程 物件導向 過程 瀑布模型 迭代模型 工程 專案管理 進度 成本 質量 組織 體制 組織結構和制度 是乙個向外擴充套件的過程。方法 分，模組化設計 過程 增量迭代，還是瀑布模型 工程 進度 成本 質量 組織 組織結構 制度 舉乙個做生意的...
大道至簡Segment Routing
聽了一下思科服務支援社群的講座，以下為筆記 1.基礎知識 1 igp基礎 ospf和中間到中間系統協議 2 bgp基礎 3 mpls 多協議標籤交換 2.模擬器為ios xrv 6.0.1 3.sr架構基於源路由。節點擊擇路徑，並且引導資料報沿著該路徑通過網路，做法是在資料報頭中插入帶順序的段列表，...