中啊！与其要求团队成员加班加点，还不如提高会议效率。我很认同Scrum对于会议时间的明确规定。例如Sprint的计划会议保持在4个小时，而评审会议和回顾会议则保持在2个小时左右。至于Scrum的每日例会，更是短小精悍，只有15分钟。是谁发明了“站立会议”这个名词呢？发明者完全就是一位天才！改传统的枯坐会议为站立会议，就可以收住那些夸夸其谈、口若悬河的家伙了。在我的一个团队里，就有这样一个家伙，总是啰里啰唆，讲了半天也说不到重点。我每次看到他要发言，我就有头晕的感觉，甚至有一种冲动，想用胶布封住他的嘴。不过，在我主持会议的时候，我常常发现会议成员看我的眼神，有几分熟悉。会议之后仔细思考，发现他们看我的眼神，和我看那个家伙的眼神竟然惊人的一致！Larry L. Constantine在《人件集》的“因地制宜”篇中写道：“如果想要团队工作获得最大成功，会议的主持人和记录者都应该以局外人的身份参加讨论会。……作为整个团队的最高负责人，项目领导者应该积极参与团队中的讨论和工作，而不是对工作指手画脚。……会议应该是在一种中立的气氛下进行。……另一方面，……陷入无休止的争论中，这时候，最好由项目领导出面中止争论，暂时地放开当前的话题，或者很偶尔的，如果话题已经进入了死锁状态，那么就由领导做出一个仲裁。”
4、合理安排人手。
通常在我们面临最后期限的压力时，第一想到的是加班，然后闪入脑海中的念头则是增加人手。加班策略素来为我所唾弃。以每人每日的生产效率来看，虽然加班可以延长工作时间，但长期的过度疲劳必然会降低生产效率，如此以时间换来低下的效率与团队成员的抱怨，完全得不偿失。在长期积怨的情况之下，开发人员会产生一种破罐子破摔的思想，心里认为反正都要加班，那么在正常上班情况下，反而会“磨洋工”，敷衍搪塞项目经理安排的工作。那么增加人手呢？且不说这会增加项目成本，我们还要考虑团队的新兵需要多长时间才能上战场？业务培训、团队磨合是新增成员必然存在的两大痼疾。如果没有处理好这两个问题，不仅不能提高开发进度，反而会有拖慢或者打乱原有开发节奏的危险。另外，如果添加的新手不幸是一个刺头或者“害群之马” 呢？需要明确的是，往往在项目经理提出增加人手的情况下，项目经理并没有亲自挑选新成员的权利。这些新成员要么是闲置的，要么是其他团队转过来的，要么是新招聘的。考虑前面两种情况，你觉得这样的成员能够达到及格乃至于优秀的几率会有多大呢？如果是新招聘的，那么拜托，赶快在心里多念几遍“菩萨保佑”吧。总体而言，如果项目经理没有挑选新成员的权利，最佳的选择是非到万不得已不要添加成员。所谓“万不得已”，即是无论如何改进，如何协商，如何提高效率，都无法达成既定目标的情况。
兵贵在精而不在于多。关键在于知人善用，以及合理调度。一个项目经理在组建自己的团队时，必须要了解自己成员的人格特点与技术特点。在理想状态下，如果项目经理具有挑选成员的权利，会具有更大的成功率。如果项目过大，那么必须建立层级式的组织架构，而在划分出的各个小组中，却应该以扁平的平等架构为最佳。这样就能够自由而不失于集中，平等而又不至于缺乏效力。当然，具体的组织架构应依据企业文化、产品性质、开发规模、团队成员特点等各个因素综合考虑，不能死搬硬套。在安排人手时，要注意对技能型人才和管理型人才的使用，注意对领域专家和系统架构师的使用，注意对开发人员和测试人员的使用，注意对编档人员、QA、配置管理员的使用。此外，还需要养成从容不迫的心理，即使最终期限火烧眉毛，迫在眉睫，仍然要保证对架构的设计、对编码的测试以及合理考虑产品性