团队之美 -- 读书笔记

Tim O'Relly的团队：

让每个人做他们想做的事情，自发地做。通过适当的引导，让对方产生积极的想法，从而改变他们的行为。就像盗梦空间里面描述的那样，把idea植入到下属的脑子里面，让对方觉得这些idea就是自己的想法，让后为之奋斗。

给定一个紧促的时间，然后做出一些事情，实现一些想法。急迫感通常能够激发出创意，和效率




IE 4.0和IE 5.0的团队：

和团队成员一起经历过磨难，然后才能互相信赖，互相依靠。因为这样就知道对方即使在最恶劣的环境下，也能够表现得很出色，而且这种表现在将来的合作中，也能够被依赖。

职场有句话说，和你一起加班到深夜的同事，通常都是和你关系最好的同事。因为，和这些人之间，我们已经在不知不觉中建立起了深厚的信任关系。




冲突管理的艺术：

发生冲突的时候，一般是某些人提出一个可能合理的要求，直接或者间接伤害到了另外一个的利益。作为管理者，就是站在整个项目的利益的角度，去进行取舍，做出安排和决定。
            
冲突管理的时候，领导需要承担风险，进度的风险，抗住上边下来的压力。

冲突也是最好激励的时候，让极力称赞每个人的长处，让对方觉得自己是可以给别人信赖的人。

有种冲突是有些才华突出，但是性格奇怪的人引起的。比如，有些能力很强的人，嘴上嘟嘟嚷嚷不情不愿，但实际上自己会加班加点做出最好的东西。这些人对别人表现出没有耐心，伤害别人的感情。   团队管理中，对这种人更应该制定特殊的管理策略，让他能够融入到团队中，让他能够信任其他团队成员。
操作手法：给他一些协作任务，让他必须依赖其他成员才能完成，想办法让其他的人能够在工作，或者在生活上给予支持。感恩的心理能够促成融洽的关系。




经理对团队成员的支持：

团队中有个很难管理，并且非常低效的，脑子缺根筋的成员，有时也是有用处了。  可以让经理利用这个难管的成员，向团队传递他永不放弃的精神，不放弃任何一个最难管的成员，往往能够收获到其他人对领导者的忠诚。 有忠诚才有士气， 士气不是靠高层几封邮件，号召大家为公司好好工作就能产生的。

有一个对所有人到保持敏感的领导，重视别人的长处，接受别人的缺陷。对桀骜不驯者，肯定其优点，肯定其价值，让他帮助其他的成员，得到价值的体现和满足。

敏感的领导要知道每个人做的怎么样，是否融洽，是否冷漠，是否某些人不喜欢和另外一些人说话，如何帮助他们。

对于冷漠的人，要帮助他打破心理的坚冰，让他能够信任别人。





团队士气的秘诀：

团队士气的秘诀在于一个愿景，作为领导者，需要帮每个团队成员勾画出一个可显现的愿景，下属能够从心底里接受这个愿景，并为之努力。 领导在这个过程中要不断地支持他们。

愿景的规划，对于不同的个体应该有所不同，每个人的需求不一样

鼓舞士气需要对成员所取得的成绩进行肯定，及时的赞扬。

让团队的每个人都知道，当前团队的工作正在发挥什么样的影响，积极的影响能够激发出每个人的自豪感，以及团队士气的巨大鼓舞。 让团队明白他们目前工作的意义所在。





营造能激发出创意的环境：

有这样一种环境，犯错误是可以得到包容，甚至是奖励的。 没有创新的风险就没有收益。要让所有人都勇于冒险

换一种角度来对待错误，包容错误，仔细分析错误的原因，甚至对犯错误的人进行表扬，因为他让所有的人增加了一条不再重复犯错的经验。

相比传统的做法，就是找到这个人，把他拉出来进行批斗，然后让其他所有的人引以为戒。


                     


开源项目管理的启示：

人员的演变，初期很多人都是使用者，后来迫于需求对软件某些部分调整，然后成为专家级用户，最后成为开发人员。

特点是非常容易提交这个软件的错误缺陷报告。





团队目标管理：

时刻让每个团队的成员都对项目的目标有一个清晰的认识，目标会不断地变化，所以目标变化的时候，也要保持团队对其正确的认识。

不统一的目标会让团队冲突，而冲突会导致分裂

不被表象的所谓的“目标”误导，用户对其目标的描述总是不明确的，这也很正常，因为以用户的能力无法清楚地描述出来。开发人员需要挖掘出用户描述语言背后的动力以及利益所在，再给出相应的建议。

