经常开各种各样的会议,要达成共识很不容易，尤其技术会议更是容易吵架。旧年最后一天，写点关于“开会”的想法。
首先，要注意听别人发言。尽量不要打断别人的发言，抓住对方的主要思想和依据。不要带着偏见听，有时候可能觉得对方不如你，但是不代表他现在说的就不对。把口头禅从“不，……”改成“对，……”，即使有时候你不同意他的观点，但是先肯定一下，可以缓和很多气氛。
然后，尽量先把自己的理论基础表达清楚，有时候争了半天，发现两个人想法是一样的，不过是换了种表达方式……
最后，不要长篇大论，给别人一个插口的机会。有些人讲话，喜欢停顿一下，然后在别人马上要开口讲话的时候接着讲。我很反感这种人，耍猴呢啊？给别人一个提出意见和疑问的机会。尽量把自己放到讨论的主导地位上来，就是说，要慢慢地让大家围绕着你的观点提问题，然后你再来进行解答。但是千万不要不让别人说话，有时候给别人机会说话对自己理清思路也非常有好处。
最近看一本叫《人件集－人性化的软件开发》的书，里面第一篇文章就讲如何作出决策和达成一致意见。一致意见应该做到综合各方的优点，而不应该是各方意见的“折衷”。书里有一个稍显极端的例子：假如你的团队正在开发一个图形用户界面的项目，一部分人强烈建议直接将控制按钮放在屏幕底部，而另一部分人建议在屏幕左侧放置一个控制窗口。两种意见中，一个是水平放置，一个是垂直放置，形成了两个极端。那么一个最具代表意义的折衷方案就是，将控制按钮沿着对角线放置在屏幕的中央。在很多时候，由折衷所产生的解决方案比任何一个原始方案都差劲，但是“技术性一致意见”就恰恰相反，它所产生的解决方案要比任何一个原有的方案都好。书上给的“一致意见”解决方法是给控制按钮窗体加上选项，让用户来决定是水平放置还是垂直放置。
在团队中的表现是很重要的，通过一个团队来改变团队中的个体，要比单独改变一个个体容易得多。所以在团队中发挥影响，比单独对每一个人发挥影响要有用得多。
有人说软件工程更像是“社会学”，而不是“工程学”，我也越来越有这种感觉了。
首先，要注意听别人发言。尽量不要打断别人的发言，抓住对方的主要思想和依据。不要带着偏见听，有时候可能觉得对方不如你，但是不代表他现在说的就不对。把口头禅从“不，……”改成“对，……”，即使有时候你不同意他的观点，但是先肯定一下，可以缓和很多气氛。
然后，尽量先把自己的理论基础表达清楚，有时候争了半天，发现两个人想法是一样的，不过是换了种表达方式……
最后，不要长篇大论，给别人一个插口的机会。有些人讲话，喜欢停顿一下，然后在别人马上要开口讲话的时候接着讲。我很反感这种人，耍猴呢啊？给别人一个提出意见和疑问的机会。尽量把自己放到讨论的主导地位上来，就是说，要慢慢地让大家围绕着你的观点提问题，然后你再来进行解答。但是千万不要不让别人说话，有时候给别人机会说话对自己理清思路也非常有好处。
最近看一本叫《人件集－人性化的软件开发》的书，里面第一篇文章就讲如何作出决策和达成一致意见。一致意见应该做到综合各方的优点，而不应该是各方意见的“折衷”。书里有一个稍显极端的例子：假如你的团队正在开发一个图形用户界面的项目，一部分人强烈建议直接将控制按钮放在屏幕底部，而另一部分人建议在屏幕左侧放置一个控制窗口。两种意见中，一个是水平放置，一个是垂直放置，形成了两个极端。那么一个最具代表意义的折衷方案就是，将控制按钮沿着对角线放置在屏幕的中央。在很多时候，由折衷所产生的解决方案比任何一个原始方案都差劲，但是“技术性一致意见”就恰恰相反，它所产生的解决方案要比任何一个原有的方案都好。书上给的“一致意见”解决方法是给控制按钮窗体加上选项，让用户来决定是水平放置还是垂直放置。
在团队中的表现是很重要的，通过一个团队来改变团队中的个体，要比单独改变一个个体容易得多。所以在团队中发挥影响，比单独对每一个人发挥影响要有用得多。
有人说软件工程更像是“社会学”，而不是“工程学”，我也越来越有这种感觉了。
扫一扫
3848
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
