冰云@Blogging

请赞同，而不说“不是” － 关于交流和反馈

关于交流

1. 永远不要以否定词开始你的对话

最近经常听到人说话时候把“不是”这个词放在句首，例如有人说：“我觉得这个设计是符合可用性原则的，你看这用户按钮这么大，多好点击啊！”有人说“不是，按钮大不代表可用性就好啊。。。”我认为这是一种很不好的习惯。他在不经意间，把自己的立场摆在了和讲话的人的对立面。甚至他们观点实际上相同的时候仍然不自觉的用“不是”开头。对方听到“不是”，虽然表面没说，但心中早已掀起滔天巨浪…… 这样说话要花很多功夫才能达成一致。（貌似很多老北京都这么说话，很奇怪。）

作为一个咨询师，当尝试解决用户的问题的时候，或尝试推销解决办法的时候，切忌用否定的句子开始阐述。当一个咨询师说“不是”的时候，无论你后面的论证多么的严谨和完美，客户都已经提前丧失了兴趣。有的时候，赞扬谈判对手能够更快的达成一致。

这时候一定要换一种说法：“你说的很有道理，我帮你改善一点……”，“你说的对，如果……能够再……一点……用户体验就更好了”。

2. 交流的唯一目的是达成共识

交流发生于双方发生分歧的时刻。例如你对工资不满意了要和老板交流，再比如需求搞不清楚了要和客户交流，在家里有矛盾了得和老婆交流等等。总之交流这个事件的产生动机总是因为有些东西搞不清楚，而交流的目的就是把这个东西搞清楚，大家对问题达成一致的理解。

然而，很多时候交流的双方忽视了交流的目的，陷入了盲目的交流漩涡。尤其是看到两个人在pair programming的时候，为了一个设计争得面红耳赤不可开交，这时候他们只是为了说服对方、或者证明自己的权威而交流，目的改变了。

3. 交流的基础是尊重

顺畅的交流是建立在互相尊重的基础上。当你和一个人说话的时候，如果他眼睛望向一边，心不在焉，根本不仔细听，敷衍的和你说，这时候说话的人是什么感觉？如果对方用傲慢的语气粗鲁的对你说，“你这个观点很愚蠢”，“我的一个朋友才是我见过最牛的（言下之意就是你不够牛）”，这时候说的人还有没有动力继续说下去？

交流的时候一定要怀着一颗平等的心。。。无论和你交流的人经验深浅，无论地位高低，无论贵贱。

4. 交流是双向的。要用心听，认真反馈

一个很好的实践叫做“Active Listening”，或者叫“主动倾听”。 所谓Active Listening，通俗的说就是指听别人交流的时候，要经常嗯嗯啊啊的赞同，并且不停的问“后来呢？”这个讲故事的人最爱听的短句，以及经常的总结一下对方的观点。这样的主动交流比较能够促进说话的人的积极性，使得话题能够不断的进行。

更重要的，是要对说话的一方提出反馈。工业上说反馈是质量的关键，只有建立了良好的反馈渠道，产品的质量才能达到客户的要求。当然，要区分的是，有时候别人说了一件事情，并不是真的想要听者提供反馈，只是抱怨和发泄一下需要听众而已。

关于反馈和提建议

1. 当你要反对的时候，请同时给出你的建议

在一个风和日丽的中午，你问旁边的同事：咱们中午一起去吃7-11好不好？他回答说：又是7-11啊，不去。或者，你好不容易写了一段感觉良好的代码，给你的同事看，他说：写的不好。（下面没有了）。总有一些人习惯于否定对方的意见建议，又不能给出自己的办法。这样人非常多。

当提出反对的时候，一定要同时给出建议。例如我们做开发过程的回顾会议（Retrospective）的时候，如果光说出不好的地方在哪里而又没有改进建议，那几乎和没说差不多。

2. 提意见建议之前，先赞扬好的一面

意见建议这个词，老外经常会用Feedback。这Feedback是个好词。辞典里说：“If you get feedback on your work or progress, someone tells you how well or badly you are doing, and how you could improve. If you get good feedback you have worked or performed well.”

说起Feedback的时候，隐含的含义就是要告诉你什么做的好，什么做的不好，并且告诉你如何改进。其中更重要的是要发扬好的。而反过来看我国这边，很多情况下我们叫提“意见建议”，意思就是对你做的不好的地方指点一下，在给你提出点改进建议。我国古代曾经有活动叫“批评与自我批评”，更多的是看到了坏的一面，而忽视了对好的一面的坚持和发扬。