确保项目干系人的目标，和团队目标一致。（询问最关键的项目干系人，项目远大目标是什么，然后分别问每一个团队成员，看他们对目标的理解与老总的目标是否一致）

有时候在一个项目中，发布日期并不是关键的目标，更为重要的目标是质量，以及体现出来的稳定性。 但大多数人都是习惯性地只盯住目标





分布式团队的管理：

有两个艰难的问题，一是信任的问题， 二是文化的问题

解决这两个问题的方法：  1.让两方的团队定期来回调动，  2. 虚拟拓展，让所有成员一起完成某些有趣的事情 
不经意的联系，能够促进团队的信任，比如饮水机问题：在接水的时候的交谈能够增进彼此间的关系

视频会议前后不经意的几句交谈，能够促进信任的产生。所以这些问候，不仅不是废话，而且非常重要。

团队中会有知识的引力和知识的中心，成为默认的领导者。做艰难决定的时候，必须要有个领导者，不然会由于大家都有高度的自尊而导致紧张的局面。




团队中的无形知识资产：

抽象于代码的原理，往往都没有文档记录下来，都在某些人的记忆里面。 为了避免这种知识的流失，建议制作录像，进行访谈，记录下架构的原理和细节。





优秀领导的几个特制：

一，善于表达， 很好地沟通，激发起大家的激情。 就像将军在打战前要做战前宣言一样。

二，在意人际关系，能够尊重别人的感受。当别人爱犬死了的时候，能够体会到别人的心情。

三，多个级别工作，向下能和开发谈代码，向上能和CEO谈战略


领导者勇于向权利部门讲真话，虽然这是拿自己的生计冒险，但这是这个职位上的人所必须做的。 “这个进度，太荒唐了..”  不然就是用一个谎言来掩盖另外一个谎言





敏捷中的部落记忆：

敏捷开发中由于架构变更实在太快，快到无法用文档记录下来。 有些高于代码，抽象于代码的原理就只保存在某些人的记忆里面。

如果能把这部分记忆抽取出来，那就是一种财富，比较好的方法是访谈，并记录整个过程。用文档的话，很难写全。






富有激情的团队：

即使知道公司即将解散，仍然饱含热情的工作。 原因是有一个迫切期望实现的目标。  并且每个人都能从这个目标的实现过程中受益。

所以，这个团队目标的贯彻是非常重要的，要让所有人发自内心地接受这样的一个目标，并成为他自己想法的一部分。






目标对质量的影响

产出了劣质代码的原因都和团队以及投资人之间对目标的不明确有关。  投资人所需要的是功能完善，质量优，时间可以再谈， 而开发人员，则最关注那个时间，为了按时交付，舍弃了一定的质量（CodeReview，设计评审），或者舍弃了一些功能

再有，比如有些成员，基调目标就是按时完成这个项目，得到升迁，以后再也不会和这个项目打交道，所以项目的质量在时间面前也被牺牲掉了。

相反，有些功能代码，也许只用一次就不会再去用。这种代码质量就无需像那些要工作10年的代码保持一个质量。 理解了这个目标有助于分清主次，关注焦点





开发团队最重要的2件事

一是持续集成，这似乎是一个比较容易实现的目标

二是自动测试，想完成自动测试壮举，那么测试代码在功能代码之前就必须高质量地准备好，并且需求不变，则测试代码不变。

这2件事情是提高质量和效率的法宝，但事实上很多团队并不怎么能够真正贯彻下来

另外对于敏捷的团队，有几个实践很重要，  任务板，列出所有的任务， 设计，测试，开发的进度。  这个任务版一定要在很显眼的地方，不然就没有价值。





写评论法;让开发人员和干系人的目标一致

产品一定会有人评论的，那么在开发产品之前，团队成员就对这个产品写一篇自己的评论， 等到最后发布的时候，检验别人给这个产品的评论，看它是否和我们自己所写的评论一致。

比如： 这个产品是所有同类中速度最快的， 他也是最经济实惠的， 用户体验相当不错的。

开发过程中，所有人就能够朝着这个目标前进，不偏离航向。





多团队项目的管理：

不同公司多个团队一起开发的时候，最难的环节就是确保所有的团队，所有的人，其目标和动机保持一致。  但事与愿违是常事，不同的团队有不同的需求，出发点，利益这些因素都会有可能干扰到真正的目标。

有一致的目标和动机，才能在最终客户眼中这10多个团队是一个整体。

