读《构建之法》417章所思所感

faith-sy faith-sy     2022-10-30     664

关键词:

  仅针对这2章的阅读,主要讲的是团队之间,不仅是2人之间的,更是整个团队在完成一个项目、在一起工作时需要的各方面的力量,也有对领导力、绩效以及职业道德方面的讲述。

  以下就是我在读完1216章后的一些问题和感想。

Chapter 4 两人合作    

       查尔斯·塔列朗说:“比起由一只羊领导的一百头狮子,我更害怕由一头狮子领导的一百只羊。”如果自己要想有所作为,那就需要提升自己,提高影响力;如果在力所能及的范围内想帮助别人提升其价值,那也即帮助他们挺高影响力,让自己和队友通过相互想影响,提升技能。

1“代码规范问题”(P69

Q1代码是否一定需要规范?如果制定一个规范只是为了某个制度或者一些无关紧要的原因,还有必要花大量时间去制定吗?还是着重于花时间去解决问题而非表面?

A1:我觉得代码还是需要规范的,就像书里写到的,代码不仅仅是自己的代码,当别人接手的时候,很清晰、有条理的代码会让人心情舒畅,这其实不仅仅是为了别人,当自己对自己的代码进行复审时,良好且合理的规范也会让自己有一个好的心态去纠错。但是我觉得代码规范的个人性也应该是允许的。毕竟对自己的代码,由自己喜欢的视角去敲、去写是合理的。

       其实我觉得就像我们现在写博客一样,不仅于内容,博客整体的排版也会让其他人浏览的时候有一个良好的心情,虽然每一次的排版,我都会花不少的时间,但是每次有时间再回看自己的博客时,会有一种想继续读下去的感觉。一定的格式、排版是需要的,但是如果将其看作比本身更重要、耗费更多时间我觉得就是没有必要的了,会产生一种喧宾夺主的感觉。其次,代码规范性好比杂志、书籍的排版,虽然最后这个东西是不会显示在用户界面的,但是对于整个团队的架构、条理清晰还是有一定的作用的。不过也会产生一个疑问,如果就是对于一个人,他真的不适应某种排版,那当务之急应该是先完成好代码再去规范化代码,还是花时间使自己习惯某种格式再书写代码呢?这两者之间应该用怎样的心态来权衡呢?

 

2“两人合作的不同阶段和技巧”(P88

Q2两人结对完成项目,选择怎样的队友是一个方面,也只有双方都同意了才会成为结对队友。但是在两人结对期间,一方的能力高于另一方的情况是极有可能出现的,在这种时候会出现两种状况:第一是能力大的带动能力稍弱的共同进步;第二是能力稍弱的会产生依赖性与惰性,而对于能力强一点的、有能力独自完成项目、想在有限的时间做得更好的人来说,也会有两种情况:第一,花时间去与对方沟通、鼓励式影响有效,让对方再一次投入项目;第二则是选择妥协,以一人之力完成项目。那么,在我们遇到这种情况的时候应该怎么去处理、怎么去选择?

A2与队友一起协商、提升能力、共同完成一个项目是我们乐于看到的情形,但是上述情况也是不乏存在的。两者之间的取舍性我觉得还是有一定困难的。对于我自己来说,我是很想两人共同进步,一起合作完成项目,然后在这期间,能够和队友时常交流,在不断沟通中提升自己。我觉得这会是让自己能力提升的一个很有效的方法,但是这种方法也一定是需要两者的配合的,所以我觉得对于队友的选择性要求很高。但是现实生活中,并非每一个人都是优秀的,谁都希望有一个强大的队友,但是人也总会有累的时候,所以最好的就是让自己成长吧。最后我想说的是,当我们成为一个能力强大的人,需要帮助别人的时候,可以进行另外一种思考——“帮助那些离开我的帮助便无法登上珠峰的人会不会将变成我最大的成就

 

Chapter 17 人,绩效和职业道德

  在读这章之前,我也看了很多关于领导力、团队合作的书籍,在读那些书的时候很多观点都是大相径庭,但是在看这章的时候,我也有收获到一些很新颖的观点、类比以及看法。在软件团队的语境中,领导力需要的要素为:设定目标、知人善任、带领团队成长、绩效管理。“鸭子本身没错,错的是让他们翱翔或让它们从高空捕猎,这是它们不能做到的”领导就是要把人才放在合适的位置,让整个团队获得成功。作为领导,需要了解、尊重不同类型的下属,让其发挥长处;而作为下属,也更应该提升自己,用自己的能力、实力证明一切。

3“一个人对于某个领域可能有知识,但是未必有技能。……有知识但无技能的人,是否一定是‘行走的书橱’,没有大用?到也未必。”(P386

Q3对于IT行业、软件开发,如果是当一个领导,是否可以仅有管理知识、而无专业技能就可以胜任?

A3领导与管理——领导是人际技能,管理是决策技能。领导是管理的一部分,正如敲键盘和编程的关系,一个是子目标,一个是父目标。

  项目经理:从职业角度,是指企业建立以项目经理责任制为核心,对项目实行质量安全进度成本管理的责任保证体系和全面提高项目管理水平设立的重要管理岗位。它要负责处理所有事务性质的工作。也可称为执行制作人。项目经理是为项目的成功策划和执行负总责的人。项目经理是项目团队的领导者,项目经理首要职责是在预算范围内按时优质地领导项目小组完成全部项目工作内容,并使客户满意。为此项目经理必须在一系列的项目计划、组织和控制活动中做好领导工作,从而实现项目目标。

  领导:领导是在一定条件下,指引和影响个人或组织,实现某种目标的行动过程。

阿吉里斯(Argyris)指出:“领导即有效的影响。为了施加有效的影响,领导者需要对自己的影响进行实地的了解。

斯托格狄尔(R.M.Stodill)认为:“领导是对一个组织起来的团体为确立目标和实现目标所进行的活动施加影响的过程。

  我觉得成为一个做项目的团队的领导,尤其是我们专业,一定是要有技能的,仅是有知识在我看来并不能够胜任,要深入掌握某项技能,才有胜任的可能性,不然的话,就只是空有其表、说白话吧。在我的观念里,无论是哪方面的领头者,都是从最小的职位开始做起的,对于行业领域的足够熟悉,对于整个团队合作过程、项目操作过程的熟悉度、了解度,定是让其主导这个团队的重要核心。一个团队不仅需要成员的能力强大,也更需要领导者的指引。所以领导所扮演的角色、所推动的作用也一定是决定团队成功的核心。在我读到的关于领导力的书中,有过这样一句话:据估计,65%的员工辞职是因为自己的经理。我们常说员工辞掉工作或炒掉公司,但其实他们炒掉的是领导。‘公司’不会做不利于他们的事情,而‘人’会。”所以提升自己,让团队成员信任自己依靠的是能力而非魅力,让队员相信更要自己相信队员。

 

4“绩效管理”(P402

Q4“绩效”是一个很公平的方法,对于老师,现在都施行“绩效工资”,我觉得这个是很比较好衡量的,大部分都是按照课时计算。可是对于软件行业来说,怎样才能公平的衡量每个人在团队中的绩效呢?

A4首先最重要的是需要让团队知道自己做了什么 才能够让他人衡量自己的工作量,要勇于表达。我也在网上搜索到了一些相关资料。IT行业和其他行业对于绩效的考核应该也是有相同之处的。但其实在查了资料以及阅读了书中的部分之后,也没有非常明确的一个合理的绩效考核标准,下面就是我查到的一些资料吧。

绩效评估符合SMART标准:

 技术分享图片

对于IT行业的绩效来说,两大重要点,一是研发;二则是销售。我们暂且不谈销售,对于研发人员:

 技术分享图片 

 其他一些相关的制定的方法:

技术分享图片

MBO目标考核法,要求所有人全力配合一个设定好的目标,自己决定如何以最有效的方式,定期评估成果。

KPI关键绩效指标,将企业宏观战略目标分解为可操作的岗位目标,用于反映每个职位关键业绩的完成效果。

BSC平衡计分卡,从财务、客户、内部运营、学习与成长四个方面设置计分。

OKR管理思维模式与系统框架,更关注长远的大目标。

PBC个人事业承诺,由员工与直属管理者相谈指定个人计划。

 

读《构建之法》第4,17章有感

读《构建之法》第4,17章有感第四章:两人合作原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性。我的问题和看法:对于英语水平没有那么高的人来说... 查看详情

读《构建之法》第十七章有感

                                 &n 查看详情

读《构建之法》之一,二,十六章有感

...终将得到自己的一份收获。   这几天阅读了《构建之法》的第一,二,十六章,我个人的阅读速度应该属于比较慢的那种,遇到什么不确定的,不理解的概念总要停下来好久,各种百度,否则继续阅读的时候总有种急... 查看详情

读《构建之法》第4章第17章有感

第4章 两人合作问题1原文:P69 4.3.2 goto函数最好有单一的出口,为了达到这一目的,可以使用goto。只要有助于程序逻辑的清晰体现,什么方法都可以使用,包括goto。问题:对于goto语句,大一上学期C语言老师总是跟我... 查看详情

读《构建之法》第四,十七章有感

第四章:我看到这样一段文字:反对解体阶段:好不容易找到合适自己的编程伙伴,并且磨合了这么久,为啥在完美解决一个问题之后就要走向解散,各找舞伴?那样岂不是走了弯路?那么我们在学校没做完一个结对项目,就要... 查看详情

初读《构建之法》之所感

...程这个方面的了解还是比较少的。这学期正好有了个自学构建之法的任务,让我有机会接触到这本书,同时也让我对软件工程有了更深的认识。软件=程序+软件工程,这个等式足以体现了软件工程的重要性。按我目前的理解,程... 查看详情

读《构建之法》第四章第十七章有感

书是我们永远的朋友它陪伴我们走过人生的春夏秋冬在我们的生命中生根、发芽、枝繁叶茂书是人类发展的录像机我们可以在其中看到前辈的足迹 书是知识的海洋我愿是一叶轻舟,载着理想之帆在海面上荡漾它蕴含着祖祖辈... 查看详情

读构建之法第十七章有感(作业四)

第四章:问题:看到这里的时候,才注意到代码中的“下划线”这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处... 查看详情

读构建之法第四章第十七章有感

第四章 1、原文;“函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用。——P69”  问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之... 查看详情

读《构建之法》

这周精读了几遍《构建之法》的一、二、十六章,本人更偏好于语言精练概况的书籍,由于语言习惯问题,这本书对我而言有些解读困难。由此在下面对几章内容精练出总结概况,并提出问题。     第一章1.1软... 查看详情

读《构建之法》第四章第十七章有感

第四章  问题1:程序各方面的质量只取决于水平较高的程序员么?  引用:在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位。   结对编程在我看来是一种合... 查看详情

读《构建之法》

 在昨天读了《构建之法》前两章内容后,对软件工程有了进一步的认识。软件工程是一个很大的概念,包含了有关软件的方方面面,从软件的需求分析开始,到软件设计,软件构建,软件测试,软件维护等等。其中的每个环... 查看详情

《构建之法》第一章自习之所感

在本周自学了第二章的内容后才发现了自己以往编程所忽略的很多事情,就拿测试来说,以往的编程我几乎是不会去进行测试的。以前只知道把编好的代码一通敲进去,然后点击执行,结果对了就成。其实这样的做法,小型的程... 查看详情

构建之法后三章读后感

   开始读这本书,最大的感受的感受就是软件工程原来是可以这么学的,以前学习软件工程的课程的时候,总是感觉这门课程及其枯燥无味,总是在说太多的理论,很少会涉及到实践,甚至根本就是没有实践这个环节... 查看详情

读《构建之法》有感其五

这周读了第五章团队和流程团队的特点:1、有一致的集体目标,团队要一起完成这个目标。2、有各自的分工,互相依赖合作。软件团队的模式主要分成:主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团... 查看详情

读《构建之法》阅读与思考

读《构建之法》思考与疑问1、2与16章第一章概论问题1、2和3我看了人类文明要向前发展,离不开思考、发现、构建。我曾经在微软亚洲研究院技术创新部工作过七年,我所在的工程团队和很多计算机科学家在不同领域一起做项... 查看详情

《构建之法》第八章读后感

今天读了《构建之法》的第八章,需求分析,感悟很深。作为程序员,我们要做的是,将用户的需求充分挖掘出来,我们需要设身处地站在用户的角度上,将他们所说的需求实现,不仅仅如此,还要将之完善,并且预判将来的可... 查看详情

《构建之法》读第十七章收获(代码片段)

《构建之法》读第四、十七章收获第四章两人合作读了第四章,我才意识到代码规范的重要性,代码不仅要自己看懂,也要能让别人看懂,代码规范能使团队合作更好的进行。代码规范分为代码风格规范和代码设计规范。其中代... 查看详情