最近有幸拜讀了《技術力量-一線技術團隊成功啟示錄》的第一篇-Team Leader團隊管理/組織發展，該篇從組織架構、團隊管理、效能提升、敏捷轉型這四個方面展示了10位來自不同行業、不同領域的專家的不同看法，貌似形態各異，實則殊途同歸。
梅爾.康威於1968年提出的「任何組織在設計一套系統時，所交付的設計方案在上都與該組織的溝通結構保持一致。」，這句話就是後來的康威定律。
從微軟的Office效能團隊專案經理楊珂的分享中看到之所以其效能團隊能夠成功，我看到的是其團隊成員的專業技能外，還有正確的團隊組織結構及互動方式。他的OPERF團隊會要求每個其他應由團隊（如PPT、Excel）要指定一兩個「效能聯絡人」，這樣OPERF團隊就能跟每個應用團隊有機建立了「連線」。反思回團隊內部，目前整個渠道條線中每個渠道團隊基本上都是各自為政的，這樣的弊端就是即使架構組已經定義了標準的技術體系與架構選型，但是在每個團隊的實際專案過程中的細節實現會更多的站在自己團隊去思考，即可能會造成重複建設、平臺建設進度慢、平臺通用化程度不高等問題。因為就算是渠道是個性化的，但是不同渠道還是有一定的共性（如使用者中心、推播中心、進銷存中心等），而這些共性則構成了平臺化建設的必要性。參考了阿里的共用服務團隊的建設經驗，我覺得在渠道端需要做兩個事情：
- 重新要針對渠道系統進行整體的業務流程、功能模組梳理，把所有的共性識別出來；
- 針對這些「共性」服務，為了確保共性服務的成功建設，更多應該組建一個業務平臺小組，而且這個平臺的成員最好是從各個業務系統抽調，這樣做的好處是可以保證每個人對每個業務系統都是最瞭解的，同時又因為他們的職責（即KPI）更加「專一」，即平臺化就是他們最優先解決的目標，這樣這個平臺化的工作才能更容易推進。
道富科技是全球性的金融服務提供商，它們從2013年9月開始在IT研發和維護部門開始了敏捷轉型工作，從傳統的職能型組織架構、瀑布軟體開發模型向跨職能團隊（即特性團隊）和分散式Scrum開發模型轉變。在整個敏捷轉型過程中他們堅持了以下三個原則：
- 梳理並堅持清晰的團隊目標
- 堅持品質和業務價值重於速度和形式
- 堅持養成自組織團隊
首先，團隊對敏捷轉型的態度是怎樣，支援、反對還是觀望？團隊目前的最痛點（即主要矛盾）在哪裡？團隊最痛點能否通過敏捷模式去解決？我覺得如果沒有先去理清和解決這個問題，敏捷能持續推進下去併成功的可能性不高。因為團隊成員從心底裡就不認同這套方法論。人是有惰性的，團隊也一樣，如果團隊在沒有足夠痛的情況下，是不太可能主動變更自己現有的工作模式，因為改變意味著不確定性，不確定性意味著潛在失敗。
首先，我認為覺得開發團隊價值的，是要看能不能提供業務價值，而不是做得有多快。團隊在一開始推行敏捷的時候因為「初戰告捷」就變得輕浮，一味的高歌猛進，每個迭代都不遺餘力的幫團隊提升迭代產能，搞得好像「眾人拾柴火焰高」一樣，這樣非但沒有好處，更會為團隊帶來隱患。
首先，初期開始時候每個人的精神狀態都是高度亢奮的，這樣的產能根本不能完全代表團隊的穩定產能，反而會讓團隊失去原來的「免疫力」，如果後面的迭代由於某些原因導致產能的持續下降或者不穩，會導致團隊變得很脆弱從而導致團隊對敏捷產生懷疑，更甚至產生對立情緒，因為當人一遇到困難後且新環境還沒有正式變成其舒適圈前，因為人由於趨利避害的特徵往往會回到自己的原有作業模式中。
另外，因為時間、成本與品質本來就是專案管理的互相影響的三個極；當在成本（即資源）不變的情況下，時間越短產能越高，但是品質則是越差。回顧我們之前的敏捷推廣的初期，很多同事動則就拿敏捷來說事，在開發過程逐漸忽略了檔案的重要性，還美其名曰「敏捷就是免檔案」，實則是拿敏捷作為藉口。在我認為，敏捷倡導交流重於檔案是有一定的基礎：
1）當然我們不是要按照CMMI的那套條條框框用最重的流程去要求準備檔案，我們是在敏捷過程中適當的裁剪我們的檔案；
2）檔案的編寫最好是有相關工具支撐以便把編寫成本最低化，最好能做到所寫即所得，如在某些團隊在編寫介面檔案採用目前較為流行的Swagger，這樣可以通過在程式碼中加入註釋則可以一鍵生成介面檔案，同時這個介面檔案直接就可以作為介面測試的檔案使用。
從奇虎360高階技術經理吳亮的分享來看，他為其負責的前端團隊確立了團隊的三大核心價值-三層金字塔：
- 金字塔基：服務業務
- 金字塔中部：基礎平臺
- 金字塔頂部：技術服務
因為我們首先是一支服務於業務產品的團隊，接著我們才是技術團隊，我們需要用最佳的服務意識和合作態度去提供必要的服務。在很多的技術人員的意識層面總是認為自己只是一名技術人員，總以技術我最懂自居，經常使用一些複雜或者未經過驗證的技術去實現業務需求，其他人稍有不同意見並「孤芳自賞」；殊不知這樣的做法只會讓自己脫離群眾，脫離實際，脫離團隊，而且自己本身對這個技術也是一知半解。愛恩斯坦說過：「萬事應該簡單化，但不應太簡單」。這句話引申到我們的實際工作，就是說針對業務需求（業務目標），我們優先考慮的應該是兼顧時間、成本、複雜度的解決方案，而非一味追求技術熱點。
當我們的團隊成型以後，我們開始提供各種各樣的服務，負責跟進各種各樣的業務需求，也踩過各式各樣的「坑」；這個時候我們需要開始怎麼去把我們的經驗沉澱下來，這個時候的基礎平臺就是為了順應發展而不得不構建的平臺，這個平臺本身就是作為從團隊經驗固化到流程、工具裡面的一個極佳體現。當我們有了這個基礎平臺後，我們才具備快速試錯的也能能力。
這裡其實包含了兩層的工作。第一，在我們把這個基礎平臺推廣到整個開發室或者部門使用的過程中，我們決不能做甩手掌櫃。為了保證平臺推廣的有效性，我們輸出的應該是基礎平臺外加技術服務，在應用團隊遇到問題的時候提供必要的協助；第二，這個基礎平臺除了滿足業務使用後，我們需要在持續收集應用團隊的意見的基礎上優化該基礎平臺以便提升其通用性，說白了其實就是要打造該平臺的產品化。
另外，從整個平臺化三步走的過程來看，技術人員的工作從單純的功能開發、設計、技術支援、產品化優化不斷過渡，也為技術人員的從一專一能的I型人到一專多能的T型人才，再到多專多能的E型人才的發展提供了相應的在崗實踐路徑，這樣人才能力的提升又反哺業務和系統。