深度思考：關於技術團隊如何提效問題

前言

因爲我的進入了一個新的工做環境，新的環境就意味着新的問題，一些問題是我的的，一些問題是團隊的。。解決一個個問題的過程當中，必然會有一些好的方法論，值得咱們記錄和沉澱。

本着對公司負責的態度，在這裏，咱們不探討公司具體業務、數據、以及相關敏感問題。我在這裏只談我的感覺和理解。

是什麼阻礙了效率提高？

可能對於大多數團隊來講，都會遇到這樣的問題，團隊在10人之內，大概內保持必定的效率，超過10我的，溝通的成本，業務交接的成本，流程審批的成本等等，都會成爲效率提高的巨大障礙。甚至我說的這些所謂的「成本」，都是大而空的話，所謂影響效率的東西，太複雜了。。

當遇到一個需求

遇到一個需求，產品先進行消化，會產出原型，ui看到的東西，出設計圖，前端經過設計圖，作頁面，後端提供service，先後端再接口對接，測試進行功能測試，最終上線。整個流程，只要一個環節出現問題，整個業務的吞吐量就會極速降低。

假如我是一個前端，我此時會面臨什麼？

整個流程中，實際上是一個個個體組成的，假如我是一個前端，會面臨這麼一些問題：

對於需求，可能沒理解透，產品出的原型圖，我作出告終果，可是徹底不是產品要的東西。。

對於產品，可能產品設計出來的原型，可是我以爲有問題，由於從技術實現的角度，這種設計有邏輯漏洞。。

面對ui，可能產品是對的，可是ui設計就是出不來設計圖，而前端的開發週期就那麼多，阻礙了前端的進度。。

到了後端這裏，前端的開發依賴接口文檔，後端同窗死活給不出來接口文檔，緣由是啥呢？後端同窗以爲產品的原型設計有問題，得和產品對接一下具體實現方法。。

到了測試這裏，測試以爲前端這麼作不對，得達到另外一種效果。。或者測試進行測試的過程當中，發現了一個老代碼的bug。。

假如我是一個新人的時候

我可能會比較崩潰，我不明白同事說的各類業務名詞。。

作一個新的需求的時候，我不懂總體架構。。

測試出來了老代碼的bug，我不明白究竟是我代碼的問題，仍是哪裏出現了問題。。

假如和你合做的後端換人了。。新的後端你感受啥都不懂的時候。。

最後總結

效率炸了。。可能20我的的團隊，產出還不如10我的的團隊。

大多數企業是怎麼作的

這些複雜的問題，咱們甚至沒辦法理出來一條線，試問心裏，到底怎麼作？

咱們能夠看看行業內，你們的共識，到底如何作？我我的先列舉幾條。

1，需求討論會

這是最基本的一個解決方案，產品理清需求，定一個會議室，由產品給你們講，接下來咱們準備作什麼？有什麼風險？技術能否實現？

需求研討會，解決了很是多的問題，它儘量的讓你們理解咱們作的業務，它儘量的讓你們提早規避了技術風險，它也儘量的讓你們處於一個頻道里理解一件事情。

2，團隊負責人機制

業務的進度怎麼保證？如何監控到項目週期的每一個節點的阻塞點？如何協調前端、後端、產品、測試各個方面的資源？這就是團隊負責人的角色。

3，標準開發流程

通常的公司的開發流程，就是我上面提到的從產品，到ui，到開發，到測試的一系列流程。定義了何時出ui圖，何時出接口文檔，給出排期等等。

咱們還有哪些痛點？

是的，這裏要問每一個人，到底爲何還有那麼多的團隊，效率仍是很低下？

咱們思考一些流程問題：

產品講需求的時候，假如原型圖有缺陷，何時能給出修正好的結果？

開發過程當中，產品又有新的需求變動怎麼辦？

ued何時給出詳細設計圖？假如不符合要求怎麼辦？

開發過程當中，若是遇到沒法繞過的項目架構設計缺陷怎麼辦？

測試什麼時候能給出測試用例？測試出老代碼的bug算不算bug？

發現了沒有，永遠有問題困擾着咱們。

四、詳細的規範流程，就是解決這些問題的辦法

又有人問，什麼是詳細，什麼又算做詳細？其實這裏沒有答案，真正的答案在於本身的團隊之中。

團隊有大有小，小而精的團隊，過於繁瑣的流程，會制約他們的生產力。

好比如今團隊很小，只有三我的，可是都是大佬，每一個人對業務都很是熟悉，都知道咱們要作什麼，你們天天坐在一塊兒，這個時候，其實連需求會都不須要開，只須要出個原型，隨便說兩句你們就懂，直接作。。

好比如今是一個大概幾十人的技術團隊，你們不是那麼熟悉，可能業務也都不熟悉，因此，爲了解決需求理解問題，咱們要開需求會，爲了讓需求會更有效果，咱們得讓產品提早一天或者兩天給出會議綱要和prd圖，爲了保證測試的準確度，咱們要讓測試寫測試用例，爲了保證測試覆蓋率，要有測試用例評審，爲了保證項目週期進度，咱們要每一個人參與各個複雜的環節。。。

可是全部的目標只有一個，保證產出的質量和效率。

所謂的規範流程，就是經過本身團隊的特性，制定出來的流程。

問題：假如咱們的業務太龐大

複雜業務的團隊，常常對咱們開發人員有更高的要求，假如咱們同時併發的需求多是5個，每一個需求的前端，後端，測試，產品，都不同，咱們的需求更有可能依賴各類中臺、第三方。。

