有將近兩個多月沒有更新博客，也沒寫過一篇博文。因爲最近太忙了，除了工作強度高之外，每天的工作狀態和節奏也不對。
11月中旬公司進行了大的組織架構調整，我所在的業務中心被重組，原來的大領導變成總監，總監變部門領導，部門領導變普通員工，因爲上層政治鬥爭的緣故，我們整個部門都淪爲人力資源中心。 那段時間大家都人心惶惶，堅持了4個月的數據中臺項目也被即刻叫停，所有沒在有合同額項目上的員工全部要出差，在有合同額項目上的人被嚴重壓縮。最終12月的第二週，我們java五人小團隊4個人被安排到北京出差，作爲人力資源去支援總部業務線的其他項目。新的環境，新的項目，新的團隊，新的挑戰。
從最初抱着一定要做好工作，到現在覺得無法再待下去，短短2個多月的經歷，刷新了我對團隊管理的認知。我不知道是因爲我們的抗壓能力太差，還是北京那邊團隊管理太差，或者說是因爲我們做事方式不對，還是因爲北京團隊那邊做事太無章法。總之，我現在站在圈子裏面，或許會存在看不清真像，有失偏頗的認知。但我還是想靜下心來想一想，問題到底在哪裏？所以有了這篇非技術的博文記錄。 我想記錄下現在經歷，寫下我對項目管理、團隊管理的看法，以及我認爲怎樣的團隊纔是有戰鬥力的團隊，怎樣的團隊氛圍纔是健康的團隊氛圍。
這裏先列一下北京那邊團隊的工作節奏和方式：
工作模式：無條件無理由強制早十晚十加週六。
【對於加班，我是不排斥的，我始終認爲IT行業的加班有時候是不可避免的，有些時候就是留給開發的時間太短，就要求你加班，有的時候是你不加班儘快做出來，就失去了機會，這些都是不可避免的。但是對於因爲管理問題造成開發進度緩慢而要求所有人不可不加班或者有事沒事就加班的制度，我是一點都無法認可的】
團隊組成：北京的團隊有大概10幾個人，有兩個專職前端，剩下的都是後端服務開發。一個開發負責人，一個項目產品負責人。
使用的技術：前端使用vue。後端使用基於dubbo的微服務架構。包括有客服中心、客戶中心、在線中心、熱線中心、工單中心、機器人中心、知識中心、平臺中心、權限中心、會話中心、鑑權中心等幾十個微服務。 前端也是針對每一塊都有一個獨立的vue工程。
【這塊在部署和發版的時候使用jenkins，但是在工程的管理上，我認爲是有點亂，任何一個小的功能都是讓去做一個獨立的工程，微服務的架構是提倡把相對獨立的功能放到一個獨立的微服務中，但是不是無節制無思考的進行服務的劃分和工程的創建。按照目前的方式，後期的運維將會是非常大的問題，不做負載的情況下也有差不多將近30個應用要跑。有些應用可能就一張表，服務可能就三四個接口。】
我們之前一直用基於SpringCloud的微服務架構，對於dubbo沒有太多瞭解。在剛進入項目組的時候，產品負責人開了一個會，給我們大概講了一下項目是幹什麼的，目前這個產品做成什麼樣子了，後續預計想要什麼功能。 之後，直接安排我們四個人做租戶管理和工單管理。然後就沒有然後了。
我當時第一感覺就是團隊的管理肯定是混亂的，沒有任何的開發規範說明，沒有任何的開發環境說明，也沒有任何的培訓，直接讓開始工作，而且每天每半個小時問一次進度。 大家都是一頭霧水。我後來直接找開發負責人，問他開發相關的環境，工程在哪裏，有什麼開發規範要求，數據模型是統一設計，還是每個人自己設計等等。 得到的答覆是他也不太清楚，讓我問某個開發人員。 第一週磕磕絆絆的通過問東問西，把整個開發環境摸熟悉，可以把項目跑起來。這個過程雖然很糟心，很討厭，但是也無所謂，通過問別人、自己查總是能解決。但是後面的事情，就讓我覺得非常不可思議。 首先是架構的設計，產品是採用saas模式進行開發的，把各個相對獨立的子功能都設計成一個獨立的微服務，團隊內部可能每個人會負責一個微服務。每個微服務有自己的數據庫。這就意味着，數據庫不是統一的。在開發的時候，基本上誰負責那一塊，自己就去做表結構的設計，也不管是否和其他有什麼關聯。 這其實是有很大的問題的，比如說：雖然表分庫了，但是還是有關聯的，熱線中心在處理話單、客戶信息的時候，一定是會和客服中心有關聯，但是熱線中心的相關表字段，可能完全和客服中心不同。例如：客戶中心設計客戶id是uuid。但是熱線中心客戶id使用的是bigint。這就亂套了。 除了這些在整體設計上的問題之外，還有諸如分佈式事務、網關異常等等各種問題，我們提出來之後，開發負責人說他不懂，讓不用管這些，我當時就震驚了。因爲涉及到多個微服務，所以不可避免的存在服務之間的調用，在進行服務間調用聯調的時候，往往是最耗時的時候。因爲我們最初做的租戶管理相對獨立，所以前期主要是看他們在聯調對接，我發現這其中問題非常大，開發的時候，每個人都很快的說我的服務開發好了，沒問題了，但是聯調的時候，總是有各種問題，這個變量對不上，那個入參對不上，這個出參不是想要的。 因爲某一塊功能聯調不成功，其他所有人都要等着，不能走，在統一測的，往往都是一兩個人在反覆的發版和聯調，其他人乾等，等到晚上12點左右，實在不行了，就下班回去第二天繼續。 我對於這種工作方式實在是非常不能認同，出現這種問題的最主要原因還在於團隊管理和規範的問題，服務的設計和對接，應該有相對嚴格和標準的文檔，他們提到有文檔，但是文檔都是流於形式，往往先寫文檔，但是在後續開發過程中的調整沒有對文檔進行更新，最終聯調的時候，聯調雙方對接相差十萬八千里。
對於開發的細節問題，我們可以按照自己之前的規範儘量避免，但是最讓人無法忍耐的還在於需求以及功能設計。 團隊名義上是有一個專業的產品負責人，其實他也是整個團隊的負責人，在進行任務下發的時候，他往往就是簡單的一兩句話，剩下的就沒有了，你繼續去追問，他的很多想法感覺都是沒有進行深入的思考。我對這種方式非常的不認可，如果因爲身兼多職，沒有時間做原型設計，那功能的設計至少要說清楚，能有一個合理的閉環，而不是隨口的一句話，然後在開發出來之後，又說這不是我當初想要的，讓重新返工。 如果功能需求都是模糊的，那在開發的時候，開發方案一定是會被返工，明明可以通過前期稍微花些時間把需求理清楚，功能說清楚再開發，非要開發直接模糊的先開發然後再不斷返工調整。 他們稱這種工作模式爲敏捷開發，快速迭代。但是我對此不認可，敏捷開發、快速迭代不是這樣玩的，我們以前做諮詢大廳、做在線接入產品化的時候，也都是快速開發，不斷的版本迭代，但是那是建立在版本不斷完善不斷補充的節奏，而不是不斷推翻不斷返工的模式。
即便是敏捷開發，對於一些小的迭代，也是儘量要把範圍內的需求梳理清楚，在大方向正確的前提下，設計的要儘量通用，爲後續的開發做準備。敏捷開發相比瀑布流的開發不是更簡單，其實是更難，對團隊的要求更高，因爲敏捷開發要求在每一步的設計更細更具有前瞻性的思考。
功能上出了問題之後，沒有人知道是什麼問題，都覺得和自己沒關係，是不是別人的服務造成的，這就造成在問題排查上增加困難，測試在測試的過程中，遇到bug不知道應該找誰，有新功能添加的時候，往往就是一句話，剩下的設計一概沒有了，全靠自己發揮和猜想，這些管理上的問題至今都是這樣。
我認爲不管是開發一個系統還是做系統的某一個功能，應該謹遵的步驟如下：
（1）在有限的範圍內儘可能明確需求
（2）在已知明確的需求前提下，設計產品原型圖
（3）根據產品原型圖，設計數據模型
（4）根據數據模型結合產品原型圖，進行接口設計
（5）接口文檔的撰寫
（6）開發、聯調測試
在安排每個人的工作的時候，至少要保證每個人能清楚的知道自己要做什麼，涉及哪些頁面，對應哪些數據模型，要寫幾個接口，接口的出入參是什麼。
後臺接口開發方在同前端進行聯調對接的時候，完全以接口文檔約束爲準，一定要摒棄口頭商量，在接口出入參發生變更的時候，一定要第一時間修改和完善接口文檔，並通知相關對接的人。
我們之前的做事方式基本上是嚴格按照上面的方式來的，有需求或者項目的時候，我會進行需求的梳理和轉化，將抽象需求轉換設計成相關的產品原型，並同客戶進行溝通確認。然後設計表模型，安排開發。團隊內部的每個人在接到任務的時候，是非常的清楚自己要做什麼，涉及那些表，界面是什麼樣，交互是什麼樣的。而不是像現在開發人員接到的任務就是原始的需求，就是一兩句話，全靠開發人員自己去設計。其實也不是說開發不能設計，但問題是涉及到多個微服務，涉及關聯的東西，沒有一個全局統一的設計，沒有一個統一個管理，那產品是要出問題的，不光是產品質量問題，更重要還在於功能對接、細節交互上。
我認爲這裏面有一個至關重要的點，那就是需要有一個人，他對系統所有功能、設計、技術細節都能把握到位，在進行表結構設計或者功能設計的時候，能夠進行關聯考慮，確保設計的功能是有意義有關聯的。承擔這個角色的人可能完全不用寫代碼，但是基本會清楚每個接口的大致邏輯。在出現問題的時候，可以迅速定位到問題在哪塊，在出現功能設計分歧的時候，可以拍板給出明確的調整建議。 我認爲這纔是一個產品負責人或者項目負責人所應具備的最重要的能力。
這裏要區分下互聯網公司的產品經理，我始終認爲，脫離技術基礎的產品經理是有缺陷的，這也是爲什麼總是會有各種新聞說研發和產品互相折磨。據我瞭解的有些大廠的產品經理可能不關心技術細節，所有的功能設計、產品設計都從用戶角度出發進行設計，所以功能設計發生變化的時候，可能對於產品來說，就是一個小調整，但是對於開發來說，可能是非常大的調整，這就造成一些不必要的麻煩。 這樣的產品經理，我認爲中小企業或者小團隊是很難效仿的。
更多的時候，我認爲站在用戶的角度，以普通人使用的視角去思考問題，用最簡單的交互實現客戶的訴求，然後給出哪怕簡單手劃的原型圖。這是在開發之前必不可少的一步，可以把表結構的設計和具體的接口設計、邏輯設計給到開發人員，但是產品或者需求負責人至少要把需求能表達闡述清楚。
另外，在團隊的管理方面，我更偏向相信我的隊友都是積極主動的，以前負責的項目，基本上在進行任務劃分之後，大家都會積極主動的去做事情，分配任務的時候，因爲需求以及功能我能設計的足夠細，所以每個人基本上能比較準確的估算出開發時間，在deadline之前，大家都能按時完成任務，不用每天幾次的問進度。 因爲我自己心裏非常清楚每個人應該做成什麼樣子，是什麼進度，我也相信大家。但是在北京這邊，負責人不深入瞭解功能和需求，無法沉下去，在上層壓力之下，他每天都會逼問進度，這種不斷強壓的工作方式，讓我們也非常的不舒服。說到這裏，我也覺得北京那邊具體開發的同事，還是很厲害的，至少他們更有韌性，因爲很多時候，出的問題不在於他們，而在於管理以及工作安排不善造成的，但是鍋都是他們背，即便如此，他們還是會忍受着去工作。我對於他們不講究做事方式的行爲不認可，但是對於他們的工作態度和韌性表示尊敬。
斷斷續續說了這麼多，也先這樣記錄吧，也許每個人的位置不同，所承受的壓力和所負責的事情不同，所以看待問題和解決問題的思路也不同，我不知道自己對還是不對，我也不能妄加評論說他們一定不對，但是項目進度和每個人高壓的工作節奏不會騙人，這中間一種有哪裏出了問題。 我按照自己的方式接下了我們所有人的任務並分解再開發，我把我團隊裏的成員儘量“保護”住我也不知道是好還是壞，這些就交給時間來驗證吧。