zoukankan      html  css  js  c++  java
  • 肆:流于形式的沟通

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

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

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

  • 相关阅读:
    SpringBoot Jpa 双数据源mysql + oracle + liquibase+参考源码
    C#:将字符串中连续空格作为分隔符获取多段模糊查询的字符串
    C# 传入参数2021-05-18T00:00:00.000Z使用ToDateTime日期在此基础上加8小时
    修改DbContext并不是线程安全的bug处理。
    产品经理推荐书籍
    抽象类、类和接口
    git 分支合并主干出现冲突的解决办法
    HttpClient请求设置Content-Type标头空格问题
    C# 3Des加密解密
    WPF 颜色选择器
  • 原文地址:https://www.cnblogs.com/kt97458/p/4908552.html
Copyright © 2011-2022 走看看