有人发明了“建设性意见”这个奇怪的词，难道对应的应该叫“破坏性”意见？貌似从来就没有一个中性的词来指给别人的Feedback。可能是自古以来朝堂上就只有抨击诘责没有正面的Feedback吧，就算有也被归于了阿谀奉承、溜须拍马一类。由于我们的这种传统，在很多情况下，我们给人提Feedback时，都容易倾向于对人进行批评性的评论。而这种评论，是破坏团队关系公司文化的特效药。

3 Feedback的目的是提高效率和增强信心

以前参加过培训，其中一课就专门讲到给人提供Feedback。给人提供Feedback，你只有两个目的：提高对方的效率，或者增强对方的信心。前者，就是针对某些不好的地方提供改进建议，后者，就是对于对方做的好的地方表示支持和鼓励，希望他再接再厉。因此，所有的Feedback，应该都能够达到这两个目标。这两个作用之外的任何其他作用，都不是合适的Feedback。

我们公司内部Feedback的种类有很多，有非正式的Feedback，离开项目的Feedback，半年期的Performance Feedback，面试之后有Feedback等等，但做法都大同小异。首先，想要给人提Feedback，你要先获得对方的允许。反之，你如果想得到别人的Feedback，你要向对方正式提出邀请。

4 提Feedback要针对行为，要具体

人的行为其实都有动机。动机(Motivation)决定了态度(Attitude)，态度决定了行为(Behavior)。例如一个人的动机是想赚大钱，他的态度就会很积极上进寻找机会，他的行为就会表现为愿意参加各种创业俱乐部之类的。

提Feedback的时候，只能针对行为来提，或者说，就事论事，而绝对是不可以针对人的动机或态度提。例如说，提Feedback说这个人太自私，平时总不积极参加活动什么的。这是错误的提法。可以改为：某某最近不经常参加某活动，如果他以后能够参加这个活动，那么他能够在活动中获得什么什么知识等等。如果针对人的动机提Feedback，一来提Feedback的人会先入为主出现偏颇，二来听Feedback的人会听不下去。

另一个提Feedback的时候的常见情况是太空泛。常见的是在提Positive Feedback的时候，有人说：某某非常nice，某某非常容易相处。好话人人爱听，并且这好话都是针对态度的话。然而，这些话纯粹是拍马屁没有实际用途。 要用事实说话，举实例。要说某某做了什么让你觉得nice，某某做了什么证明了他容易相处。这些具体的实例对于接受Feedback的人会起到促进的作用。

另外要避免使用我认为，我估计，我猜，可能之类的词。因为这些词不客观。想对一个人进行了解，只能根据客观事实来判断，而不是可以根据别人的判断而判断。

5 给组织提Feedback就是Retrospective

当我们把上述的实践用于组织和过程，就是敏捷方法中常见的Retrospective了。Retrospective的目的是增强团队的效率和提高团队的信心，一个有效的Retrospective也需要：先提出团队过程中好的一面；当提出不好的时候一定要有具体的改进建议；提出的好坏方面都必须具体，对事不对人。

当我们每个团队的个体成员都学会了如何交流，如何提Feedback的时候，那么团队的自组织和自完善也就很好办了。团队建立起完全平等和安全的交流环境，成员们就会逐渐的去进行交流和反馈。

Tags: Agile 敏捷, communication, consulting, feedback

Posted in Agile 敏捷, ThoughtBlogs | 3 Comments »

演讲技巧（下）

查看：演讲技巧（上）

PPT的制作

多数情况下一个好的PPT能够给听众带来愉悦的心情和清晰的思路 。在做PPT的时候，我第一件要考虑的事情是模板的选择。有人说内容第一，最后在做样式。其实不然，如果一开始不选好，中间的配图、字体、高亮颜色等最后还得返工。

选择模板需要考虑使用的场合。一般的黑白深蓝底色都是比较安全的。有人喜欢把屏幕弄亮点让底下观众不会因为背景暗而昏昏欲睡。我最近喜欢用黑色，看起来更酷更时尚一点。如果演示稿是关于公司或者代表公司，公司Logo一定要放在上面（其实一般公司都会有统一的模板）。如果是给客户做演示，客户的Logo也不应该忘掉。

PPT多数时候需要一个Agenda来开头，让用户知道你今天的议程是什么。后面不时的可以重复展示这个Agenda来提示客户你说道了哪里。不过这点并不是必须的。有的时候一场报告只有一个主题，例如我前次做的校园招聘的宣讲，是关于Business Analyst的。我就没用Agenda而口头说明的。

