你有沒有遇過以下的問題？

1.您的開發人員完成了一個功能，只測試了主流程，看起來不錯。于是它被標記為完成并轉給QA測試。 QA發現了一個嚴重的bug，只需要在正常流程走到一半的時候點一下取消的按鈕。

2.您的開發人員分配到一個子任務，開發一個API，API的需求寫得很詳細。他很快完成，開始與調用者做集成測試。此時他發現，他做的，跟調用者原來的預期差別很大。

3.還是您的開發人員，他要修復一個Bug.他檢查了現有的代碼，發現這代碼很丑陋。但是要修復很容易，如果他只是希望修正這個問題，只是兩行代碼的改動。不過代碼還是很丑陋，以后要改功能還是會很復雜，除非重構。他默默選擇了簡單的修改，沒跟人討論。

4.你的QA人員在測試一個新功能，功能跟需求描述是100%符合的，但是他在使用的時候覺得有些地方不順暢。他讓這個功能測試通過。

5.我們的開發人員每次要跑起整個開發環境，都要從4個代碼庫更新代碼，在4個工程里面點構建， 然后再啟動3個應用服務器，以及啟動數據庫。他們慢慢的習慣這樣的麻煩。

6.我們有個開發人員，在上海，有個美國的同事，是QA.兩人有差不多半天的時差。上海的開發人員快下班了，他手頭的功能還剩點掃尾的工作就可以給美國的QA測試。估計還要30分鐘。開發人員決定先下班，第二天再繼續做。于是美國QA多等了一天才進行測試。但除了這個開發人員以外沒有人知道這一點。

7.你的UI開發人員做了一個漂亮的HTML原型，100％展示了設計師要的UI效果。但在原型中使用的UI庫跟現有應用程序中使用的沖突。要嘛工程師需要花費大量的時間重構現有代碼，或者UI開發人員使用不同的庫來重做他的原型。

在以上所有的例子中，有沒有人違反流程？沒有，除非我們把上面所有的情況寫進流程。如果給我時間，我還可以列出數百個流程里面沒有規定的情況。所以不可能有一個流程可以規定所有的情況。

　但他們是不是可以有不一樣的做法？

＃1，他可以選擇將問題提交給QA測試前，完成簡單的冒煙測試； 也可以選擇先像QA盡量跑一下所有的流程，盡量確保QA找不出Bug來。

＃2，他可以選擇完全只看產品經理的描述；也可以選擇在開發之前跟調用者討論一下。

＃3，他可以選擇盡快修復bug；也可以選擇將代碼的問題提出來討論，看要不要重構。

＃4，他可以選擇只聽產品經理的；也可以選擇從用戶的角度把反饋提出來。

＃5，他可以選擇忍受這種繁瑣的手工活；也可以選擇建一個腳本來自動完成。

＃6，他可以選擇常規節奏按時下班；也可以選擇多留下來半個小時，讓QA提早測試。

＃7，他可以選擇盡快實現UI效果；或者做之前跟開發人員討論一下。

如果把他們的思路不斷抽象歸納一下，就是：總是考慮下游人員的工作，像用戶一樣思考，改進一切可以改進的事情等等。這些思路，不是專業技能，不是流程，但就是這些思路，構成你的團隊文化，讓你的團隊不一樣。新團隊一般不會有一致的思維方式，大家的各有各的視角和立足點。

一個訓練有素，經驗豐富的團隊，他們碰到各種場景，一起處理過各種問題，最終他們建立了一種默契。屬于團隊自己的默契，于是他們花更少的時間就可以把問題溝通清楚；他們可以更快的達成一致的行動方案；他們可以更快的反應；他們可以用更少的嘗試找到答案。這是一支有強烈風格的團隊，而且很高效！

誰來打造文化？通常是團隊的領導者。如果領導者能夠進入項目的每一個細節，關心每一件小事。那么，團隊每個成員自然而然會去注意每一個細節，因為他們知道他們老大關注這個。如果領導者在做每一個環節的時候，都會考慮下一個環節怎么做，那么成員自然會學著多考慮一步。如果領導者總是在想著怎么提高效率，減少手工流程，時時在問這個問題。成員也會擁有這種思維。如果領導者總是站在用戶的立場考慮問題，做嘗試，成員在考慮問題的時候，就會像領導一樣，問自己，如果我是一個用戶，我會怎么樣？

　如果想打造有自我風格的團隊？試試這樣：

1.花時間回想你碰過的所有場景，把那些場景下組員應該怎么想的思路抽取出來，總結成簡短的話。

2.這幾句話就是你們團隊文化的關鍵詞。

3.告訴你的團隊這些關鍵詞。

4.往后留心跟這些關鍵詞有關的場景。

5.如果團隊成員的思路跟你想要的文化符合，鼓勵他們。

6.如果團隊成員的思路跟文化不一致，指出來，告訴他們你是怎么想的，后者自己親自做給他們看。

7.讓你的成員以同樣的方式這樣指導新來的人。

8.根據一些以前沒考慮到的場景，提煉改進關鍵詞。

來源：月光博客

作者：王偉杰