各團隊間協同工作是常有的事，若協調的不好，那麼對產品的輸出會產生阻礙，要麼是推遲上線，要麼是攜帶bug的線上產品。最近有這樣一種業務邏輯需求，它涉及到四個團隊成員的開發，在這裡我分別用a、b、c、d四個字母來代表四個團隊，a團隊是輸出最終提供給業務需求方使用的產品，b團隊是處理資料供其它團隊使用，c團隊是提供相關的資料結構和資料來源給b團隊，d團隊是輸出產品供a團隊服務。
上面介紹完此業務場景的四個團隊的分工，現在來說說平時是如何協同開發的吧，只要各個團隊之間產生互動，各開發人員都會進行聯調開發，將鏈路打通，形成各自的閉環；這樣團隊開發完成的模組就可以已微服務的方式或者元件庫的方式供別的團隊使用，這樣a團隊就可以完成一次自測的閉環。為了提高對於協同工作方式的效率，前提是各個團隊之間根據業務需求定義好相關服務能力的介面，然後各個團隊可以同時展開開發，彼此之間互不干擾，每當完成服務介面的開發都可以找需要互動的團隊進行自測，將此段的鏈路調通，此階段可以暫時不檢驗資料的有效性。等到一條業務需求的完整鏈路開發完成後，開發人員就可以進行此鏈路的閉環測試，這個時候就需要校驗資料的有效性了。
以上是開發協調的基本流程，接下來說說測試驗收環節。測試階段是檢驗產品是否符合發布的最後乙個環節，它把控著產品的質量，找出顯性或隱性的缺陷，以便產品帶修改後可以滿足正常發布的條件。若是在上述四個團隊協作的場景中，誰擔任測試職責呢？正常來說，應該來說誰真正接觸客戶，誰就該擔任測試職責，來監管產品的質量。在該場景中應該由a團隊抽出人力來擔任測試職責，他們即對業務需求有所掌握，同時也對資料來源把控，可以根據真正的業務需求場景以最真實的輸入來檢驗產品的最終輸出結果。若對結果不滿意或者結果沒達到需求的驗收標準，那麼可以否決這個流程達標了，立刻讓開發人員修補。若模擬的輸出結果已滿足了需求驗收標準，那麼恭喜各團隊已經完成了對該流程的使命。
目前在團隊中有個不足的地方是a團隊的測試人員沒有把整個流程進入深度測驗，只是測驗了a團隊自身開發的一些功能，這樣的壞處是若產品上線（當然是b、c、d團隊已經在同乙個時刻上線了）後會含有其它團隊沒有被暴露的問題，那麼這就相當於是在產線來測驗產品質量，這種方式極不合理，也是必須要禁止的，先不說成本高，就單單說工作態度和方式，就不夠端正和流程混亂，這樣的團隊leader是及不合格的，需要負擔起產品質量問題的責任。若leader讓團隊這樣玩，那只會輸出失敗的產品，這樣的團隊離over也就不遠了。
每一步都無愧，人生才能無悔。
------20191215閃
關於創業的想法
想創業，不要總想著做出什麼驚天地的尖端產品，首先要看誰有困難需要你利用技術手段來幫助他克服，然後是利用最低端的技術去解決他們的困難從而保證你的產品質量，盡量讓人家 少付出代價 這樣搞你才有 白手起家 的可能，否則你就去找 賺 第一桶風險金，再努力撐到出產品，再撐到找著客戶，然後拼命留住回頭客再爭到新...
關於封裝的想法
從自己做自己的開發架構以來，逐漸理解封裝的含義和帶來的好處。1 三年來，自己的架構從滿足簡單的查詢列表配置，到現在複雜的列表 詳述 列印以及複雜的編輯頁面的配置，始終堅持框架的無業務性，框架就是提供業務應用的架構。2 封裝的另乙個對自己覺得最大的好處是修改和擴充套件，只需要在該修改和擴充套件的地方修...
關於封裝的想法
從自己做自己的開發架構以來，逐漸理解封裝的含義和帶來的好處。1 三年來，自己的架構從滿足簡單的查詢列表配置，到現在複雜的列表 詳述 列印以及複雜的編輯頁面的配置，始終堅持框架的無業務性，框架就是提供業務應用的架構。2 封裝的另乙個對自己覺得最大的好處是修改和擴充套件，只需要在該修改和擴充套件的地方修...