友情提示:如果本网页打开太慢或显示不完整,请尝试鼠标右键“刷新”本网页!阅读过程发现任何错误请告诉我们,谢谢!! 报告错误
狗狗书籍 返回本书目录 我的书架 我的书签 TXT全本下载 进入书吧 加入书签

软件工程实践者的思想(PDF格式)-第12章

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!





…………………………………………………………Page 54……………………………………………………………

第 4 章  流于形式的沟通  



3。  最简沟通  



   在 D  项目中,我向我的项目组员提出在需求阶段与 



客户的沟通计划。这个计划只有三条:  



   )  在一个月中,只能跟客户作三次联系;  



   )   三次联系中,最多只能有一次面谈的机会;  



   )   一个月后,提交全部的需求调研报告、需求分析 



       和关于该项目的远景规划。  

     



   D 项目并不大,所以从主观上来讲,客户(代表) 并不 



会为这个项目投入太多的精力。重要的是,我们在前期交 



涉中已经发现:这个客户代表为大量其它的项目和工作所 



困扰,他不会有时间来处理我们的问题。因此,减少沟通 



和保障沟通质量的问题就显得非常突出。  



   在大多数的项目中,这样的问题都是存在的。真正能 



满足极限编程(XP)所提出的“现场客户”的情形并不经常 



出现。即使能将程序员送到客户现场中去,沟通问题仍然 



是不可避免的。  



   因此在 D 项目中我提出了“最简沟通”。  



     



   我们开始在网络上查看相关的软件系统的特征以抽 



取客户所关注的内容;了解该客户的公司、经营理念、组 



织结构形式以及工作模式;了解同类公司的成功经验和优 



秀的管理模式,以及客户的竞争对手在做什么和在关心什 



么……  



   最后,我们开始综合以下两个方面的因素:  



                                    …50


…………………………………………………………Page 55……………………………………………………………

                              『大道至简』  



   )  客户在公司层面的外在表现、内部机制和运营管 



      理手段。  



   )  客户在项目中既已明确的需求和可能发生的需 



      求,以及客户围绕其公司行为(和方向)所提出的 



      需求。  



   这样我们就了解了客户项目中所有会产生需求的信 



息点。  



   我们开始设计提问,每一个提问涵盖尽可能多的信息 



点,尽可能的具有发散性以便形成更多的推论和假设。  



   我们把这些做成项目概要用 mail     提交给客户,并在 



第二天电话回访他。他以口头的形式回复了这封 mail ,这 



让我们尽可能地得到了项目在方向上修正。  



     



   我们确定了项目的实际目标,以及远期的方向。接下 



来就是设计需求条目。  



   客户已经先期提供了一些关于项目的文档、报表和工 



作数据。因此基于这些数据的需求分析,将是下一个沟通 



前所进行的最坚苦的工作。项目组员被要求:  



   )  分析用户的每一个表格,以构建基础数据库;  



   )  分析每一条数据的含义以确定它的上下限,以及 



      数据间的相关性;  



   )  从工作文档中去了解客户的组织机构及其相互 



      关系,同时确定了每一类使用该系统的角色;  



   )  从报表中去了解客户关注的数据信息,以及被他 



      们所忽略掉的数据信息。  



   我们从数百条的需求条目中,整理出系统结构和模 



                                …51


…………………………………………………………Page 56……………………………………………………………

第 4 章  流于形式的沟通  



块,需求条目被映射到各个模块。我们很快画出了模块间 



的相互关系图,并通过这个图分析了数据交叉关系,设计 



了相应的数据索引并增加了一些新的关系性数据。  



    我们对用户角色、原始数据和系统结构进行了梳理之 



后,我们花了很短的时间实现了第一个系统模型。当然, 



很多的功能项目,我们都只是简单 show a dialog 。但我们 



优化了每一个操作流程,以保证不同的用户(角色)在使用 



时都尽可能流畅。  



     



    这一次的沟通我们使用了面对面的模式。我们很庆幸 



的得到了与这个系统的每一类用户(角色)接触的机会,而 



正好我们有一个模型,我们便让他们来操作并提出意见。 



这一次我们终于有了一份详尽的的调研报告。  



     



    接下来的分析设计是顺理成章的事。我们在一个月后 



完成了这个项目的需求分析报告,以及在这个分析上的一 



些框架型的设计。还有,一个被用户所接受的原始模型。  



    ——尽管,第三次的沟通中还发现了一些问题。但我 



们终于有了一个好的开端。  



     



    应该清楚的是,保障每一次沟通的有效性都是最重要 



的事。沟通不是打电话或者请客户吃饭那么简单的事。你 



得到的每一次沟通机会,都是向客户了解更深层次的需求 



的机会,因此最好在见到客户之前,你就已经设计了所有 



的问题和提问方式。  



    吃饭并不是有效的沟通。大多数时候,那将以酒醉收 



                                       …52


…………………………………………………………Page 57……………………………………………………………

                                     『大道至简』  



场。  



      



                                              



4。  为不存在的角色留下沟通的渠道  



    大多数人不会知道,我们中国的“五千年文明史”实 



际上仅有三千年“有史可查”。  



    司马迁在史记中写道:“维三代尚矣,年纪不可 



考,……于是略推,作三代世表”。也就是说,他在写史 



记时“(夏商周)三代”的年代已经不可考了,因此只能做 



 “世表”;而其后十二诸候国的年代才可考证,因而有“(十 



二诸侯)年表”。  



    世表和年表的准确性和可靠性有明显的差异,因此我 



国古代编年史能追溯到的上限,就成了《史记·十二诸侯 



年表》中记载的西周共和元年,亦即公元前 841 年。  



    司马迁无法做夏商周三代的年表是因为其年代不可 



                                        …53


…………………………………………………………Page 58……………………………………………………………

第 4 章  流于形式的沟通  



考,这是因为自黄帝以来的许多文献材料部分虽有年数, 



但比较模糊且不一致,所以他只能弃而不用。  



    现在国家在“夏商周断代工程”中再次推算和考证编 



年史,这些相关资料也同样只做参考,实际采用的方法是 



更有可信度的金文(记载) 、历史学、天文学、碳…14                测年 



等。  



    资料的缺失、及其有效性的缺乏,给中国编年史撰写 



带来了莫大的困难。  



      



    项目的中断和中止,与历史产生断层的内因是一致 



的。——我发现很多的项目(尤其是产品计划)在负责人员 



离开后,就自然而然地死掉了。我把这一切的原因归咎于 



 “没有history ”。  



      



    在先人写“谱牒”(简、册) 时想必是没有考虑过后人 



要读的,或者更为远古的先人可能根本没想过要留下他们 



的生活和部落记录,再加上有象秦始皇这样的人在前面放 



火烧东西,所以司马迁拿不到夏商周三代的确切史料,也 



是情理之中的事了。  



    ——远古的先人不知道司马迁这一号角色的存在,司 



马迁也没有办法跟古人约定一下要留点记录给他写《史 



记》。  



      



    我 们 做 项 目 的 时 候 , 如 果 也 不 留 下 历 史 记 录 



(History) 
返回目录 上一页 下一页 回到顶部 0 0
未阅读完?加入书签已便下次继续阅读!
温馨提示: 温看小说的同时发表评论,说出自己的看法和其它小伙伴们分享也不错哦!发表书评还可以获得积分和经验奖励,认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦!