标签：
第六章 谁是解结的人
在一个模式化的公司里，体制上最大的敌人其实是模式本身。
在通常情况下，一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。
成功的经验往往最不可信，因为一方面，成功者沉醉于成功的喜悦，并急于与人分享快乐与荣誉，而不关注这些成功的前提与背景。另一方面，听取这些经验的人则因为那些“既有的成功”而丧失了应有的警惕。
经验，是源于对过去的思考，而不是对过去的复制。
只有提出质疑，才能换个角度去看到那些成功经验所依赖的背景，也才能看到某些成功背后的偶然或者关联的因素。
你的团队无论如何都需要有一个远期的目标。
远景更多地侧重于方向性的描述，而阶段性目标的确也是必须的，原因：
明确阶段性目标以便于团队实施和检测
细化的设定目标更加灵活，便于修正
阶段性成功能充分激励团队的士气
项目经理的主体工作是：协调，督促，激励，监督，凝聚。
应该让团队每一个人清楚：“我”必须跑到终点，否则“团队”到不了终点。这是每个个体的责任，没有人可以替代——这是培养责任心和树立价值观的事。
培养一个人最怕的是“教而不习”，你教他，他要么不学，要么不用，但是事情的真相，不见得是这个人“懒”到不学习，而是你过于勤快，让他失去了“习”的机会。所谓学习，就是让他在过程中看到问题，并了解到解决问题的方法，最后加以解决。
于一个人而言，“成功”的激励远大于其他。
过于强调个人能力，会助长团队的惰性。团队管理是促进整体行进的过程。
管理者的责任也包括“监督，发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题，在问题出现之前定位它、分析它，并组织人力去解决它，而不是：
等问题出现后再冲到前面
然后在还没有清楚地意识到问题的根源时就试图解决它
最后刚解决了表面问题或者侧面问题，又发现更多的问题挡在前面
最后之最后，你垮掉，团队也垮掉
即使你什么也不做，也比整队人都停下来要强得多。
学会否定矛盾、消化矛盾，看到矛盾产生的内因、外因，转而借之用之，才是解脱的方法。
第七章 从编程到工程
语言只是工具。
从角色的角度上来说，开发经理思考项目的实施方案和管理具体的开发行为，而项目经理则保障团队的稳定性和一致性。
经验来源于回顾、理解和分析，而不是你将要写的下一行代码。
过程说的是很多人（团队）如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样，有了环节，就有了角色，有了角色，就有了沟通。因此，过程中的问题就是角色、沟通和环节的问题。哪些环节重要，取决于具体的编程行为，也就是具体的项目。
角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互协作是否紧密，是这个项目能否成功的保障。
项目的“复杂”可能要求不同知识领域的角色参与，而“庞大”则要求更多的（人、技术与管理）资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。
团队必将越来越庞大，因为（与工程对应的）软件必将越来越复杂。没有团队意识的软件公司在高度过程化、通晓方法论、拥有大量工具的集团军面前，必将一触即溃。
你必须更关注于对这个（或这些）工程的组织与计划。站在“组织者”这个角色上，你现在要考虑的内容可能会是：
为项目的各个阶段建立计划、并逐渐地细化计划的内容，以及确立项目过程中每一个环节，每一个计划阶段的优先级和复杂度。
确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其评核办法。
对团队中的不同角色开展培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响。
为每一个人准备他所需要的资源，准确地评估他的工作量，以及决定是否为他增加一个副手。
决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度。
习惯于开会、组织更短而有效的会议，以及建立激励机制，当然也不要忘记让每一个成员意识到这一项目的风险。
不要乐观。
好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。
回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
经营者决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的架构下的一个具体行为。
第八章 你看得到工具的本质吗？
工具之于工程，本质在于关注并发挥有益于工程全局的那些特性。
不同的工程角色确实应当有他自己的关注点。这个角色能考虑到别人想不到的问题，固然不错，但如果他恪尽职守，只关注自己的那一部分，也是本分。
一项技术是以完成工程需求为目标的，而不是以彰显个人技术为目标的。
技术容不得取巧，只能点滴累积。“静下心来做代码”是开发人员的良好品质。作为开发人员，我们不应当妄自菲薄，作为管理人员，我们更应该善而用之。
“写代码”并不是解决问题的唯一方式。融通是以一通十，有运用变化的能力。融同，是知工具之大同，信手而得，随心而用。
工程实践中，用或者不用某个工具，仅取决于工程本身的需要，而不取决于喜好，也不取决于现实中的大公司与外来布道者的鼓吹。
于某时某事，适用的就是最好的。前提是你要有看明白这些工具实质的能力。只要能够分辨出所需要的部分并适度地用在你的工程中，就可以了。
识见到工具“设计”所满足的那些“确定的需求”，进而明确工具与项目的关系，才是解脱之法。
标签：
原文地址：http://www.cnblogs.com/Ribbon/p/4503365.html
