肆:流于形式的沟通

  今天开始读第四章了,引言部分作者便是引用了韩愈的话“足下求速化之术,不与其人,乃以访愈,是所谓借听与聋,求道与盲。”一句话便是说出了要求速化,必须切合实际的与你需要沟通的人交流,否则,一切都只是空话,用这句话来引入主题,不得不说作者的独具匠心。而流于形式之说,可能正是现在的沟通现状吧。

  一开始作者说到客户不会用C,难道就会用UML么?看到这个,不禁想笑出声来,真是太多“理所应当”似的想法,虽然不能说客户不会C就更不会UML,但是客户并不是你想象的该会什么就会什么。不然什么都会了,还要我们这些人干什么?所以说在与客户沟通请收起你的专业术语吧,说了也只能是造成更多的迷茫,增加沟通的难度而已,你应该做的是最简单的、最原始的语言的沟通,而不是拿出你的模型语言,那样只能让客户不懂你在说什么,那么他也就不知道该怎么好的回答你。当然客户会uml的话,似乎也没有需求分析师这个职业,客户直接提交模型不就结了,真是不能想着客户会UML啊。项目文档真的可以用甲骨文来写,甲骨文是象形文字,也许大多数人不知道它怎么读,但是起码都能看出它表达的是什么意思,但是要让人完全明白你所做的用例图,没有适当的说明,还真不是件轻松的事。所以说如果甲骨文可以用作建模语言,那么你就可以用甲骨文做项目文档。这可能更加让人懂。你应当知道UML图在一些客户的眼中无异于盲人的世界,如果需要做需求调研,你只能用一种这些客户可以接受的方式,比如表格,流程图,或者更深入的交谈。因为你需要做的是让沟通实现,而不是使用UML,客户签字并不是你画的对不对、精确不精确,而是你能不能理解他们的需求。说到这作者又提到了愚公,他所用的聚室而谋,就是很好的沟通方式,我也觉得,懂得沟通的项目经理才能做到更好,我很同意作者的看法。接下来便是所谓的最简沟通,最简指的是保证每一次的沟通都要有它的效率,只要提高效率,我相信就算只有一次沟通,那也能完美的获取客户的需求,当然这在现实中应该是不可能的事,因为现在大多的沟通都已经流于形式。很多时候我们所知道的沟通都是一种形式,比如和客户吃饭或者打回访电话。其实沟通是有目的的,如果没有目的去和客户沟通,那无疑是在浪费自己和客户的时间罢了,交流感情似乎不应该放在这里吧,然而这种交流感情的沟通已经成为一种形式,客户往往都是讨厌这种形式的。当然现实的沟通问题不仅是存在于与客户的交流之中,还存在于项目的各个角色之间,项目的分析报告为设计人员所看不懂,设计人员的方案为开发人员所看不懂,而开发的结果为测试人员所看不通,就这样简单的沟通问题,却让这所有都乱套了,那么还要怎么去实现客户的需求呢?

  在这章中让人深深感到了沟通的重要性,语言应该都是用来交流的,然而如果双方不能通用这种语言那么沟通要怎么进行下去。最后作者为我们指出,流于形式的沟通,可能是使得你的项目被不断推翻和延迟的最直接原因。沟通突然变得是如此的重要。

时间: 2024-08-25 23:18:50

肆:流于形式的沟通的相关文章

大道至简--流于形式的沟通

读后感已经写到了第四章,前期关于编程精义,方法,团队管理方面已经做了相关的总结,接下来就到了与客户的沟通了. 很明显,要想了解客户需要什么,首先要和客户进行沟通.作为程序的开发人员,我们可能会希望客户可以能学习或精通c语言,这样客户就可以以c语言的形式告诉开发者他们究竟需要的是什么.但是与客户交流,开发人员面对的是人,而不是计算机,不能简简单单的用c语言来描述,因为他们面对的是人,而不是计算机. 这时,便需要一个可以用汉语,或其他的非c 的语言来与客户进行交流沟通的人.当然如果你想要开发人员尽早

感想之流于形式的沟通

交流沟通使开发人员明白了用户的需求,有了要实现的目的项目.项目的进行中也少不了与客户的交流沟通,项目完成后的交流沟通当然也更有利于两公司之间更好的交流合作.好的沟通成就了事业,实现了双赢的目标.然而也不免流于形式的沟通,在项目回顾中,你应该认识到流于形式的沟通,可能是使得你的项目被不断推翻和不断延迟的最直接的原因. 客户不懂得c语言程序也不知道如何对程序员来表达自己对所要求项目的详尽的要求,我们不能要求客户必须懂得计算机要求,毕竟客户是与我们交流,我们做的才会是与计算机交流,使它替我们做成一些事

读《大道至简——流于形式的沟通》有感

