高效高质量的讨论

xug

内容：1 前言
回想我多年的职业生涯，充满了艰辛，有悲伤失意的时候，也有成功高兴的快乐。但是，最近的经历使我充满了挫折感，我们的项目设计工作进展很不理想，虽然设计小组经常有激烈的争吵，却没有得到有效的解决方案，因此，我失望地离开了那个项目组。
为什么最近的一次分析设计工作如此低效？为什么日子不好过？问题在哪里？我不能停止思考。
总结多年来，我作为项目经理或设计组员的经验与教训，得到了一些体会，愿意与大家交流。

2 人员配置
一个比较优化的人员配置方案是，一个项目经理加若干个小组人员，他们每一个人应该具有一定的侧重点，比如说，按知识结构来分，有的精于管理调度，有的是数据库专家，有的在OOAD上面很精通，你也可以按子系统负责人来分。除了项目经理外（项目经理最好是Mentor），小组人员的分析与设计水平最好接近。

应该注意不要把相同功能的人配置到同一个项目组，那样不但造成了资源的浪费，还会带来额外的麻烦。
不要让杀伤力强的人进入设计小组，那些杀手争强好胜、一意孤行，处处要别人顺从与附和。
如果你的某位成员与平均水平差距太大，却又赋予重任，会有效的降低分析设计效率与设计质量。我想，每一个分析与设计人员，应该具备基本的分析与设计知识，比如说结构化分析与设计、面向对象的分析与设计。

3 问题
一个设计小组总是在解决各种不同的问题。应该把问题清清楚楚地写出来，包含它的前提条件是什么，有哪些边界，需要达到什么目标，解决方案的适用范围是什么。我的最近一次的项目从来不为问题写什么，遇到复杂的问题，大家争论不休，到后来才明白问题是什么。
应该对问题有一个分类的策略，比如说，需求问题、技术问题、商业前景等，以便小组人员能快速的找到解决问题的参考模型。
如果问题关联到多个子系统，则应该将问题分解，以便后面的分析能分步骤进行。
应该对问题里面的术语有一个明确的定义。最后，应该将问题公布出去，让整个部门都知道，如果可能的话，让整个公司都知道。我所采用令人高兴的办法是将问题通过EMAIL系统发给整个部门。

4 准备
问题出来以后马上就讨论，OK？
实践证明，那只能导致低效率，你还没有想法，大家还处理真空状态，怎来头脑风暴？我最近一个项目的讨论就是这样失败，某人想到了一个问题，有了一些想法，即刻要求全体讨论，这样只会带来更多的问题。
因此，设计小组的人员应该阅读问题公告，理解问题本质。如果你不能明白问题公告的内容，应该将这一情况反馈给问题的提出者或文档编写人员，找出原因，更新文档资料。应该明白，这些资料有可能是给全体人员看的，如果你不能使别人明白那个问题的话，你就不要浪费别人的时间。
问题清楚了，是否开始构想解决方案？
千万别忙！设计小组的人员应该仔细考虑是否应该解决这个问题，是否值得解决该问题，如果存在回避该问题的办法，应该与问题提出者交流。
有的时候，我发现描述的问题不是元问题，它是另外一个问题的延伸，如果是这样，就应该毫不犹豫地重新定位问题。
有了一个确实应该在此时解决的问题以后，就应该着手解决它了。怎么开始呢？
对于简单的问题，你可以根据搜寻以往的经验、分析与设计模式，然后直接提出解决方案。
对于复杂的问题、新的问题或具有战略意义的问题，你应该查询一些帮助你思维的资料，应该记住一句话：“不要去重新发明车轮”，你应该坚信，你的问题肯定有别人已给出高明的解决方案。但是，应该注意的是，你不要陷入资料的海洋而不能自拔，其二是，查询出来的资料需要进行思考，不能照搬（教条主义），你需要各方面的意见，然后给出一个比较客观的评价。
有时你应该去查一下同行业的解决方案，比如白皮书一类的东西。有时你应该多请教别人，听听他们的看法。
有了这些启发，你思考它们的异同点，你应该能提出多种自己的解决方案，试探性地改变它们的每一个方向，这些问题与解决方案在你的脑袋里面飞速变换，或许，它们与某个日常现象相似，好像人工智能里面提到个这个问题，你不断的将该问题及解决方案向深度及广度上面演进，深度锻炼了你的逻辑推理能力，广度锻炼了你的联想能力，增加了你的灵感度。先提出自己的解决方案，然后在反证它的正确与错误也是经常采用的办法。
你的目标是解决问题，需要注意问题的方方面面你都考虑到了，至少，你的解决方案在你看来是完备的（实际情况是，总有遗漏的地方）。
在这个阶段，最有价值的东西是创造性的思维导致的创新成果，因此，你在思维的时候，要勇于打破常规。
你需要把你的初步方案写出来，也许有几个解决办法，不要紧，不需要华丽语言、优美的格式，你的目的仍然是要让别人能看懂，如果你的方案引用了别人的知识，一定要注明该知识的出处及要点，否则，你应该有把握在以后的讨论会上用简短的方式向大家推销该知识，不要以为别人不懂该知识就轻视他们，现在的知识实在太多了。
然后，如果你不想在最后讨论时遭受否定的话，就把这些资料发送给整个部门，同时你可以查看别人的方案，接收别人对你的反馈，你也可以评价别人的方案，这样来进一步完善你的思路。
可能有人认为，我的解决方案是我的秘密武器，我不会给别人知道，Peter F. Durcker说：“我们无法承受这类傲慢自大。知识是力量。。。力量来自于传递信息使它成为有效的东西，而不是来自于隐藏它”。如果存在这样的人，那他一定是一个傲慢自大的人又极端自卑的人。
至于准备阶段的时间长短，应根据问题的难度、项目时间等因素灵活安排。一般是一到两天准备即可。

