最近看了舜平學長在 Facebook 的文章，讓我想要分享一些有關溝通和對話的觀念。 學長提到他和同事在工作上觀念的不同而引起爭執；他希望同事能夠思考流程如何改善，讓工作更有效率與品質。但同事則認為本來工作就是這樣做的，她並沒辦法改變什麼。結果兩人因為觀念不同而發生了言語衝突。文章的最後學長提到： 工作中充滿無奈與挑戰，或許是我的口才不好，下次要來學學勁哥跟畢姐，才能說服同事，多思考一起改善流程。不要整天都在救火，不僅沒效率、又沒效益，老闆也認為你在瞎忙。 看了學長的文章和後面的討論，同人覺得學長與同事的糾紛，真正的問題應該不在工作上的爭執，而是彼此語言差異產生的溝通障礙。雖然表面上雙方是因為在工作上的觀念不同而爭執，但存在雙方溝通的根本問題卻是因為顯著的語言差異。
海砂屋的誤解， 您三番兩次到本人的部落格，表達您對本人文章〈從海砂屋陰影學到的教訓〉的見解。這些見解和其它房屋仲介的說辭沒有差別，但這些都是本人曾經詢問過政府機構、律師、建築師之後，認為是錯誤的觀念。這讓人高度懷疑您是房屋仲介的從業人員，為了公司的利益而發表一些似是而非的觀點。果然，前一陣子有網友說他要與ＸＸ房屋仲介公司談和解，但ＸＸ房屋要求他把在我部落格的文章留言撤下，才願意和他談和解。這位網友希望我能夠幫忙，並告訴我海砂屋的誤解應該就是ＸＸ房屋的公關。 如果這位網友說得是正確的，這只會讓我愈來愈討厭ＸＸ房屋。我可以理解房仲業者有自己的利益要維護，幫網友撤下留言也是沒問題的，因為我很清楚這是和解必然的條件，我希望網友能夠圓滿解決問題，當然會幫他撤留言。只是暗地隱藏房仲業者公關的身份，為了維護自己公司的利益，一方面壓迫消費者，另一方面用似是而非的說法反駁我的文章觀點，想必這才是代表是ＸＸ房屋公司的企業文化吧。 您上一次再次對本人回應一連串的留言，本人覺得很困擾，讓我已經將您列為需要審核留言的黑名單。這兩天又再次留言執意要來這邊繼續踢館。我實在是懶得理您，寫這篇公開信的目的是希望你不要再來這邊打筆仗了（不是說不打筆仗嗎？），否則我只好公布ＸＸ房屋的真實名字，讓大家看到ＸＸ房屋是否表裡如一、還是說的比做的還好聽，到時就沒有人可以教我撤下來嘍！
上上周五有難得的機緣，在家看到「公視人生劇展」的電視節目。當天播出的《二十五張郵票 》，這是一齣有關生命教育的電視劇。同人覺得這齣電視劇很感人，使我想寫下對這部片的感觸與心得。
同人發現金蘋果與金瓶梅之間，可能存在某一種關聯性，它們都與女神維納斯有關，然後我提出我的想法。
敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但文辭有略為做過一番修飾，可以用來澄清我對測試驅動開發步驟的看法。
對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
技術經理當教練如果對公司是不好的徵兆，問題應該還是出在領導上，誠如同人過去發表過的文章所講的：強將手下無弱兵，但也不會有強將。沒有辦法訓練培養人才的教練，還是因為技術經理不諳教練之道呀！
在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。
一件商品在正常使用之下，在保固期內廠商竟然會拒負保固服務的責任。在這近幾年來，同人還是第一次意識到台灣會發生這樣的現象。不過有趣的是，有朋友認為消費者碰到這種情形不應該生氣，以免因為憤怒而喪失理智，但同人認為這樣的想法反而會助長劣質服務的氣焰。
分享會在台北市電腦公會舉行，看到現場互動氣氛的熱絡，以及會後學員們給予不少正面的評價，感覺大家收穫都不少。其實包括我自己在分享會結束之後也產生了一些想法，倒是想藉由此文章分享我的分享會後心得。
最新迴響