Less is More

最近经常听到Less Is More这句话。当制作PPT时，大忌是把所有的文字都堆在幻灯片中，在演示时读屏幕。这样是最枯燥的。最近流行一种模板，就是多数页只有一句话，放在屏幕中间，据称叫做PPT 2.0模板。这种的模板很有看头，每页一句话，剩下的要靠嘴说。每页一张图片，后面的故事也要娓娓道来。只有演讲者说服了听众，幻灯才能达到效果。让观众读懂算什么。

幻灯片设计中的颜色也不宜太多，而且应保持一致，例如所有的图片边框都是2pt的白色，而不要每页不同。如果使用Office2007，里面会有些color scheme，大概有几种配色供使用，都还不错。

在商业演讲中，幻灯片的字体应当用普通的字体，例如Arial, Tahoma, Calibri等常用字体，这样显得朴实大方。不要用Comic等儿童的、奇幻的、趣味的字体。

要白板还是PPT？

我们有时候常有争论，就是是否要准备PPT还是只用白板就好。我们以前总结过敏捷培训宣言，里面就说白板和卡片胜过幻灯片，但这并不是绝对的。一个准备良好的PPT绝对能够发挥很大作用。

白板的弱点就是字体不好控制，后面容易看不清；无法展示图片；但白板的好处在于可以动态的和递进的讲出问题，可以在白板上留下推理过程和历史记录，并且可以根据听众的反应，随时转换话题或者引出新的内容。

而PPT在准备的时候必须要遵循一个套路，很难跳出。所以讲PPT的时候必须要考虑周全，如果听众问问题打断了讲解思路就非常麻烦了。因此很多讲PPT的人都要求客户最后提问:P

如何缓解紧张情绪？

每个人演讲都不可避免的会紧张。我第一次给公司内部讲东西就紧张的不行。后来在内部习惯了，第一次给客户讲又紧张。再后来客户面前20人不紧张了， 到上50-80人的时候又会紧张。不过解决这种紧张情绪很容易，就是多讲。讲多了，见得人和事面多了，自然不会紧张。我现在面对小场面那是相当的不紧张， 大场面不敢说啊，要让我上人民大会堂讲，估计还是得腿软。

当紧张袭来时，每个人的反映不同。我以前是可能会有点发抖，现在不发抖了，在开场2-5分钟时候有些喘不上来气，心跳的厉害，思路也不太连贯。这时候最重要的是要镇静，抓住时机吸几口气，把语速降慢，适当增加停顿，让自己缓解过来。

有的人紧张起来比较奇怪。徐昊一直跟我说，他是后紧张类型的：下场后10分钟抖个不停。。。。我说，你这是讲东西发泄后爽的吧。

如何练习演讲

演讲能力的提高主要靠练。练表达能力，练逻辑能力，练在人前说话不怯场，一定要克服自己怕说话怕在公共场合发言的心里。要锻炼演讲，可以先在公司内部搞内部交流时讲，反正都是自己人不怕丢人；然后可以到Beijing Open Party等社区活动来参加技术社区交流，面对陌生人来讲；接下来是在客户现场承受压力的讲；最后就可以考虑到几百人的大会上露脸了。

Tags: consulting, presentation

Posted in Business, Consultant 咨询, ThoughtBlogs | No Comments »

演讲技巧（上）

演讲技巧是咨询师必备的技能之一。作为一名专业人士，在观众面前能够逻辑清晰、表达到位、信服有力的将其所关注的内容表述出来，是许多人都希望做到的一点。然而很多时候，有些人对小细节不够重视，在演讲时犯错误，导致比较差的演讲效果。

如要提高演讲技巧，个人认为需要着重关注于内容、声音、手势、幻灯片等几方面。下面我会分2篇将我个人这两年的一些经验总结一下。

内容要有内在逻辑性

我看到过一些人做演讲，前后内容跳跃性极大。幻灯片之间没有过度句，头一篇和第二片之间异常生硬。关于这方面Minto的《金字塔原理》一书讲述的比较深入。一般的，逻辑可分为演绎法和归纳法等方法。

我同事马波在讲敏捷的时候，采用的多是演绎法。他从问题开始，推出解决方法，然后又从这里引出新问题，一环扣一环，最终推出来结论，让听众从根本上理解为什么采用敏捷。这种方法对于问题的分析非常清楚，但有时候把握不好容易陷入细节，无法给观众一个大局观。所以要考虑多种方法共用。

