Posted on 2006-12-31 15:22
Zou Ang 閱讀(1472)
評論(3) 編輯 收藏 所屬分類:
經常開各種各樣的會議,要達成共識很不容易，尤其技術會議更是容易吵架。舊年最后一天，寫點關于“開會”的想法。
首先，要注意聽別人發言。盡量不要打斷別人的發言，抓住對方的主要思想和依據。不要帶著偏見聽，有時候可能覺得對方不如你，但是不代表他現在說的就不對。把口頭禪從“不，……”改成“對，……”，即使有時候你不同意他的觀點，但是先肯定一下，可以緩和很多氣氛。
然后，盡量先把自己的理論基礎表達清楚，有時候爭了半天，發現兩個人想法是一樣的，不過是換了種表達方式……
最后，不要長篇大論，給別人一個插口的機會。有些人講話，喜歡停頓一下，然后在別人馬上要開口講話的時候接著講。我很反感這種人，耍猴呢啊？給別人一個提出意見和疑問的機會。盡量把自己放到討論的主導地位上來，就是說，要慢慢地讓大家圍繞著你的觀點提問題，然后你再來進行解答。但是千萬不要不讓別人說話，有時候給別人機會說話對自己理清思路也非常有好處。
最近看一本叫《人件集－人性化的軟件開發》的書，里面第一篇文章就講如何作出決策和達成一致意見。一致意見應該做到綜合各方的優點，而不應該是各方意見的“折衷”。書里有一個稍顯極端的例子：假如你的團隊正在開發一個圖形用戶界面的項目，一部分人強烈建議直接將控制按鈕放在屏幕底部，而另一部分人建議在屏幕左側放置一個控制窗口。兩種意見中，一個是水平放置，一個是垂直放置，形成了兩個極端。那么一個最具代表意義的折衷方案就是，將控制按鈕沿著對角線放置在屏幕的中央。在很多時候，由折衷所產生的解決方案比任何一個原始方案都差勁，但是“技術性一致意見”就恰恰相反，它所產生的解決方案要比任何一個原有的方案都好。書上給的“一致意見”解決方法是給控制按鈕窗體加上選項，讓用戶來決定是水平放置還是垂直放置。
在團隊中的表現是很重要的，通過一個團隊來改變團隊中的個體，要比單獨改變一個個體容易得多。所以在團隊中發揮影響，比單獨對每一個人發揮影響要有用得多。
有人說軟件工程更像是“社會學”，而不是“工程學”，我也越來越有這種感覺了。