人月神话札记之专制、民主和系统设计

前言:大教堂的整体设计在基本元素构成上都是一致的。有的教堂偏重于设计师的个人创意,有的教堂舍取设计师的创意而保证设计的纯粹性,在书中提出的观点中,对于计算机系统来说,保持概念的一致性是至关重要的,省略不规则的特性和改进,而反映一系列连贯的设计思路。

获得概念的完整性

  1. 一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时,就会难以普及和推广,我觉得产品的易用性是特别重要的。就比如说CSDN推出的Markdown和xheditor相比较,我觉得Markdown并没有征服我,主要是其用起来并不容易。
  2. 把易用性作为软件开发的目标来讲,功能和其复杂程度的比值将是最终的标准。功能本身如何强大,或者功能使用起来如何简便都不能作为标准。
  3. 当确定易用性作为开发目标来讲,产品经理、项目经理就要在简洁性和功能上做出衡量,就像我们大多数人来说,我们来制作一个图片效果时,用美图秀秀就可以了,非要去用Photoshop那会是痛苦的。那也就是说,Photoshop的设计师和美图秀秀的设计师就要去把控简洁性和功能。

贵族专制和民主政治

  1. 要保证概念的完整性,就必须要求设计由一个人完成,或者非常少数的人默契的完成。
  2. 很多时候,我们会说从用户、开发人员那里获得创意,来制作更好的产品。但是书中的观点想要告诉我们,在产品设计上去采用民主,往往会失去概念的完整性。从乔布斯传中,我也得出,好的设计显然不可能来自用户,也不能来自于开发人员,因为用户往往只需要一匹快马,而不会需要一辆汽车;而开发人员往往会因为技术实现的难易去掩盖伟大的创意。所以,在产品的设计上,保持专制是不需要有歉意的。
  3. 开发人员在开发过程中的创意并不比设计师设计产品的过程中差,很多时候,在实现设计的过程中,会伴随更好的创意。就比如说赫兹菲尔德(我记不起来了)实现了层叠窗口,这就是一个伟大的创意。
  4. 另外,资源在有限的情况下,人们往往会发挥更强大的潜力,所以乔布斯的那些现实扭曲力场才会在苹果激发员工的激情,从而实现了苹果的伟大。

在等待时,实现员工该做什么

  1. 在早期的瀑布开发流程中,产品的开发人员的确要等到产品的设计师们把需求做成文档,并且经过大量的BI、BD、FD才会到MK阶段,虽然我现在处在敏捷开发迭代中,但是同样会面对这个问题,在产品分析设计阶段,代码开发人员该做什么?显然书中告诫我们,不能将实现者加入到设计者队伍中,这将会带来致命的危险。
  2. 开发人员往往会有以下疑问:
    • 设计中功能繁多,不考虑成本。
    • 结构师剥夺了开发人员的创造力。
    • 设计师在工作阶段,开发人员只能等待。
  3. 对于2中出现问题,第一个的解决方案到下一章中再说;第二个在目录2中已有介绍,不再赘述;对于第三个问题,如果存在像建造建筑物的时间差点时,那么就等到开始建造的时候,再请工人。另外的解决方案是,在实际的软件作业过程中,很很多工作都要平行的开展。就如同我的小组有三个人,我负责整体设计,另外一名负责的是winform开发,还有一个负责Java方面开发,那么在我讨论设计方案的时候,我会让他们各自调查实现方案,给我确认能够进展的方向。还有就是我们的项目很多分支,我可以交给每个人去解决bug,去预热接下来要开发的内容等等。总之开发人员虽然不便参与设计,当然我也会征求他们的意见,但是在软件作业过程中,等待几乎是不可能存在的,只要合理安排任务,就让人员充分利用,这要建立在有一个好的作业环境。
时间: 2024-12-20 01:05:12

人月神话札记之专制、民主和系统设计的相关文章

人月神话札记之人月神话

前言:美食的烹饪需要时间,那么稍等片刻,你将享用更多的美味.缺乏合理的进度安排是造成项目滞后的重要原因,因素有以下内容: - 对估算技术缺乏有效的研究 - 进度和工作量混淆,就是说人员和时间可以转换 - 对自己的估算缺乏信心 - 缺乏信心 - 对进度缺少跟踪和监督,所以站立会和燃尽图至关重要 - 意识到进度偏移时,第一个反应是增加人力,而这时大多数情况如同火上浇油,火越来越大,需要的汽油却越来越多 乐观主义 书中说,编程人员都是乐观主义者,我想,在国内,需求者比编程人员更"乐观",他们

人月神话札记之巴比伦塔失败

