仅针对这2章的阅读，主要讲的是团队之间，不仅是2人之间的，更是整个团队在完成一个项目、在一起工作时需要的各方面的力量，也有对领导力、绩效以及职业道德方面的讲述。
以下就是我在读完1、2、16章后的一些问题和感想。
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：个人事业承诺，由员工与直属管理者相谈指定个人计划。
