微软团队成功秘诀

）赋予责任（Accountability） 我认为软件开发问题中最有趣的就是赋予责任这个主题。我们讨论过的题目是：
  “你负责什么？”我的理论是，大多数人的思考都没有好 好利用到，因为人们并不把提出新想法当成自己的责任之 一（请参考法则4：别做笨蛋）。
  首先，人们可能认为：“这不是我的责任范围”，因此 少管闲事，不提任何有建设性的提议。如此一来会有很多 不良的后果，尤其是当事情没有用语言沟通，会引起许多 误解、猜忌、行动力的相互抵销，而最后只有用行动来抗议了。
  只要单纯地请对方表示看法，这样的姿态很容易解除对方的心理防线。
  其次，如果建议的来源真的说出了他的想法（可能要 冒很大的风险），被建议的对象很可能产生防卫心理（又 不是你的事情，管什么管嘛！），导致争端。有时候，防 卫心理是非常隐讳的，特别是当这个组织的文化将防卫心 理视为缺点时。讽刺的是，愈是成熟的团队或个人，愈会 执着于现有的优良管理制度，愈会提出各种反驳的理由来证明现有的做法才是最好的，不需要什么建议。
  第三，除非建议者克服自己的攻击心理，否则这个 建议可能永远到不了对方的心中。就像防卫心理是普遍 存在一样，攻击心理亦然。通常提出建议的人都有某种 攻击性或包含价值判断的态度，这也是绝大多数的人都 有的弱点，而受到批评的人会感觉到威胁而更强烈反弹， 于是提出建议的人立刻下结论：这人是个笨蛋，沟通的 大门立刻关上。
  有很多建设性的想法就此消失。我所想到惟一的解决 办法，就是所谓的研讨会（ workshop）。在研讨会中人们 主动上前邀请同事提出批评指教，这样单纯的提出、接受、 反馈的循环中，每个人都会受到批评、提出建议，这是比 较容易让人卸除心理武装的气氛，比较容易对事不对人， 如此单纯的信息传达让每一个人都轻松接受建议而愿意改 善。令我惊讶的是，由于研讨会的练习使得组员熟悉沟通 技巧，最后反而不需要经常开研讨会了。
  我有过多次运用研讨会的方式解决软件开发问题的经 验。方法像是个案研究（ case study），由一位志愿的组员 主持；这个案例当然是现在发生的真实情况，通常是关于 组内的人际关系，主持人先描述案例的大致情况，有时故意不说明当事人的名字，比方说：
  ──我实在无法接受这种想法。
  ──没有人看我的电子邮件（指建议）。
  ──某人根本没有把心放在项目上。 然后其他的人开始讨论，询问主持人关于此案更详细的信息，并理清一些盲点，或是询问主持人尝试过那些方 式，之类的问题。最后事情会在讨论中澄清，问题也就差 不多解决了。
  前述的两种简单方法会产生两项很重要的结果（从来 没有让我失望过），其一是这样的讨论会造成非常多的新 点子伴随而生：你会看见主持人不断地说：“这个想法太 棒了！”然后当场记在笔记本上；其二是这种案例研讨的 结论通常可以应用在其他类似的情况，人们会发现，这就 是我上个月讨论过的某案嘛！当类似的过去案例累积到相 当的数量，人们就会发现本案也不是什么特例，然后就会 发现处理这类事情的通则，把它记在笔记本上作为日后的 参考。
  在横向的特色监督小组中，一个人的成功或失败是完全透明的。
  “赋予责任”有很大的好处，很少有应用上的限制。 如果一个组织健全的团队成员，对于整个任务的过程─ 设计、开发、除错、品质、期限 ─彼此都负有责任，就 会自然地互相给予建议和建设性的批评，而且用正面的态 度接受。因为每个人都有相同的责任。一旦建立团队的责 任感，这种对责任的认知会分享、传递到团队中的每一个 份子。
  融入任务（Identity） 充分的授权和责任感，使人具有控制权和影响力，愈能使自己与任务融为一体。控制权 愈大，融为一体的一致性愈高。这种融为一体的一致性是 开发任何好软件的先决条件，它会将个人的心理状态健全 与否，表现在软件作品中。譬如说，有一个人心中有挫败 感或是自我毁灭的倾向，就会在他所负责的软件功能中表 现出来。
  在横向的特色监督小组中，每个人会将产品当作他的任务，而非狭隘的技术而已。没有什么人可以推诿塞责，一个人的成功或失败是完全赤裸而透明的。你不能责怪管 理不良，因为你自己就是管理者，你不能责怪其他的功能 支持人员没有好好配合你的产品特色，因为你们是相互负 责。因此，你有责任自己找到答案，你有责任克服自己的 障碍。
  建立共识（Consensus） 共识是特色监督小组的气氛。因为大家聚在一起的原因是“产品特色”而非功能， 由于责任是互相的，敞开心胸是安全也是必要的。我见过 有些特色监督小组自动地重新组织他们的关系，建立共同 目标、重新规划资源、适度修改日程，而没有发生严重冲 突。即使有冲突，由于不是对人的或是出于私心，通常都 很容易解决，不需要主管以职权介入。
  地位平等（Balance） 由于特色监督小组的每一位成员都是不同的背景、专长，不同的工作角色和不同的观念， 没有谁比谁优越的情形，所以每个人的地位都是平等的。 通常人们对于不属于自己专业的领域，反而会有一些全新 的看法，刺激彼此打破过去的观念限制或盲点，激发更好 的创意。由于各人的意见来自不同的着眼点，就可以使产 品的开发顾全更广的层面，而更周全、完美。不同角色的人会关心不同的问题：
  项目经理：团队目前的状况如何？开发过程顺利吗？ 领导是否有效而得宜？我们走到开发周期的哪个阶段？进 度是否控制得当？需要别部门协助的地方是否已经取得支 持？我们的目标明确吗？还有什么尚未完成的工作？本周 的工作主题是什么？
  品保人员：我能不能依照预定的时间自开发人员手中 取得阶段性程序代码？程序有什么样的错虫出现？这些错 虫对付得如何？有什么功能尚未开发出来？程序的执行效 能如何？本周的产品状况是否合格，需要对谁提出警告 吗？项目经理知不知道程序的稳定程度？我们团队的沟通 如何？是不是每一个人对产品状况都有相同的认知？本周 合理的短期目标应该是什么？
  开发人员：本周我能不能完成预定的工作进度，将阶 段性程序代码交给品保人员和文件人员？这一段程序代码 写得够好吗？使用者需不需要这个功能？这个程序容易使 用吗？程序是否执行够快体积够轻巧？我清除了所有的错 虫吗？有没有人因为在等待我的工作进度而耽误进度？我 是否完全了解本周的短期目标？我的工作是否符合策略上 的方向？而且工作内涵对技术规划有无贡献，或只是个早晚会被丢掉的垃圾？
  产品经理／行销：产品特色是否吸引顾客（包括潜在 顾客）？我该如何生动地表达这个产品的特色？它能否牵 动顾客心中的心理或情感反应？我们应该如何修改产品， 才能加强顾客的购买欲？当顾客听到我们的产品时心里会 有什么样的反应？顾客在什么时候会使用这个产品？产品 特色是否能加强我们与顾客之间的关系？媒体是如何报导 我们的产品？开发这项产品特色背后的动机是什么？我是 否完全了解产品特色及其重要性？准时完成的可能性有多 大？我是否应该向公司说明产品的不确定性有多高（或是 非常确定）？产品成功推出的机会点在哪里？
  技术文件／教育训练：这项功能是否以更容易的方式 使用？我对它的说明够清楚吗？使用者接口能不能设计到 不必学就能操作？如果我现在还没有完成文件，会不会太 迟？这项产品特色是否已经通过品保人员的核准？我对这 项产品特色有什么感觉？我能不能用更简洁的方式来说 明？其他的组员认同我写出来的文件吗？
  虽然特色监督小组是非常的重要，但要成功地组织起 来可不是件容易的事。在传统的阶层式组织中加入横向的 特色监督小组是非常困难的转变，这种转变上的困难可能来自团队的内部或外部。
  在特色监督小组的内部，本身就会面对相当大的不确 定性，大家不知道自主权的范畴是什么，只知道我们是一 组人，应该在一起做事，但不确定的该用什么样管理方式。 特色监督小组的本意是突破传统角色的藩篱，但是组员却 会很自然地以原来的传统角色来为自己的定位，如此特色 监督小组的作用就会明显受限。开发人员常常会主导小组 的运作，导致使其他的功能不容易发挥。如此一来，特色 监督小组的横向组织功能大概只能改善沟通，这似乎与它 的高成本（组织小组、召集开会、物色人选、行政作业等 等）完全不成比例。
  在很多人的心中,所谓的团队只不过是虚伪矫情的共识和假装一团和气罢了。
  而且，人们总是要等到问题已经很严重时，才会成立 特色监督小组。如果这个时候管理阶层放手让他们自行决 定命运，组员反而会有被抛弃的沮丧感。