《大道至简》第四章有感
第四章主要讲述的是沟通,作为程序员我们能很好的与客户沟通吗,答案是否定的。开发人员总是先要接触客户,了解客户到底想要什么,来确定到底要做什么。但是客户不懂C,开发人员就不能有效的与客户沟通,就需要咨询公司借助UML来介入需求阶段,帮助了解和分析需求。因为客户不会C当然也不会UML,此时最直接的问题还是与客户如何交流?最为开发人员最重要的就是与客户交流,来了解客户的需求从而进行研发。无论是开发人员还是咨询公司,想达到的目的都是了解客户的需求,但是在这期间C和UML,客户都是不了解的。这就引出了一个很重要的问题,怎么才能做到有效的沟通。
“我们需要在正常人与盲人之间建立一种沟通的方式,既然盲人不能睁开眼睛,那么你就闭上眼睛好了。”UML 图在一些客户眼里无异于盲人的世界,如果需要向他们做需求调研,只能使用一种这些客户能够理解和接受的方式,例如表格、流程图以及⋯ ⋯ 更深入的交谈。通过甲骨文我们了解了只要约定一套“语法”并且得法就能达到良好的沟通的目的,所以你要确认你的沟通方式是否有效,而不是去追求这种方式是不是 UML,以及用 UML 表达得是否正确。与客户沟通是方式是多变的,要取决源头,是一个专家组,还是一个不懂UML的人,就要改变不同的沟通方法。
减少沟通和保障沟通质量的问题是尤为重要的,保障每一次沟通的有效性都是最重要的事。每一次沟通,都是向客户了解更深层次的需求的机会,因此在见到客户之前,设计出所有的问题和提问方式。这样就了解了客户项目中所有会产生需求的信息点。通过设计提问,每一个提问涵盖尽可能多的信息点,尽可能的具有发散性以便形成更多的推论和假设,来了解客户的需求,所以通过设计提问来保证沟通的质量。
项目的中断和中止,很多的项目在负责人员离开后,就自然而然地死掉了。一切的原因“没有 history”。我们做项目的时候,如果不留下历史记录 (History),那么以后别人来看这个项目,也会是两眼一抹黑,项目便就此中止;要么就花大量的人力物力来攻关。维护旧项目比做新项目更难,在做“新项目”的时候,要为“项目维护”这种还不存在的角色,留下一个沟道、对话的渠道。 项目的 History 作为跟这种“不存在的角色”沟通的一种方式。History 的丰富和准确为项目的后继开发、维护提供了可能。History 是为整个项目而记录的。一些参考的记录内容有:需求阶段、设计阶段、开发阶段、测试阶段。通过History留下历史记录,可以方其他人更好的阅读我们的程序。在JAVA上机课上老师说的最多的一句话就是“加注释”,加注释不仅可以为我们编写程序理清思路,也方便了其他人来阅读我们的程序。
沟通是具有目的性的,如果在没有明确目的的情况下与客户沟通,那将是浪费客户和自己的时间。这种目的,可以是了解项目的讯息、挖掘潜在的项目。沟通问题不仅仅存在与客户交流之中。还存在于与项目的各个角色之间。UML 的确是解决沟通问题的最佳手段之一,但不是万能的方式。使用与不使用 UML,其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的,就是好的沟通方式。沟通方式的选择对于达到沟通的目的也是很重要的。
参加比赛项目时,就要做到与队员的良好沟通,与项目的良好沟通。