程式不會有錯的，都是人的錯
最近一直是6*8+6*(22:00)工作狀態，正解決程式中出現的問題時，老大來了上面的一句話，小夥伴們都驚呆了，在這樣的夜晚，安靜的辦公室，噠噠的鍵盤聲中，這麼驚悚的一句話似乎要將所有麻痺狀態下的小夥伴驚呆呀！
回到主題，先看乙個案例，該案例**於開發生活，可能有高於生活，但絕不偏離生活。
案例情節：
上面的案例講述兩個人進行一次開發工作的合作，小白是需求提供者，小可是開發者；從案例的對話中小白也不是絕對的小白，小可也不是絕對的小可。
通過這個情景，引出下面的行之有效的溝通的話題。
溝通: 在案例中，小可進行了工作內容，個人情感兩方面的反饋，並且積極主動獲取資訊，當然兩者也有不足之處，溝通的方式停留在口頭，未能落實可見的材料，個人思考未能體現出來。
工作中的溝通是基於乙個目的來進行的，溝通的參與者將是同事，合作夥伴，客戶，服務提供者等，因而上圖中的溝通要素則是進行溝通的必要前提。
回到一開頭的那就話，人的錯，錯在什麼地方，錯在沒有溝通對，沒有通過溝通確定事實的真相，工作的本來問題。
下面列舉乙個圍繞溝通的注意的因素圖：
參與：溝通的干係人（主體）；
聆聽：沒有聆聽的溝通是沒法通的，只會讓溝更深；
表達：清晰，準確的表達可以有效的傳遞資訊
自控：自我情緒，思考，想法的控制，自控是溝通產生阻礙的時能夠繼續進行的基礎；
物件：如果非要引用：「見人說人話，見鬼說鬼話
我想表達的意思是用這樣的方式來對待不同的溝通物件，而不是溝通內容。
場景：不同場合，環境需要不同的語言方式
反饋：溝通參與者應該反饋自己不明白，有異議，情感變化等資訊，積極反饋是為了更加接近溝通要解決問題的本質。
溝通好了，人的錯解決了，程式的錯又有什麼糾結的呢？溝通，行之有效的方式是嚴格要求自身做乙個有準備的溝通者，時刻行動。
關於溝通問題的乙個案例
我們需要測試乙個安裝包，安裝包中包含了資料庫公升級指令碼，這是測試的乙個重點。我們以前能訪問客戶的一台伺服器，並且在5.2號對資料庫進行了備份，但是在5.3號手動對資料庫進行了一點修改，這些修改是不包含的備份中的。而我們現在不能遠端桌面連線到客戶的伺服器了，這樣我們就沒有乙個真實的資料庫來測試公升級...
乙個案例引發的思考
今天下午，團隊開了乙個簡短的版本總結會。會上測試經理分析了乙個案例 某子程式在轉測試後發現不能被平台排程，原因是子程式的排程入口跟不符合平台規範。很明顯開發在轉測試前沒有充分自驗證，測試經理提出，後續對跟平台對接的子程式轉測試必須要有將子程式接入平台跑通後的驗證報告和相關checklist，否則不予...
乙個案例的簡單總結
翻看去年處理的乙個案例，發現處理時間挺長的，而且這個案例也有點意思，就再看多兩眼，做個簡單總結。1.首先是應用伺服器效能不穩定，排查之後，伺服器是vm，要求加資源，並且所有資源都reserved.2.接著就是應用伺服器連線資料庫時很不穩定，資料庫經常報 recovery mode 好像是資料庫莫名被...