今天怀着热情我读了大道至简的第四章——流于形式的沟通.通过学习这一章的内容,我明白了我们程序员的交流沟通在完成一个项目的过程中必不可少,而如何进行合适有效的沟通,在这一章中我深有体会. 沟通,写起来简单,但是做起来可就没那么容易了,不管是自我沟通,还是父母之间的沟通,同学之间的沟通,师生之间的沟通,还有与客户之间的沟通……太多太多了,所以沟通对于我们来说是多么的重要,这关系到我们的前途和未来,所以,我们必须要讲沟通做好,要善于交流. 对于我们搞程序的人或者研究人员来说,因为客户是不可能都会C语言

流于形式的沟通

作为学习软件编程的软件工程专业的我们,实际上不止和计算机打交道,更多的我们需要的是提供客户所需要的服务.而如何和客户进行有效的沟通交流就显得尤为重要,在开发一个软件之前,我们总是先要和客户进行接触,如果不这样我们无法确知要做什么.然而与客户最直接的接触当然是他们懂得我们所使用的编程语言,但这可能吗?显然不现实.只能是我们为客户考虑,而不是让客户去迎合我们.如果一直天方夜谭般的想着客户去改变,那么可以说你离被开也就不远了.所以如何更好的与客户的交流与沟通在我们这个行业来说真的是值得深思熟虑的地方.

大道至简第四章流于形式的沟通——读后感

沟通是为了更好的了解对方,有句话说只需一个眼神,一个动作,对方就会了解自己,这是知己.但是我们在沟通的过程中,我们可能会想当然地认为别人会了解我们,因为我们都有这种意识——我们都会认为别人会按照我们自己的想法去理解我们的意思,这是一个大缺陷,我们对自己太自信了,也可以说是自私.可是别人不是这样想的呀.我们都有自己的见解,这其中一定会有隔阂,或大或小:我们因为一件事的完成,而聚到一起,为了实现它,所以必须要好好的交流. 在每次的交流过程中,沟通是有目的性的,我们都是为了某个目的而去沟通,必须要清楚

技能——沟通

沟通是思想的交流,是将灵感转化为实体的媒介.客户通过与顾客的沟通确定他们的喜好与习惯,做出适合打不分人喜欢的东西,而我们通过与客户的交流,明白客户的需求,理解他们的意思,才能最大程度的利用我们的优势,将灵感与创意转化为理想中的产品. 正所谓隔行如隔山,并不是所有的客户都有我们一样的编程基础,不会用c的大有人在,我们不能期待他们能够运用计算机知识给我们讲明白,当然如果他们懂得话,哪里还有我们的用武之地!从一个角度来说,我们是他们的服务者,既然是服务者,那么我们就要明白他们的意思,也就是说要将自己的

大道至简

思考任何问题,首先都要想到本质,而本质一般都是简要却最易被忽略的 在平时的编程过程中,我渐渐发现,学习编程是有窍门的,我概括为以下几点:构建图像,再在图像中添加各种逻辑关系 图像正是将所学的知识结构化,明晰化 1.巧妙地利用"愚公移山"这个众所周知的例子,将其与编程类比,让我们更通俗地领会编程的精义 2.在书中的说法是懒人造就了方法,这话没错,因为懒得弄个百万行代码的文件,我们创建了面对对象,但从另一个方面来说,这些懒人无疑是聪明的,他们通过分类整理,将杂乱的程序变得简单 鹤立鸡群的高

大道至简读后感

首先我十分钦佩周爱民先生出这本书的初衷:不为利益,只想把他在软件开发一线浸淫近十年回头思考开发的本源的心得体会分享给大家,迫于现状最后出了电子版.在当今这个物欲横流的社会实在一股清流. 当读到懒人造就了方法时我发现其实做工程可以劳逸结合,当遇到难题时可以闲游会,正如李冰凿石开山时很懒,懒到闲着看火烧石头,最终想出"积薪烧之"来破石.最后事半功倍,很轻松的完成了任务.同时这使我想起中科院院士.中国人工智能学会理事长李德毅先生.他在研发无人驾驶汽车时为了解决测量雨天过后乡村道路上水坑的深度

大道至简第四章

猜对啦,有是我,我又要来扯淡了.并不想写这篇文章,因为我从小文采不好,不擅长与人沟通.更不想写什么观后感,我个人认为观看一本输是要记在心里的并不应当成任务来看待,读书是自愿的,强迫是没有好东西的.下面进入正文... “足下求速化之术,不于其人,乃以访愈,是所谓借听于聋,求道于盲.” ——唐·韩愈<答陈生书> 又是一句古文,仍旧不是很明白其意思,算了懂那么多又有什么用呢. 1. 客户不会用 C,难道就会用 UML 吗? 这一小节讲述了,项目经理的功用,即是在程序员和客户之间沟通的桥梁.用户只知道