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