前言:在最初的世界,人们只有一种语言,所以大家沟通好说去建立一个通天塔,可以通往天堂的巴比伦塔,然而上帝出现了,他交给人们不同的语言,让大伙最终无法进行交流,最终队伍遣散,巴比伦塔就此失败,那么本章作者想要告诉我们的就是"沟通"对于成功的项目很重要. 编程项目中的交流 书中主要针对的是大型项目的交流,然而同样适合我当前所处的团队: 非正式交流:以前在日企和日方沟通主要是电话会议,那么小型团队的非正式交流就是协作的人员互相凑一起说话就可以了. 会议:站立会,分析讨论会,项目评估会等任何有

人月神话札记之外科手术队伍

前言:研究表明,效率高和效率低的实施者之间个体差异非常大,能够达到数量级的水平.类似我这样年龄段的产品经理来说,我认为我只需要有5个精干的成员组成团队,然而我这样的想法就面对着一个很难回避的问题-这样的小型团队很难在有计划的进度安排时间内创造大型的系统! 问题 大家知道,优秀的程序员和较差的程序员的效率存在巨大差异,书中也指出来最好和最差的效率上平均为10:1,编程速度和空间上具有5:1的惊人差异. 需要协作沟通的人员数量影响开发成本,这就意味着人员数量少的情况下,沟通就会减少.然而这不适合于大

人月神话札记:未雨绸缪

前言:软件在设计阶段如果能够多考虑一些后续的维护工作,显然是非常棒的.然而对于现阶段的我,或者很多程序员来说,未雨绸缪有很大难度,我们往往即使已经下雨了,也依然无法把窗户关紧,那么如果你想得到一些指导的话,请随我来,看看我能否品出一些味道来. 没有什么是永恒的,除了变化. 普遍的做法是,选择一个方案,试试看:如果失败了,没关系,再试试别的.不管怎么样,重要的是去尝试. 我觉得书中提供的这两个观点非常的棒,首先,任何事都不可能一成不变,敏捷宣言也提倡我们要拥抱变化.其次,在解决问题的时候,就是要不

人月神话札记:提纲挈领

前言:所谓提纲挈领,从字面上讲就是抓住渔网的总绳,提起衣服的领子,其含义(度娘说要用含义而不推荐用涵义)就是告诉我们做事情要能够抓住要领.那么本篇告诉我们什么是要领呢,就是书面文档,从一开始就要意识到其重要性,那么就不会对文档产生厌烦.因为作为技术人员来说,包括我,普遍对文档没有好感,尤其是看完了长篇大论后,发现无非就是要表达一两句话,那时候,就会气急败坏. 计算机产品的文档 对于该小节,我读了三遍,发现并没有很好的理解,所谓预测->报价->价格之间相互制约的关系,没有弄出来个所以然.希望在以

人月神话札记:干将莫邪

前言:A good workman is known by his tools.外国谚语如此,我们也有这样的古话,"工欲善其事,必先利其器".好的开发团队自然有自己一套比较完好的工具,用来提高生产力以及生产效率. 在学习编程的某一段岁月,我喜欢尝试用各种Java的开发工具,editplus.eclipse.jcreator.myeclipse.netbeans等等,最后,我决定使用eclipse.这一段探索的岁月,也证明了brooks的观点,在工作环境中,如果开发人员的工具不够统一的话

成功需要一个好基石 ——读《人月神话》有感

历经了前面的种种困难,才懂得"成功"两字的分量是多么的重,不仅仅是来之不易,更是无法复制的.使得一个项目成功需要很多的因素,俗话说:"好的开始是成功的一半",读了<人月神话>也就明白了怎样让一个项目有一个好的开始.为了呼应主题,我将好的开始称作"基石". 效率高和效率低的 实施者之间具体差距非常大,经常达到了数量级的水平,这也就产生了一个最基本的问题:如何分工?这个问题看似简单,实则包含了人员数量,工作种类.管理结构.任务分配等,每一

读&lt;&lt;人月神话&gt;&gt;

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职

人月神话阅读笔记07

第1章 焦油坑      焦油坑的意思说明了即使你足够强大,也无法摆脱束搏而沉到坑底.IT项目也是这样,不论是开发大型软件系统还是小型项目,都会遇到诸多复杂的问题和影响因素,项目本身就是一个足够复杂的动态系统,没有最优,只有满意.项目四要素,人员,组织环境,干系人,外部依赖和约束,风险和假设,团队,人等诸多问题都是你必须要考虑的问题,任何一个要素出现大的差错都可能导致项目失败,只有所有要素能够平衡好,团队能够协调一致才能够保证项目成功 第2章 人月神话      进度问题是IT项目管理最为关注的