誰來推進整個需求？顯然一個Team Leader是不夠的。

五、用項目owner的方式，保證複雜需求的進度

咱們須要有一個虛擬角色，就是項目owner，項目owner就是來把控整個項目的週期。

通常而言，項目owner有這麼一些特色：對業務很是熟悉；是一線開發人員，能切身體會到當前遇到的瓶頸問題；溝通成本低，對項目中的每一個人都能作到良好溝通。

問題：假如咱們沒有gitlab，會發生什麼？

能夠說，git給咱們的代碼管理，提供了極大的方面，若是沒有這樣的基礎工具，那基本上沒辦法作多人開發的協做了。。。

常見的企業級開發工具包括：gitlab、wiki、rap、jira、釘釘。。解決了咱們一系列問題。

但是有太多制約咱們生產力的地方了。。

好比，每次上線，都要讓運維同窗幫忙，每次發佈一個測試包，可能咱們都要到某個平臺手動部署一次，甚至還有些公司用上傳文件的方式部署代碼。。

好比咱們項目變大了，編譯速度變得超級慢，該一行代碼，須要等4秒左右才反應過來。。

好比每次開發，只要是新的需求，咱們好多類似的代碼，都要從新寫一遍。。

六、良好的基礎設施，是提效關鍵

解決這些問題，其實本質上是基礎設施的建設。。

咱們能夠作自動部署平臺。。

咱們能夠作高效腳手架工具研發。。

咱們能夠作組件庫建設。。

咱們能夠作自動化測試工具研發。。

以上的種種，都是基礎設施。

問題：有些團隊比較特殊，一些應用用這個框架來寫，一些應用用那個框架來寫，這個時候問題在哪？

業界有很多這樣的團隊，不少大廠以爲本身技術很牛，無所謂用什麼框架，確實，在牛人眼中，寫啥都沒問題。。

可是咱們要換個角度看問題，技術的本質，是爲了給業務作支撐，當業務很是複雜的時候，若是仍是無所謂框架的話，那其實頗有可能形成的結果就是無所謂沉澱。。

所謂的無所謂沉澱就是，我在框架a中沉澱下來的基礎組件，無法用在框架b的業務中。

七、統一的技術體系和標準，下降開發人員的介入成本

想象一個場景，若是咱們要作100個app，若是用一個統一的框架，因爲業務的相關性，咱們能夠抽離出很是多的中臺組件，提供給這些app使用。。

假如是不一樣的框架，作起公用的東西，就太費勁了。

在統一的技術體系中，我能夠定製很是多的東西：

類似的項目結構。。

統一的代碼風格。。

不用重複造輪子，全部的難點統一解決。

這樣的話，咱們的關注點基本就在業務的層面，團隊人員的業務吞吐量，就會極速的提高。

問題，假如咱們的服務太雜的話，會發生什麼？

這裏所謂的雜，就開始可能有一個服務，隨着業務的發展，發展到幾十個服務。。

這時候，服務a可能依賴服務b，服務b又依賴服務a，咱們整個幾十個應用，因爲開始階段，沒有考慮的太多，致使如今一個小小的需求改動，代價都異常的大。

咱們不知道，哪一個階段的數據出了問題，致使本來的應用，出現了異常。。

咱們也不知道，哪些服務會有性能瓶頸，會致使服務不穩定。。

咱們更不知道，咱們的數據表的定義是否是規範，一個字段的刪除，會不會影響其餘的服務。。

八、完美的架構設計，從新煥發業務的生產力

這個咱們須要從新對整個系統，進行重構。。

咱們要進行業務拆分，分清楚業務的邊界狀況。。

咱們要對架構分層，好比弄清楚什麼是業務層，什麼是中臺層。。

服務的依賴關係，如何整理。。

作好整個的架構設計，才能放手去博取業務的將來。。

問題，假如領導決定的東西，團隊的人不認同怎麼辦？

常常會有這樣的一些問題，領導說怎麼怎麼作，底下人聽着，事後就忘了。。

有時候，底下人以爲領導很SB，作事不靠譜。。

有時候，領導以爲手底下人，都是菜雞，連一點小事都辦很差。。

所謂的提效，落腳點都是人。。怎麼把人解決好。。

9，解決好人的問題，是提效的關鍵

好比我一進入一個團隊，就來了一個需求，這個項目很是複雜，結果，作砸了。。

其實這是一個常見的問題，不少老員工都會出線上故障，更別說是新員工。問題的關鍵就是，做爲一個團隊，有沒有對新人有相關的業務培訓？甚至價值觀培訓？有沒有爲員工的成長負責？其實這是一個雙向的過程，通過公司的培養，員工成長了，員工反哺公司業務，承擔更大的價值。

本質上，是要把團隊和我的的利益，儘量的保持在同一種節奏中

一件事情，領導想到了，而後告訴你們怎麼作，顯然不可能成功。。不是說，領導的想法很差，而是領導的想法，如何讓你們以爲好，也要讓你們知道怎麼作。。

本質上，咱們要作到達成共識。。

人的問題，是一個很是複雜的問題，涉及到人員招聘、人員培養、價值觀、技能、性格等一系列問題。

可是核心就是處理好兩個關係：團隊和我的、上級與下屬。

讓團隊與我的，頻率同步，達成共識，全員參與，共同成長，才能真正作到提質增產的目的。