一、前言

最近有幸拜讀了《技術(shù)力量-一線技術(shù)團隊成功啟示錄》的第一篇-Team Leader團隊管理/組織發(fā)展，該篇從組織架構(gòu)、團隊管理、效能提升、敏捷轉(zhuǎn)型這四個方面展示了10位來自不同行業(yè)、不同領(lǐng)域的專家的不同看法，貌似形態(tài)各異，實則殊途同歸。

?

二、康威定律

梅爾.康威于1968年提出的“任何組織在設(shè)計一套系統(tǒng)時，所交付的設(shè)計方案在上都與該組織的溝通結(jié)構(gòu)保持一致。”，這句話就是后來的康威定律。

??????? 從微軟的Office性能團隊項目經(jīng)理楊珂的分享中看到之所以其性能團隊能夠成功，我看到的是其團隊成員的專業(yè)技能外，還有正確的團隊組織結(jié)構(gòu)及交互方式。他的OPERF團隊會要求每個其他應(yīng)由團隊（如PPT、Excel）要指定一兩個“性能聯(lián)系人”，這樣OPERF團隊就能跟每個應(yīng)用團隊有機建立了“連接”。反思回團隊內(nèi)部，目前整個渠道條線中每個渠道團隊基本上都是各自為政的，這樣的弊端就是即使架構(gòu)組已經(jīng)定義了標準的技術(shù)體系與架構(gòu)選型，但是在每個團隊的實際項目過程中的細節(jié)實現(xiàn)會更多的站在自己團隊去思考，即可能會造成重復建設(shè)、平臺建設(shè)進度慢、平臺通用化程度不高等問題。因為就算是渠道是個性化的，但是不同渠道還是有一定的共性（如用戶中心、推送中心、進銷存中心等），而這些共性則構(gòu)成了平臺化建設(shè)的必要性。參考了阿里的共享服務(wù)團隊的建設(shè)經(jīng)驗，我覺得在渠道端需要做兩個事情：

重新要針對渠道系統(tǒng)進行整體的業(yè)務(wù)流程、功能模塊梳理，把所有的共性識別出來；

針對這些“共性”服務(wù)，為了確保共性服務(wù)的成功建設(shè)，更多應(yīng)該組建一個業(yè)務(wù)平臺小組，而且這個平臺的成員最好是從各個業(yè)務(wù)系統(tǒng)抽調(diào)，這樣做的好處是可以保證每個人對每個業(yè)務(wù)系統(tǒng)都是最了解的，同時又因為他們的職責（即KPI）更加“專一”，即平臺化就是他們最優(yōu)先解決的目標，這樣這個平臺化的工作才能更容易推進。

?

三、敏捷轉(zhuǎn)型

??????? 道富科技是全球性的金融服務(wù)提供商，它們從2013年9月開始在IT研發(fā)和維護部門開始了敏捷轉(zhuǎn)型工作，從傳統(tǒng)的職能型組織架構(gòu)、瀑布軟件開發(fā)模型向跨職能團隊（即特性團隊）和分布式Scrum開發(fā)模型轉(zhuǎn)變。在整個敏捷轉(zhuǎn)型過程中他們堅持了以下三個原則：

• 梳理并堅持清晰的團隊目標
• 堅持質(zhì)量和業(yè)務(wù)價值重于速度和形式
• 堅持養(yǎng)成自組織團隊

1、統(tǒng)一團隊目標

??????? 首先，團隊對敏捷轉(zhuǎn)型的態(tài)度是怎樣，支持、反對還是觀望？團隊目前的最痛點（即主要矛盾）在哪里？團隊最痛點能否通過敏捷模式去解決？我覺得如果沒有先去理清和解決這個問題，敏捷能持續(xù)推進下去并成功的可能性不高。因為團隊成員從心底里就不認同這套方法論。人是有惰性的，團隊也一樣，如果團隊在沒有足夠痛的情況下，是不太可能主動變更自己現(xiàn)有的工作模式，因為改變意味著不確定性，不確定性意味著潛在失敗。

2、堅持質(zhì)量和業(yè)務(wù)價值重于速度和形式

??????? 首先，我認為覺得開發(fā)團隊價值的，是要看能不能提供業(yè)務(wù)價值，而不是做得有多快。團隊在一開始推行敏捷的時候因為“初戰(zhàn)告捷”就變得輕浮，一味的高歌猛進，每個迭代都不遺余力的幫團隊提升迭代產(chǎn)能，搞得好像“眾人拾柴火焰高”一樣，這樣非但沒有好處，更會為團隊帶來隱患。

首先，初期開始時候每個人的精神狀態(tài)都是高度亢奮的，這樣的產(chǎn)能根本不能完全代表團隊的穩(wěn)定產(chǎn)能，反而會讓團隊失去原來的“免疫力”，如果后面的迭代由于某些原因?qū)е庐a(chǎn)能的持續(xù)下降或者不穩(wěn)，會導致團隊變得很脆弱從而導致團隊對敏捷產(chǎn)生懷疑，更甚至產(chǎn)生對立情緒，因為當人一遇到困難后且新環(huán)境還沒有正式變成其舒適圈前，因為人由于趨利避害的特征往往會回到自己的原有作業(yè)模式中。

