软件工程-六 谁是解结的人
是谁的问题
在通常情况下，一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。特质的形成，是管理者的问题。他或者是主观地培养，或者是在不经意中形成，或者这根本就是管理者个人特质扩散开来的一种群体特征，但无论如何，维护有益于团队整体的特质，是管理者的责任。
正视你的成功
成功的经验往往最不可信，因为一方面，成功者沉醉于成功的喜悦，并急于与人分享快乐与荣誉，而不关注这些成功的前提与背景；另一方面，听取这些经验的人则因为那些“既有的成功”而丧失了应有的警醒。
解决问题而不是来分享成功的。你的那些成功经验，未见得都是可以或应该与团队分享的。如果需要，对失败案例进行分析，并与团队中的成员分享可能要好得多。
不要把自己的经验直接拿到项目中来套。“我曾经做过”、“我这样想过”、“对这个问题我思考过了”，这些言论只能把问题的根苗填实在团队的缝隙里。
总得先做点儿什么吧
团队无论如何都需要有一个远期的目标（然而我发现事实上很多管理者并不善于描述远景）。团队的远景与目标不一定非得是“特定项目的特定结果”，例如远景不见得是你现在正在做或者准备完成的项目。举一个例子来说，远景可以是“打造公司的精英团队”，或者“挖掘某项目技术在某某行业中的应用”这样的描述。前者以精神形象约束团队，后者以技术方向引导团队。远景的具体设定，取决于团队的结构、项目的特性和管理者个人的素养。
远景更多地侧重于方向的描述，而阶段性目标的确也是必需的。这至少有三个原因：
- 明确阶段性目标以便于团队实施和检测；
- 细化的设定目标更加灵活，便于修正；
- 阶段性成功能充分激励团队的士气。
但是无论是对大的远景，还是小的目标，在团队中并不需要每个人都予以密切关注。所以对目标进行阶段性设定与回顾，是使这些“并不时时关注方向的人”也能体会到方向感的最佳方法。
团队有三点特性：
- 方向和目标明确；
- 团结并分工协作；
- 能意识风险并有规避策略。
你不是团队的腿
如果“头羊”是技术经理，或者是团队中的某个“精神领袖”，那么（作为项目经理的）你就是教官。你的工作主体是：协调、督促、激励、监督和凝聚。
大凡是从技术出身的管理人员，总会有愚公那种本能的“实现欲望”。如果一件事自己能做而别人不能或者做得不够好，那么他总是恨不得自己去做。的确，对于一些技术细节来说，你“也许”能立即着手去解决。但是，一方面你根本不可能通过“亲力亲为”解决掉“团队行进”的问题；而在另一方面，你至少为团队带来了下面这四重危险。
- “我”必须跑到终点，否则“团队”到不了终点。这是每个个体的责任，没有人可以替代——这是培养责任心和树立价值观的事。假使你真能成为这个人的腿，“跑”到终点，那么这个团队的成员将会置疑于自己的价值和能力，也会忘却自己的责任。一个人如果在团队中没有价值，也没有责任，那么他离辞职也就不远了。
- 培养一个人最怕的是“教而不习”：你教他，他要么不学，要么不用。但是，事情的真相，不见得就是这个人“懒”到不学习，而是你过于勤快，让他失去了“习”的机会。所谓学习，就是让他在过程中看到问题，并了解到解决问题的方法，最后加以解决。
- 于一个人而言，“成功”的激励远大于其他。一个人从来没有享受过登顶的乐趣，那么他一定不会喜欢登山的过程。而你帮他跑到终点，事实上也剥夺了他作为团队成员来分享成功的权利（虽然项目奖励可能不会少，然而这只是形式的，而非内心的所得）。让一个人总是去做“没有成就感”的工作，他必将渐而生厌，你也无异于自毁长城。
- 你过于强调了个人的能力，这会助长团队的惰性。团队管理是促进整体行进的过程，因此基本上来说，你的行为事实上是在暗示其他的团队成员“你们也可以不跑到终点”。这种暗示的结果，是管理层变成了执行层。由此，原来的执行层变得效率低下，而管理层疲于奔命。你忽略了管理自身的价值，以及你作为管理者的工作内容，因而为整个的管理过程种下了恶因。
对于团队来说，“解决掉一个技术问题”，远比“团队的整体行进”次要，因此你不要冲在前面披荆斩棘——把这件事交给技术经理去做，或者教而习之，由成员自己去做。你首先要明确自己的责任是“整个团队的目标”。
如果你真是好的教官，如果你关注于“整体的目标”，那你就应该早早地发现这个团队或某个个体存在问题的“原因”。大多数管理者并不是因为能力不够而做不到这一点（哪怕这看起来好像是“未卜先知”的神术），而正是因为你过度陷于实施，无法履行你的监督职责——因为你不可能监督自己。
应该记往管理者的责任也包括“监督，发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题，在问题出现之前定位它、分析它，并组织人力去解决它，而不是：
- 等到问题出现之后再去冲到前面；
- 然后在还没有清楚地意识到问题的根源时就试图解决之；
- 最后刚解决了表面问题或者侧面问题，又发现更多的问题挡在前面；
- 最后之最后，你垮掉，团队也垮掉。
团队管理中的每一个话题，都足以写出一本书。而对于每一个从技术走上管理的项目经理来说，记住“你不是团队的腿”可能是一个最好的起点。
三鼓而竭
“三鼓而竭”的本意，是指振奋士气这件事经不起一再空耗。“鼓”在原文中是指外在的激发、激励。而“三”这个字，在原文中是实指三次，而在引申的含义中则是虚数，表明多次地、频繁地激励与消耗。
我知道有很多管理者习惯否定别人的想法，而不是肯定之。这个问题的根源，一般是由于管理者从技术出身，因而总是主观地认为自己“有更加绝妙的想法”。但是，不管你的想法是否真的“绝妙”，从管理的角度来说，这种“否定别人”的做法，其实是一个非常愚笨的主意。
根本上说，“怎么做一件事”是一个人的态度问题、性格问题、品行问题。团队成员能有点想法，本身就是值得提倡的：想法成熟，则对工程进展有推动（如改进工程技术、方法）；想法不成熟，善以用之，则可以对团队建设有推动（如进行团队教育、激励）。因此，万不可拒“意见（或想法）”于千里，把团队“自下而上”沟通的道路给堵死了。——你在牺牲团队成员的同时，也失去了建设团队特质的机会，二者之任一，都是你作为管理者的失职。
现在开始，你不妨把这个愣头青看做愿意“贡献集体智慧”的表率，从他开始，为团队内部的积极沟通带个好头。至于接下来如何讨论：认同他、引导他，或者说服他，那才是“理”的问题。态度可以认可，至于“想法好不好”是技术问题。你不宜急于表态，因为团队中还有“头羊”，还有“精神领袖”，实在不行，还有“聚室而谋曰”。
先人后己
管理者一定不要忘记在开始“忙”之前做一件事：驱动你的团队。这就是我所谓的“先人后己”。
很简单的算法：如果你忙一天，也就是一个人的工效；如果你的团队（例如20人）一天都在忙，那么会有20个人的工效。即使他们每个个体都不如你一样地能干，工薪也没有你高，但是只要能驱动整个团队，20个人的工效终归大于你，（日薪的）投入与产出比也终归是大于你的。因此从管理学上来说，推动团队比推动个人要经济得多。
“先人后己”，在开始自己的工作之前就来招呼大家了：安排每个人的工作，或者解决某些人的问题，那么这会是美好的一天。然而如果他总是等到发现很多人无所事事时，再来找大家的茬儿，那么这个项目经理离离职也就不远了
这个“让影响到别人的事先做”的思想，与“团队高于个人”的观念是一致的（只是后者听起来有点学究和政治，因此德育课老师也许曾经给你讲过这些，但你当时听起来总像是在唱高调）。然而有很多人、很多时候不能分辨一个问题是自己的问题，还是团队的问题，因此也不能正确地决策其先后。这种情况下，我只建议你装得自己很闲，或者希望忙里偷闲，问问自己：“如果这件事不做，会如何？那件事不做，又会如何？”找出影响面最大的一件，交给别的人（或者大家）去做，而自己做“不是太重要”的那件事就可以了。
做事时固然要“先人后己”，面对成功与荣誉时也要“先人后己”。前者得以完成团队建设的重任，后者则表达你对团队价值的认可。
自相矛盾
“问题其实就是你期望的东西，和你体验的东西之间的差别。”
“要想解决问题，要么改变期望，要么改变体验。”
所以学会否定矛盾、消化矛盾，看到矛盾产生的内因、外因，转而借之用之，才是解脱的方法。
大道至简：软件工程实践者的思想 第六章 谁是解结的人