逻辑讲究的是有理有据。每个概念都应该有解释，每条论证都应该有根据。所以很多时候我们都是从What开始开头，然后说Why，接着是How。有一种情况应该大力避免，就是用一个观众不懂得词汇来解释另一个观众不懂得词汇。最终这里面的逻辑关系可能会套的很远，为了解释一个概念，不惜引经据典，博古论今，这样听众很容易迷失。不过徐昊运用的相当精熟。

声音和情绪

声音是传达内容的媒介。以前我做演讲的时候，常犯的一个错误就是声音没有起伏，像平时说话一样一串串就出来了。如果在相对封闭的会议室，又是下午，很快你就会发现下面听众开始犯困了。做演讲讲究语速和语气。在林语堂的《怎样说话与演讲》一书中专门强调过这一部分。

语速是最容易理解和掌握的。我一开始演讲语速容易加快。可能是由于紧张，就倾向于快点讲完。然而，对于介绍新知识、新理论、做新品展示等场合，切忌快速说话。这时候应当慢慢的细致的把新的东西娓娓道来。

语气比较需要经验。什么时候该强调，什么时候该重音，什么地方应该用平淡的口气带过，非常需要揣摩。这个我做的也不好。不过，多数情况下，你觉得重要的东西，自然要着重则个。

演讲者的情绪能够感染听众。我英国的同事Marc演讲的时候，情绪非常的兴奋。他那次讲的是Web 2.0主题，里面涉及到许多创新的应用。他用一种非常兴奋的语气和动作，表达了他对这个主题的激动和热情。他的演讲感染了听众，所有人都对这些新应用产生了浓厚的兴趣。

所以很重要的一点，就是你要对自己的话题有激情。如果讲了很多遍， 自己都觉得没意思了，你再讲给听众的话，就会不自觉的把这种厌烦的情绪带给听众，从而降低你演讲的影响力。

手势和姿势

我们老大郭晓曾经讲过一个故事：当年我们CEO去参加商业课程培训，回来后说学到了一件事最有用，就是演讲三步骤：1 将手指向你要讲的幻灯片内容，2 转头面向观众，3 面带笑容的讲解这一部分。然后不停反复这一过程。这就是演讲手势的精要。

虽说上面说的简单了一些，不过非常实用。很多时候，由于在投影仪上进行演讲，不如白板来的直接，用手势或激光笔等指示你讲的部分非常重要。尤其是在出现结构图、流程等略显复杂的页面的时候。

演讲的时候，应当站直尽量不要走动或晃动。我有次在一次演讲在观众面前不停的走圈，结果被同事记下取笑至今，说我走八字。演讲者应站在一个不挡住屏幕的位置，用手势配合你的讲解，除非必要不要乱动。

笑容在有的时候很重要。如果不是必须要严肃的内容和场合，不妨增加一些微笑。俗话说的好，“面上洋溢着自信而成熟的微笑”。个人认为在一些地方增加一点小包袱也很有效果。例如，场下坐着某个听众比较熟悉的人，不妨开下他的玩笑，如果是公司内部，开老板玩笑或许是一个很有趣的选择。也可以对上一场的演讲者进行一下评论等等，作为开场白或者活跃气氛的调剂相当有效。

阅读：演讲技巧（下）

Tags: consulting, presentation

Posted in Consultant 咨询, Skills, ThoughtBlogs | No Comments »

独立咨询师

独立咨询师（Independent Consultant）在国外是一个非常寻常的职业。在英国的时候，我们Team缺少CSS Developer。我在一开始兼任了一周，结果Analyst的工作忙不过来了，PM只好选择寻找一个兼职的独立咨询师。

没过多久，公司就从外面找到了一位独立咨询师。他以前也和公司合作过，口碑不错。他在team里面待了大约2周，这两周内，他整理了原来的CSS并且将界面调整到了一个相对稳定的状态。随即他便离开了。过了一段时间又来了几天进行短期调整。

在国外，许多有一技之长的开发人员都选择了做独立咨询师。虽然这样丧失了一些公司福利，但获得了更高的收入和更大的自由。而公司这边，也由于减少了长期雇员从而减低了成本。我问他，客户都从哪里来？他说朋友有机会都会介绍他，一些老客户也经常回头找他。总之还是很忙碌的。

后来，整个Team移师北京。在北京公司尝试寻找一位兼职的CSSDeveloper，才发现，在北京，这方面的独立咨询师真是少之又少。难的找到的几个能力合适的人，却并不能接受这种短期的合同。究其原因，总归是因为大环境的问题。公司既不习惯提供短期工作，客户也不能信任短期咨询的质量，继而开发人员也无法选择这样的生活。