另外，因為時間、成本與質(zhì)量本來就是項目管理的互相影響的三個極；當在成本（即資源）不變的情況下，時間越短產(chǎn)能越高，但是質(zhì)量則是越差。回顧我們之前的敏捷推廣的初期，很多同事動則就拿敏捷來說事，在開發(fā)過程逐漸忽略了文檔的重要性，還美其名曰“敏捷就是免文檔”，實則是拿敏捷作為借口。在我認為，敏捷倡導交流重于文檔是有一定的基礎(chǔ)：

1）當然我們不是要按照CMMI的那套條條框框用最重的流程去要求準備文檔，我們是在敏捷過程中適當?shù)牟眉粑覀兊奈臋n；

2）文檔的編寫最好是有相關(guān)工具支撐以便把編寫成本最低化，最好能做到所寫即所得，如在某些團隊在編寫接口文檔采用目前較為流行的Swagger，這樣可以通過在代碼中加入注釋則可以一鍵生成接口文檔，同時這個接口文檔直接就可以作為接口測試的文檔使用。

?

四、團隊培養(yǎng)

從奇虎360高級技術(shù)經(jīng)理吳亮的分享來看，他為其負責的前端團隊確立了團隊的三大核心價值-三層金字塔：

• 金字塔基：服務(wù)業(yè)務(wù)
• 金字塔中部：基礎(chǔ)平臺
• 金字塔頂部：技術(shù)服務(wù)

金字塔基：服務(wù)業(yè)務(wù)

因為我們首先是一支服務(wù)于業(yè)務(wù)產(chǎn)品的團隊，接著我們才是技術(shù)團隊，我們需要用最佳的服務(wù)意識和合作態(tài)度去提供必要的服務(wù)。在很多的技術(shù)人員的意識層面總是認為自己只是一名技術(shù)人員，總以技術(shù)我最懂自居，經(jīng)常使用一些復雜或者未經(jīng)過驗證的技術(shù)去實現(xiàn)業(yè)務(wù)需求，其他人稍有不同意見并“孤芳自賞”；殊不知這樣的做法只會讓自己脫離群眾，脫離實際，脫離團隊，而且自己本身對這個技術(shù)也是一知半解。愛恩斯坦說過：“萬事應(yīng)該簡單化，但不應(yīng)太簡單”。這句話引申到我們的實際工作，就是說針對業(yè)務(wù)需求（業(yè)務(wù)目標），我們優(yōu)先考慮的應(yīng)該是兼顧時間、成本、復雜度的解決方案，而非一味追求技術(shù)熱點。

金字塔中部：基礎(chǔ)平臺

當我們的團隊成型以后，我們開始提供各種各樣的服務(wù)，負責跟進各種各樣的業(yè)務(wù)需求，也踩過各式各樣的“坑”；這個時候我們需要開始怎么去把我們的經(jīng)驗沉淀下來，這個時候的基礎(chǔ)平臺就是為了順應(yīng)發(fā)展而不得不構(gòu)建的平臺，這個平臺本身就是作為從團隊經(jīng)驗固化到流程、工具里面的一個極佳體現(xiàn)。當我們有了這個基礎(chǔ)平臺后，我們才具備快速試錯的也能能力。

金字塔頂部：技術(shù)服務(wù)

這里其實包含了兩層的工作。第一，在我們把這個基礎(chǔ)平臺推廣到整個開發(fā)室或者部門使用的過程中，我們決不能做甩手掌柜。為了保證平臺推廣的有效性，我們輸出的應(yīng)該是基礎(chǔ)平臺外加技術(shù)服務(wù)，在應(yīng)用團隊遇到問題的時候提供必要的協(xié)助；第二，這個基礎(chǔ)平臺除了滿足業(yè)務(wù)使用后，我們需要在持續(xù)收集應(yīng)用團隊的意見的基礎(chǔ)上優(yōu)化該基礎(chǔ)平臺以便提升其通用性，說白了其實就是要打造該平臺的產(chǎn)品化。

另外，從整個平臺化三步走的過程來看，技術(shù)人員的工作從單純的功能開發(fā)、設(shè)計、技術(shù)支持、產(chǎn)品化優(yōu)化不斷過渡，也為技術(shù)人員的從一專一能的I型人到一專多能的T型人才，再到多專多能的E型人才的發(fā)展提供了相應(yīng)的在崗實踐路徑，這樣人才能力的提升又反哺業(yè)務(wù)和系統(tǒng)。

總結(jié)

以上是生活随笔為你收集整理的聊一下《技术力量-一线技术团队成功启示录》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。