罗伯特议事法

第1条：动议中心原则

动议是开会议事的基本单元。动议必须是具体的、明确的、可操作的行动建议。所讨论的问题是需要得到解决方案的。

第2条：主持中立原则

主持人的基本职责是遵照规则来裁判并执行程序，尽可能不发表自己的意见，也不能对别人的发言表示倾向。（主持人若要发言，必须先授权他人临时代行主持之责，直到当前动议表决结束。）

第3条 机会均等原则

任何人发言前须示意主持人，得到其允许后方可发言。对该议题未发言者第一优先，先举手者第二优先。同时，主持人应尽量让意见相反的双方轮流得到发言机会，以保持平衡。

第4条 立场明确原则

发言人应首先表明对当前待决动议的立场是赞成还是反对，然后说明理由。

第5条 发言完整原则

不能打断别人的发言。

第6条 面对主持原则

发言要面对主持人，不同意见者之间避免直接面对的发言，避免成为2个人的快速诘问和反问。同一时间只能有一个人发言，坚决反对大会当中开小会。

第7条 限时限次原则

每人每次发言的时间有限制 (比如约定不得超过2分钟）；每人对同一动议的发言次数也有限制（比如约定不得超过2次）；不必非要说服他人改变意见，只需把自己的观点表达清楚。发言内容不可以简单重复，如果简单重复说明同样内容，主持人有权终止发言。

第8条 一时一件原则

发言不得偏离当前待决的问题。只有在一个动议处理完毕后，才能引入或讨论另外一个动议。（主持人对跑题行为应予制止。）一旦一个议题被提出来以后，它就是当前唯一可以讨论的议题，必须先把它解决了，或者经表决同意把它先搁置了，然后才能提下一个提议。讨论问题不能跑题，主持人应该打断跑题发言。

第9条 遵守裁判原则

主持人应制止违反议事规则的行为，这类行为者应立即接受主持人的裁判。

第10条 文明表达原则

不得进行人身攻击、不得质疑他人动机、习惯或偏好，辩论应就事论事，以当前待决问题为限。

第11条 充分辩论原则

表决须在讨论充分展开之后方可进行。

第12条 多数裁决原则

（在简单多数通过的情况下）动议的通过要求“赞成方”的票数严格多于“反对方”的票数（平局即没通过）。弃权者不计入有效票。

《学习敏捷：构建高效团队》

假设你是一家公司的CEO，而你全心全意投入项目。假设现在项目团队开始有一些倦意，很明显他们需要咖啡。如果所有人都在忙一些无法脱身的事情，那么你会去给大家准备咖啡，这就是猪的状态。即使你是CEO，你也觉得给大家准备咖啡是对你时间最好的利用，因为这正是团队现在需要的东西。

很多经理都有一种疯狂的想法，那就是如果不压迫开发人员，开发人员就会尽可能地偷懒少干活，以及给自己设定很晚的截止时间。在大部分团队里，事实与此相反。在现实中，开发人员往往会过于乐观，因此我们都经历过项目延期的情况，但是很少见到项目提早交付的情况。

• 细节会后讨论 每日Scrum 例会的目标是定位问题，而不是解决问题。如果在一两分钟的讨论后无法 解决问题，那么请另外安排一个后续会议，自认与这个问题有关系的人可以参会。很多 这种后续会议的内容都关乎哪些人要负责哪些任务。这就是团队自组织的方式：大部分 任务都可以让大家自己给自己分配，但是有一些任务还需要讨论。只有通过每日Scrum 例会的“检查”环节才能认清哪些问题是可以自分配，还有哪些问题是需要讨论的。

• 轮流先行 没有谁充当进度的“守护者”，也没有人在项目中比别人重要。显然，有一些开发人员 的专业技能比其他开发人员更高超，但是任何一个人都可能有好的想法。如果团队中有 初级员工出了好主意，请不要因为他不是顶尖程序员而忽视他的想法。他可能会发现任 务安排中存在的严重问题，整个团队都需要处理这个问题。为了让每个人都能听取其他 人的好想法，每天的Scrum 例会可以由不同的人起头。

• 不要当作例行公事 我们每天都要开这些会（有些Scrum 团队甚至把例会称为“仪式”），所有人都需要参 加会议，并且参与每一个步骤。例会很容易将每个人都要回答的三个问题（从上一次例 会到现在我都干了些什么？到下一次例会前我要干什么？什么事情阻挡了我的进度？） 当作是例行公事，大家只顾着回答问题，而忘记了这么做的初衷。随着时间的推移，例 行公事会模糊掉工作实质，因为人们会慢慢产生敷衍行为。这三个问题是每日Scrum 例会的核心部分，因为团队每天都需要检查这些内容，这样才能尽早地发现问题。比如 说，要找到因为某个人要承担太多任务而导致的瓶颈的最有效方法，就是让每个人回答 关于阻碍进度的问题，因为第一个会被瓶颈阻碍进度的人肯定比其他人更早发现问题。

• 所有人都要参与 所有人包括测试工程师、业务分析师以及团队中其他所有人，产品所有者也算在里面。 所有人都要真正投入项目。产品所有者的工作非常重要，因为他要让所有人都知道积压工作表中有哪些任务对用户和公司来说最有价值，他要让所有人了解最新的状态。团队 对于自己要交付的价值越了解，他们就能越准确地满足用户的目标。产品所有者还要与 团队其他成员一起回答那三个问题，因为团队很容易忘记他在项目中也承担了重要的工 作，而他的答案可以帮助团队其他成员理解他的工作。（事实证明，与用户交谈，理解 用户的业务需求，以及管理积压工作表的确是需要全力投入的工作，如果开发人员能切 身了解这些，那么他们就能更尊重产品所有者的工作。）

• 不要开成最新状态汇报会 典型的状态汇报会是每周例行公事的一种典型。我们早已习惯了这种会议，所以很少想 到要质疑，甚至都不会多想。状态汇报会应该达成两个目的：一个是让团队里的每一位 成员都获得最新信息，另一个是让管理层获得最新信息。但是对于大多数团队来说，这 个会议只是一种单向沟通，即单个团队成员与项目经理之间的二人谈话。为了避免这种 状况，可以尝试确保每日Scrum 例会中的每个人都在认真倾听。（这意味着不能查看电 子邮件，不能玩手机，甚至不能做与工作相关的事情！）当团队成员开始把每日Scrum 例会看作提早发现问题，避免走错路浪费开发时间的方式时，大家就会觉得这个例会并 没有官僚主义色彩。他们会知道，这是一种以开发人员为中心的实践，可以帮助大家开 发出更好的代码。

• 检查每一项任务 寻找障碍的时候，不要只盯着手头正在做的事情，而要检查“待处理”栏中的每一个条 目，往后看几步，看看是否有存在问题的可能。如果发现了潜在的问题，最好现在就把 这个问题拎出来与团队一起讨论，把障碍消除，而不是默默地留着问题直到后面爆发。 这也是任务检查需要团队每个人都互相信任的原因。如果有人有意或无意地没有准确描 述他正在做以及计划做的事情，那么团队就可能会错过一个潜在的障碍，而这个障碍如 果没有及早移出，后面可能会导致更严重的问题。

• 计划需要则改变 这是“可见− 检查− 调整”周期中的“调整”部分，也是自组织团队的关键工作。团队 在每日Scrum 例会中发现了一个障碍，然后在后续会议中发现他们有一个错误的估算， 无法交付一项已经承诺的重要功能。那么继续坚持已经知道不可能实现的计划有意义 吗？当然没有。积压工作表和任务板必须反映项目的真实情况，如果发现了一个问题， 那么整个团队都必须共同修正积压工作表和任务板。这就是产品所有者作为猪的方便之 处，因为他可以立即开始调整其他人的预期。只要记住，不要管人们现在发现了计划的 变化之后会有多糟糕的反应。如果你现在不告诉他们，他们日后的反应会更糟糕，他们 迟早会发现的。

　理解极限编程价值观，拥抱变化

• 人性化
  牢记软件是人创造出来的，要平衡团队成员的需要与项目的需要。
• 经济因素
  软件的背后总是有人要掏腰包的，每个人都要考虑到预算问题。
• 共同利益
  寻找那些能够使得个人、团队和客户都能受益的实践。
• 自相似
  一个月度循环与一个周循环是一样的，与一个日循环也是一样的。
• 改进
  今天尽你的全力，同时要知道你明天怎么能够做得更好。
• 多样性
  大量持有不同意见和视角的人在一起工作，从而得出更好的解决方案。
• 反思
  优秀的团队会持续反思他们软件开发过程中哪些做法有效，哪些做法没有。
• 流畅
  不断地交付意味着连续的开发工作流程，而不是明晰的阶段性流程。
• 机会
  团队碰到的每一个问题都是学习关于软件开发的新东西的一个机会。
• 人员冗余
  即使乍看起来有点浪费，人员冗余确实能够避免大的质量问题。
• 失败
  你可以从失败中学到很多东西。应该允许失败的尝试。
• 质量
  降低质量标准并不能让你更快速地交付产品。
• 责任明确
  如果某个人对某件事负责，那么他应当有足够的权威来完成它。
• 慢慢来
  向着正确的方向缓步前进，在采用新的实践时，不要太过大刀阔斧。

两个重要的极限编程原则。

责任明确 一旦某一对程序员承接了一项任务，他们就应该全力投入把它完成。如果他们遇到问 题，就应该全力克服。但是他们也会向团队中的其他人寻求帮助，即使这么做可能会有 点挫伤他们的自尊。（由于大家彼此坐得都很近，最好是其他人无意中听到他们遇到了 麻烦，从而主动提供帮助。） 机会 每个新任务都是一个学习新东西的机会。如果某项技术有人不懂，学习该技术就成为了 任务的一部分。这有助于知识的分享，而且给未来提供了更多的机会。 这里还涉及另外一个概念：共同所有权。在前面提到的13 项极限编程的主要实践之外，

11 项衍生实践。

• 真正的客户参与 让客户参与到每季度和每周的计划会议中，并且真心倾听。
• 增量式部署 对系统的每一个小部分进行单独部署，而不是做大规模的一次性部署（同时，相信这种 增量式部署方法是可行的）。

• 团队的连续性 让那些高效率的团队始终在一起工作，不要拆散他们。 缩小团队规模 随着团队的不断进步，他们完成工作的速度会越来越快；这个时候不要给他们增加工作 量，而应该减少一个团队成员（让这个人把极限编程的文化带到其他团队中去）。

• 根本原因分析 出现问题的时候，找出问题所在，然后分析问题之所以产生的原因，并从根本上解决该 问题。
• 共享代码 开发团队应该只维护生产代码和测试代码；文档应该从代码库中自动生成，而项目历史 则通过口口相传的方式予以保存（因为即便有书面的项目计划，也很少有人去查阅）。
• 唯一的代码仓库 不要维护好几个不同版本的代码仓库。
• 每天部署 每天都将软件的一个新版本发布出去。

• 就合同范围进行谈判 作为一个咨询公司，不要把合同范围定死了，然后去就工期讨价还价（这样通常会导致为了按时完工而牺牲产品质量），相反，把工期先敲定，然后随着项目的推进逐步协商项目的范围。

• 按使用付费 这也是一个与咨询相关的实践，不要按开发工作量收费，按客户对系统的使用进行收 费；这样你会得到实时的、不间断的反馈，从而了解用户使用了哪些功能，哪些功能没 有用到。 我们在本书中不会太多讨论上述这些衍生实践，但这其中有一项有必要一提，那就是分 享代码。在一个极限编程团队中，跟项目相关的每个人（包括项目经理，只要他或她是 团队的一份子）都应该有权对代码的任何部分进行编辑修改。每个人都是所有代码的主 人，大家都有一种主人翁意识。这意味着如果一个团队成员发现了一个bug，他就会修 复它，即便这个bug 是别人引入进来的。这跟很多传统团队的做法很不一样，在那些团 队中，每个人只对他或她自己的那部分代码负责。 （我们还会深入讨论另外一项衍生实践：“根本原因分析”，以及“五个为什么”技巧， 这会帮助你在遇到问题时透过表面现象从根本上解决问题。我们会在第8 章中介绍这些 内容。） 打破所有权的藩篱，有助于让整个团队团结起来，因为当出现问题时，大家都感觉到自 己负有解决该问题的责任。因此，如果每个人都对代码有一种责任感，那么每个人也就 一样有能力解决队列中的每一项任务，或者至少有能力学习如何解决每一项任务。大家 会把学习的过程视为项目的一部分，值得他们花时间去做。

《ERP项目管理散记》

失败的六拍：

1. 拍脑门决策。
2. 拍肩膀信任。
3. 拍胸脯承诺。
4. 拍桌子骂娘。
5. 拍屁股走人。
6. 拍大腿后悔。

四种人不适合做项目经理 1、好好先生 管理者的日常工作有两类：管人和管事，越高阶的管理者，管人的比重越大 项目管理属于目标管理。好好先生是关系导向型领导，这种领导更多的精力用在下属之间的关系上。

2、先锋勇士 与好好先生对应的另一个极端。先锋勇士可能是因为业务水平过硬而被提拔的，这样的项目经理本质上不是管理者，绝大部分任务是靠项目经理亲自动手完成的。后果是其它成员非常迷茫且没有成就感

3、马虎大王 缺乏对项目整体的把握和规划

4、艺术大师 一方面追求新技术、高难度，另一方面追求完美

《逆向管理：先行动后思考》

提出一个问题：当我们越擅长一个领域时，花时间做其它事情的机会越少。因为做擅长的事回报更高，探索薄弱而有潜力的新领域回报不那么高。
这个现象是一个需要解决的问题吗？有些工种是这样，因为没有门槛，有些工种不是，因为规模报酬递增

你的关系网会有哪些问题？

• 物以类聚：你的联系人都和你很像
• 滞后：你的人际关系只停留在过去，没有面向未来
• 回音箱：你的人际关系都是内部成员，大家彼此认识
• 鸽笼：你的联系人认为你没有能力做其它事。