5 讨论
好了，终于到了讨论的时候了。有的人想，终于可以一较高下了，错！如果有这样的想法的人，就不要进讨论室的大门，我们需要有正确的心态。
应该意识到，讨论问题的人，是如你这样的人，聪明能干，充满知识，如果你是权威，你有优越感，你应该将它们扔在门外。
应该清楚的意识到，通过大家的集思广益，一定能得到一个美妙的答案，并且，大家一致同意，那个美妙的答案是大家的，而不是某人的。
所以，敞开心怀，在听别的陈述的时候，忘记自己的方案，在意识到自己的方案存在问题时，要勇于抛弃它。
一个人的本性是：不喜欢别人否定自己的成果。因此，需要承认差异，并尊重差异，要做到在讨论中尽量的陈述事实，不要说这个不行，那个不行。
让我们开始讨论把。
第一位成员开始介绍方案，让我们仔细倾听他的介绍，不要打断他，把问题记录下来。等到他介绍完毕，项目组开始对这个方案提出问题，而介绍方案的人开始他的答辩。
如果你的方案受到大多数成员的否定，不必难过，比尔.克林顿也要犯错误，这也是人性，你应该感到高兴：“感谢上帝，他们帮我纠正了不切实际的想法，我得到了提高”。
如果你的方案受到修剪，应该感到高兴：“感谢上帝，他们帮我完善了方案，我得到了提高”。
经过第一轮讨论，我们有了成果，把它从第一位成员的方案里面抽取出来，放入我们的成果箱里面。
第二位成员开始介绍方案，要注意，如果我们的成果箱已经有了你的建议，你应该简单说明，你应该把重点放在差异上面。
好的，通过同样的方法，我们把第二位成员的方案分析了一遍，或许，我们对以前的成果有了新的看法，让我们修正它，或许，两者是根本不同的想法，不能互相包容，不要紧，我们可以有两个候选方案。
第三位成员开始介绍方案。。。
一旦我们所有的成员介绍完毕，我们可以开始第二轮讨论，我们的目标是整合第一轮讨论的成果，分析差异，评定风险及优缺点，或许，受到启发，还能提出新的思路。
应该意识到，所有的分析与设计都是各种因素的折衷，局部的优化不是我们的目标，我们需要全局的优化。毕竟，需求是多方面的， FURPS。因此，采用正确的原则，总是能得到一个恰当的解决方案（及备选方案）。
或许，在方案里面有一些不确定因素，不要紧，此时我们不需要非常详细的论证，我们总是不可避免一定的冒险，我们可以把这些因素列入风险表，可以开发原型，以后进一步调整方案。
我们还认识到，人的认知需要一定的时间过程，所以，要避免一开始就发誓设计一个十全十美的系统，我们总是采用迭代计划。在实际的工作当中，我遇到多个因为发誓十全十美而工作没有成果的例子。
时间到了，会议主持人应警觉讨论开始变得没有进一步的成果输出，此时，应该总结陈成果，宣布散会了，会后要保证有秘书整理成果。

6 把问题放一下
或许我们讨论的是一个复杂的问题，一早上的讨论没有结果，建议下午不要继续讨论，给成员一定的缓冲时间，让他们消化各种思想，或许有的人还需要查一下资料、做点原型。
多次的实践证明，第二天的讨论能得到满意的效果。

7 妥协
如果你是项目经理，认定某方案有问题，但你的某位负责这个方案的成员非要坚持这个方案，你该把你的主张变为备选方案或保留方案，看远一点，千万不要说：“这个问题就按我说的来办，出了问题我负责”，要知道，在这种情况下，权利不能解决的问题，只会带来问题。
如果你Mentor，你发现自己说话太多，应该改变一下工作方式，多一点去引导你的同事，让它们说出答案，也就是说，有时候你要装傻，试想，如果不是这样，那整个讨论会岂不成了你的表演。

8 明天会怎样？
新的时代，各种知识越来越多、越分越细，顺应潮流，人们的思想观念发生了巨大的变化，Peter F. Durcker说：“当讨论用词问题时，我对使用经理这个词感到很不舒服，因为该词包含下属的意思。我现在更多地使用主管，因为它意指在某一领域中的责任，但并不一定支配人”。
写到这里，已是明日东升，我渴望找到一个精明的工作方法，不论在哪里，希望以后的工作，能愉快地讨论，高效率地产出，没有强权，没有政治。
我知道，我的思维存在局限性，可能还不全面，或有错误观点，大家都是我的导师，因此，希望大家热列反馈。