架構師作為項目組最資深的專業技術人員，是項目組開發測試工程師的前輩。從架 構師的身上，工程師可以看到自己的未來，因此架構師在做人做事方面需要嚴格要求自 己，做好表率。
關注人而不是產品
一定要堅信：一群優秀的人做一件他們熱愛的事，一定能取得成功。不管過程多麼 曲折，不管外人看來多麼不可思議不靠譜。
領導的真諦：尋找一個值得共同奮鬥的目標，營造一個讓大家都能最大限度 發揮自我價值的工作氛圍。
沒有懶惰的員工，只有沒被激發出來的激情。所有強迫員工加班的管理者都應該為 自己的無能而羞愧。
發覺人的優秀
是事情成就了人，而不是人成就了事。指望優秀的人來幫自己成事，不如做成一件 事讓自己和參與的人都變得優秀。
共享美好藍圖
架構師要和項目組全體成員共同描繪一個藍圖，這個藍圖是整個團隊能夠認同的， 是團隊共同奮鬥的目標。 藍圖應該是表述清楚的：產品要做什麼、不做什麼、要達到什麼業務目標，都需要 描述清楚。 藍圖應該是形象的：產品能為用戶創造什麼價值、能實現什麼樣的市場目標、產品 最終會長什麼樣，都需要形象地想象出來。 藍圖應該是簡單的：不管內部還是外部溝通，都能一句話說明白：我們在做什麼。 藍圖應該寫在軟件架構設計文檔的扉頁、寫在郵件的簽名檔、寫在內部即時通信群 的公告上。 在項目過程中，架構師要保持對目標藍圖的關注，對任何偏離藍圖的設計和決定保持警惕，錯誤的偏離要及時修正，必要的變更要經過大家討論，並且需要重新獲得大家 的認同。
共同參與架構
架構師需要對系統架構負責，但並不是說一定要架構師自己完成架構設計，並要項 目團隊嚴格遵守架構決策。 把架構和架構師凌駕於項目和項目組之上，只會讓架構師變成孤家寡人，讓架構曲 局和寡。
- 不要只有架構師一個人擁有架構
- 讓其他人維護框架與架構文檔
學會妥協
不要企圖在項目中證明自己是正確的，一定要記住，你是來做軟件的，不是來當老 大的。所以不要企圖去證明自己了不起，永遠也別幹這種浪費時間、傷害感情的事
很多時候，對架構和技術方案的反對意見，其實意味著架構和技術方案被關注、被 試圖理解和接受。架構師不應該對意見過於敏感，這時架構師應該做的是坦率地分享自 己的設計思路，讓別人理解自己的想法並努力理解別人的想法，求同存異。 對於技術細節的爭論應該立即驗證而不是繼續討論，當討論深入到技術細節的時候 也意味著問題已經收斂，對於整體架構設計，各方意見正趨於一致。 而當大家不再討論架構的時候，表明架構已經融入到項目、系統和開發者中了，架 構師越早被項目組遺忘，越表示架構非常成功；項目組越離不開架構師，越表示架構還 有很多缺陷。
成就他人
架構師作為團隊的技術領導者，在項目過程中不要去試圖控制什麼，帶著一個彈性 的計劃和藍圖推進，團隊會管好他們自己。你越是強加禁令，隊伍就越是沒有紀律；你 越是強制，團隊就越是不能獨立自主；你越是從外面尋找幫助，大家就越是沒有信心。
發現問題，尋找突破
其實即使是在一流的技術團隊裡，也一定有數不清的問題，只是人們習慣了這些問 題，以至於無視它們的存在。正所謂“魚是最後一個看見水的”，天天面對這些問題，反 而不覺得有什麼問題。
提出問題，尋求支持 問題被發現，它只是問題發現者的問題，而不是問題擁有者的問題，如果想要解決一個問題，就必須提出這個問題，讓問題的擁有者知道問題的存在。 找對關鍵人
- 把“我的問題”表述成“我們的問題”
- 給上司提封閉式問題，給下屬提開放式問題
- 不要問上司“你覺得該怎麼辦？”這種沒有建設性的開放式問題，給上司 提問題是希望能夠得到他的支持，而不是帶著一頭霧水等他去指點迷津。公司 付你薪水不是讓你睜著迷茫的眼睛賣萌。給上司提問應該是“你覺得A 和B 兩 個方案哪個更好？”這種封閉式問題。
- 指出問題而不是批評人 如果在合作中出現問題，告訴他問題的存在和緊迫性，而不是責問他為什 麼出現問題。
- 用贊同的方式提出問題
- 所謂直言有諱是指想要表達的意圖要直截了當說明白，不要兜圈子，但是 在表達方式上要有所避諱，照顧到當事人的感受。
解決問題，達成績效
- 在解決我的問題之前，先解決你的問題 先解決別人的問題有幾個好處： 你幫別人解決了問題，禮尚往來，別人也會幫你解決問題。 在幫別人解決問題的過程中，熟悉了情況，後面解決自己的問題也就得 心應手了。 解決別人的問題時使用的是你的解決方案，這個方案在你的控制之中， 將來往這個方案裡再塞一些東西解決自己的問題，手到擒來。
- 適當的逃避問題
閱讀更多 IT技術圈 的文章
