码迷,mamicode.com
首页 > 其他好文 > 详细

大道至简——软件工程实践者的思想读书笔记二

时间:2015-05-13 16:24:14      阅读:120      评论:0      收藏:0      [点我收藏+]

标签:

第四章 流于形式的沟通

C语言是程序员与计算机交流的语言,而不是他与客户交流的语言,程序员面对的是计算机,但计算机不是客户。因此,开发人员最好不要直接面对客户。项目经理由这样一种优势: 他可以不用了解C语言,也可以用一种非C的语言来与客户交流。

要深入项目需求阶段的项目经理或者调研人员,被要求深谙项目所涉及的业务。但这往往是做不到的,因此惯常的做法是聘请行业咨询公司(或个人)来介入需求阶段,以协助了解和分析需求。

沟通时需要确认沟通方式的有效性,而不是追求这种方式是不是UML,以及用UML表达得是否正确。客户是因为他认为你理解了他的需求而在“需求确认书”上签字,而不是因为你的UML图画得是否精确。

沟通的三层障碍

1. 沟通并不在于你要表达的内容,而在于你如何表达。此时,你需要组织语言,学会说话。“对不起,先生,我们这里没有你想要的东西……”和“对不起,先生,你想要的东西我们这里没有”的区别:前一句的语气是在“致歉”,后一句则是在“推诿”。

从叙述中揣度结果,是人们子啊交流沟通过程中潜在的意识和行为。如果两个人在努力地交流,那么他们一定会无比细致地去分析对方的描述,因此,他们事实上都回关注对方的措辞、语气、句法,或者分析表达的前后逻辑与关联,这么做的目的是:

  a. 找到对方表达的潜在含义与目的

  b. 找到对方叙述中的逻辑错误

第一个是支持者的心态,第二个是反对者的心态,这两种心态就是一个会议的全部内容。

2. 第二层障碍出现在跟聪明人的讨论中,让人觉得“不知所为”。此时,应当预设前提,并尽早阐述结论。

对于两个聪明人而言,正确的结论通常只有一个,因此,如果出现了争执,那么讨论的一定不是同一个问题。

一个结论是需要在大多数人之间做出,还是只需要在一两个人之间做出,是在一开始就要被确定下来的。

3. 沟通不知缓急。此时,不要把沟通目标设定为“让对方认同”。

用尽可能少的人、在尽可能短的时间内做出决策,是降低沟通成本的关键。

作为管理者,应当去观察、理解和发现问题(或由专人汇报),你要尽量去听,去思考,因为作为这个角色,你总是有机会纠正问题的。但是,不要急于去纠正。在一个会议上即使某种想法有问题,也绝不是在你发言的三分钟里就能纠正的,而是在最后你做出的决策里去纠正。这种决策通常有两种:给出明确答案和存而不论。

沟通不过是手段,是工具之一,而管理者的目标是项目本身。因此讨论不清楚就暂不清楚,让需要讨论的人继续去讨论。

保障每一次沟通的有效性都是最重要的事。你得到的每一次沟通机会,都是向客户了解更深层次需求的机会,因此最好在见到客户之前,你就已经设计了所有的问题和提问方式。

历史记录与注释不是一回事。代码中的注释是为阅读代码而留备的,而历史是为整个项目而记录的。一些参考的记录内容有:

  a. 需求阶段:与谁联系、联系方式、过程、结果以及由此引发的需求或变更

  b. 设计阶段:如何进行设计,最初的构架,各个阶段的框架变化,因需求变更导致的项目结构上的变化(有助于了解构架的可扩充性)

  c. 开发阶段:每一种技术选型的过程,每一种开发技巧的细节和相关文档,摘引的每一段代码、算法、开发包、组件库的出处和评测,程序单元的测试框架,每一个设计和构架变更所导致的影响。

  d. 测试阶段:测试用例和测试报告

其实,沟通是具有目的性的,如果在没有明确目的的情况下与客户沟通,那将是浪费客户和自己的时间。这种目的,可以是了解项目的讯息,挖掘潜在的项目……最末了,才是交流感情。

沟通问题不仅仅存在于你跟客户的交流之中,还存在于项目的各个角色之间。

使用与不使用UML,其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的,就是好的沟通方式。

流于形式的沟通,极有可能是你的项目被不断推翻和不断延迟的最直接原因

第五章 失败的过程也是过程

瀑布模型将软件开发过程分成需求、分析、设计、开发和测试五个阶段。

从最开始,从我们编程开始,我们的目的就是实现一个东西,而工程,只是一种实现的途径。

越是简单的东西,往往越是接近于本质。

大道至简——软件工程实践者的思想读书笔记二

标签:

原文地址:http://www.cnblogs.com/Ribbon/p/4500456.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!