通過流程和規則來管理團隊，規則只會越來越多；通過目標和價值觀來統一團隊，繁文縟節才會越來越少，最終形成團隊文化
——xx.仁波切
去看了小龍飯否的日記，心中也有所感，在朋友圈發了這段文字，然而就像奧特曼變身只有1分鐘，仁波切的狀態只能持續一小段時間，回到現實生活，苦逼的生活還在持續，寫測試報告的時候，心中痛苦的思索，哥辛辛苦苦推動了各項流程，加固了各條防線，然而問題還是好多。
現在一般專案來說，總有提測規範，測試規範，上線規範等基本規範，而對於乙個新專案來說，規範的建立往往是現實而迫切的，專案組成員背景不同，可能來自不同開發部門；人員組成各異，有開發、qa、前端等角色；大家在一起溝通交流以及做事都需要有一套流程去規範和約束，所以，流程誕生了。雖然有了流程，但是很多人員做事或者交付的產物與標準相差甚遠，於是就要制定規範，來保證流水線上每個人都能交付出合格的產品
實行了一段時間，流程跑起來了，規範執行下去了，然而總有一些情況與當初設想有出入，就像**邏輯寫的不夠完善一樣，我們看著流程和規範在執行，就像看著程式**在不斷執行一樣，還是有些成就感的：這套系統終於引導團隊正常運轉了。有一些不完美的地方，通過改進流程和規範，打一些補丁，讓它更符合專案特點。
如同**跑到了乙個沒處理的異常分支導致程式崩潰了一樣，系統總是會遇到一些處理不了的情況。比如規定了上線版本必須經過qa測試，晚上需要緊急上線的時候，原有流程和規範回答不了這個問題。那就需要再加一套緊急上線的流程在裡面。當面臨越來越多各種情況的問題的時候，就需要新增更多的流程和規範，同時要維護這麼多的流程和規範。
回頭想來，其實有很多問題是通過流程和規範解決不了的：
所以之前我也對此有所思考：
如果乙個專案需要30天，開發每多花一天進行自測，測試的工作量就能少一天的話，或者說開發少在自測上花費一天，測試就要多測試一天的話，那麼不管開發自測不自測，專案總時長是不變的，討論的焦點就是如何分配工作量，由於"公認測試不創造價值"，則開發不自測，而測試時間拉長。
實際情況是需要考慮在哪邊發現bug成本最低，通過**審查、開發對一些場景進行自測能夠花費較少的時間來提高質量以及大大減少整體測試的時間，從上帝的視角來看，專案的交付時間因此縮短，應該是有益的舉措。大家都說，有益的事情是原本不需要推動的，但是為什麼推動開發改進質量那麼困難，是因為從開發看來，自身的效率因此下降，而沒有覺察什麼益處；而測試則覺得對質量有幫助還能減少測試時間，大力推進。
未來的工作，必然需要從消極防守轉變為主動進攻，為團隊灌輸質量的意識和價值觀，挖掘和培養開發的潛力，讓大家能夠自由發揮能力去達到提公升效率和質量的目標
我對流程設計的認識 1 總論
1.總論 在旁觀者看來，業務流程設計這一概念投影到大腦皮層，大抵就是一張狀態圖，裡面刻畫著各種分工的步驟。其歷史的考究，最早應該是從經濟學的角度觀察到運用這種分工所帶來的生產力激增，然後轉而從管理學的角度來學習並使用這種技術。直到今天有了乙個時髦的名字，大抵叫做 business process。不...
微服務入門 對流程的理解
最近公司換架構使用spring cloud 微服務做新專案，本人也是第一次接觸，然後就一頭霧水紮進pm提供的例子，看了和github上的例子大同小異，問題是很多概念不熟，經過差不多乙個星期的了解，同時也和同事討論了彼此的理解，才真的將例子跑起來，為此，下面講解基本了解，希望對剛入門的同志有幫助 熟悉...
故障處理流程和規範
目前架構團隊負責公司很多核心服務，包括商品中心 訂單中心 優惠券中心 使用者中心 閘道器等等服務。作為主鏈路的關鍵核心，服務的穩定性和可靠性直接到影響到使用者口碑和體驗，同時也影響到公司的營收，所以線上服務的穩定性和可靠性是每位同學都需要重點關注的事情。當線上服務發生故障，我們希望每乙個團隊或技術同...