如果你說，你的團隊比別人好，那理由是什麼？因爲每個人有突出的專業能力？因爲你們懂得很棒的流程？還是其他的原因？
你有沒有遇過以下的問題？
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.根據一些以前沒考慮到的場景，提煉改進關鍵詞。
轉載自：http://www.sailingnet.net/sailingnet/4626