招人的时候，确保招进来的人，不完全是为了更多的钱， 要有明确的激励因素。 找出激励的因素，不同行业，不同个人，激励因素也许会不一样。
比如陆军工程， 号召天才的加入为了自由和生命而奋斗。  ADM是用定向广告来改变北美的广告业布局，将来更精确地定位广告而奋斗。 关键是让人觉得自己在做有意义的事情。





业务知识的重要性：

让资深的技术专家熟悉用户的业务知识，具备工程技术知识，具备领域知识，才能让我们开发人员的魔法发挥最大的能力。能够创造出很多很棒的想法，并实现他们。

领域知识和工程知识的非常重要，将此合二为一的人，能够遇见到未来的发展。

拥有领域知识的工程人员，是团队中最重要的人员




向团队中推行新实践：

团队工作方式的改变对于团队的成员来说，可能是非常痛苦的。所以领导者必须用其卓著的口才，引导成员明白其中的价值。 另外对买单者施加影响，让其明白新实践的重要价值和意义。

团队工作方式的改变是一件比较危险的事情，最危险的是把不适合的方式强加到了团队身上




敏捷实践：

评审测试用例，也就是TDD，在代码之前就把测试用例完整地写出来了，并且通过评审。需求不变，测试用例不变。

结对编程，相当于实时的Code Review，有助于代码质量的提高。

结对编程可以关注不同的领域，可以先关注在用户用例, 测试代码的编写。  如果能够让前面的2个事情做好，可以再尝试结对编程进行具体的实现。

敏捷和过程管理一样，都需要开发需求这个环节。

通过对团队的观察得到结论，其实并不是每个人都能适应结对编程，有些人，有些工作是可以单枪匹马完成的。





团队建设以及团队身份

公司应该确立明确的预算用于团队建设，这笔预算可以采用更有效的方式来使用。

1. 对于团队身份的确立，让这个团队有个明确的标示，T-Shirt, 咖啡杯，水壶，背包等，让团队的概念深入到生活当中

2. 适当的集体活动，比如球赛，或者e-game，或者协作等。

3. 吃顿饭的方式初期可以用，但不适合用的太频繁





团队状况：

如果有人是不可或缺的，那么说明这个团队存在问题

团队中如果有冲突，或者相互之间有点矛盾，应该及早的着手处理，要让成员用于上报问题，或者保持敏感的心理，及早发现存在的问题， 行动要及时才可以。

另外要确保团队知道自己的目标，这个目标要和投资人的目标一致。  不能出现团队成员多半关注技术，以及有趣的功能。 但不注重交付，以及利润。




打造完美的团队，关键要素：

对于利益相关者的目标，有统一的认识

制定一个产品极其结果的愿景，并让大家都认同（不是仅仅知道就可以的）

尊重每一个成员，及时解决团队中不协调的因素
              




NASA的开发团队：

对质量，细节的关注，都形成了一种文化。 因为所有的人都知道，一旦任何一个非正常的错误发生，我们都没有第二次机会修复了。

明确的目标（看的见摸得着的，比如赶上时间窗）有助于一致的行动，而抽象的目标很难把握方向（构建可复用的平台）





成功的需求开发：

组件需求开发团队，既包括工程师，也包括利益相关人的代表们

进行期望管理，通过沟通让利益相关人知道这次需求开发的重要性，以及需要达成的目标，启动需求开发过程

对利益相关人的代表们进行分类，明确开发团队的负责人

不同利益代表分别讨论，采用一定的提问技巧，理解用户目标，现有的工作，工作的任务，以及他们期望新的系统能够如何帮助到他们。

采用活动挂图来总结讨论的成果，这些挂图就是一个个的用户用例。

每个用例，都再次设计出这个用例的测试方法过程，编写出来。编写测试的过程，能够从另外一个角度审视这个用例

最后将用例进行评审，所有的人坐在一起，由其中一部分人把用例用自己话说出来 （同样的文字，不同人有不同理解）

从用例中构建出GUI，并确保这个GUI能够实现用户所有的用例。


整个需求开发的人们在这个阶段是一个团队，需要一定的激励，鼓舞开发团队的士气，定时召开需求开发会议。
对于每个成员，都要布置好Homework，在一起开会的时候只进行讨论和表决

非功能需求：安全，性能，易用性，扩展性，健壮，维护 等，让所有的用户对这些特性进行评级



总之，需求的开发非常重要，如果你不想让你的代码生命只有1个星期，或者是3天的话，那么就要重视需求的开发。





团队的交流方式：

团队中成员相互间的交流方式比今天你使用的任何一种很酷的新技术所产生的影响都要大

每个人都要调整和其他人相处的方式，在这方面，经理要给予帮助，确保团队的沟通顺畅

让每个人的声音都能够得到传递