我很早以前也在家SOHO做过一些开发网站之类的工作。收入既不高，客源也不稳定。许多中小企业倾向于雇佣一个人，将所有的事情都外包给他。而不是根据团队所欠缺的能力和人才来雇佣。受限于这种情况，独立咨询师独立生存极其困难。

国内管理咨询业做独立咨询的人更多一点，相对于IT业的情况，管理咨询需要若干年的实际管理经验才能做好，从而提高了行业的门槛。而IT业的门槛很低，同样是做网站，你用什么技术对客户来说并没有任何区别。

再后来，有了项目外包网站，发标者开出低价，投标者更是为了获得订单不惜赔本开发。这种行为最终损害的还是客户的利益。为了快速的交付，损害了质量和售后服务。同时也使得整个独立咨询的口碑大大降低。

独立咨询师对公司带来的好处是很多的。如果公司团队正好缺乏一个专项人才，同时又不需要长期的配备这样人才，独立咨询是非常合适的。然而，缺少一种渠道让公司了解咨询师，通过口碑营销在初期会非常的慢。虽然itechtag在这方面可以作为一个很好的个人展示平台，但独立咨询师还需要一个地方来声明自己工作性质才好。

估计等市场、客户、及个人能力都成熟之后，IT独立咨询师才能成为大家的一种选择吧。

Tags: consulting

Posted in Business, Consultant 咨询, ThoughtBlogs | 2 Comments »

敏捷的弱点是什么？

“敏捷的弱点是什么？”，一个刚接触敏捷的朋友如是问。

敏捷方法是一种适应性方法，换句话说，由于它本身的适应性，他可以去适应各种情况，并且可以根据实际的效果来调整自身，从而改善它的适应程度。因此，首先我们说，敏捷的弱点或者优点这样的问法是不妥的，应该问，在什么情况下敏捷适用性不好？

敏捷的产生主要是来自于开发团队，开发团队发现他们在进度、质量等方面的能力无法满足业务需求，于是提出要加强交流，增进反馈，避免各种内部浪费。于是开发团队在实践上采用测试、迭代、提高交流效果等等，最终在效率上得到了很大提升。

但是，很快的，这个团队意识到，光提高开发的质量还不行 。开发测试之外的很多东西也需要敏捷才可以，尤其是在发布一个新版本的时候，旧有的发布方法没法满足开发的速度要求。他们于是提出了敏捷的需求管理，要求和业务部门之间建立专门的业务分析来进行沟通；数据库重构技术，要以往DBA所负责的部分也能够变得敏捷，适应开发的需要；部署和发布方面也需要一套高效的方法来适应快速发布，快速反馈的需要。于是，整个IT部门变得更敏捷，从需求到发布的整个软件生命周期都得到了很大的改善。

然而，这个部门很快又遇到了问题。虽然IT部门的开发很高效，但他们和其他的业务部门之间总遇到难以解决的问题。或者是业务变化跟不上，或者是售后支持没法及时反映。于是，由CIO带领，公司开始了整个的组织转型，将一个组织敏捷/精益化，建立敏捷业务和精益企业。让IT部门的价值得到最大的提升，由新的IT系统来促进业务的发展。

不过，问题又来了。由于业务的发展，公司需要和其他的公司之间进行数据交换，共同开发通讯接口。合作公司的反应速度和开发效率极低，大大的降低了合作的效果。于是，公司派出咨询师，帮助合作公司进行过程的改进。最终达到共赢。

这一整套过程下来，敏捷/精益的思想得到了贯彻，开发效率和业务效率得到很大提升，公司获得了很大的企业价值。然而，如果这一切都无法顺利的完成呢？

在某些公司，由于各种原因，一个团队的敏捷程度完全取决和他们合作的部门或公司的敏捷程度。在一个项目中，我的一个同事所在的团队需要和数据库部门以及另一个开发部门协作，从而完成一个系统集成应用，然而，他们没有数据库的操作权限，同时另一个部门的API尚未就绪。他们很快就开发完毕自己所分配的部分功能，在等待中不断的催促和协调另外的部分。一个几周的工作，硬生生的被拖到了三个月。

综上， 敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部门、公司做事方式的时候。

不过，我认为，改变一个人虽然困难，但我们可以去影响他们。只要从基本的实践处做起，逐渐的，周边的人会被带动，从而可以推动整个部门的改变。一个部门改变了，公司领导会很快意识到这种变化，变化也有可能影响到其他部门。只要我们坚持去做。

Tags: Agile 敏捷, consulting

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 思考 | No Comments »