解开最后期限的镣铐
4、合理安排人手。通常在我们面临最后期限的压力时，第一想到的是加班，然后闪入脑海中的念头则是增加人手。加班策略素来为我所唾弃。以每人每日的生产效率来看，虽然加班可以延长工作时间，但长期的过度疲劳必然会降低生产效率，如此以时间换来低下的效率与团队成员的抱怨，完全得不偿失。在长期积怨的情况之下，开发人员会产生一种破罐子破摔的思想，心里认为反正都要加班，那么在正常上班情况下，反而会“磨洋工”，敷衍搪塞项目经理安排的工作。那么增加人手呢？且不说这会增加项目成本，我们还要考虑团队的新兵需要多长时间才能上战场？业务培训、团队磨合是新增成员必然存在的两大痼疾。如果没有处理好这两个问题，不仅不能提高开发进度，反而会有拖慢或者打乱原有开发节奏的危险。另外，如果添加的新手不幸是一个刺头或者“害群之马” 呢？需要明确的是，往往在项目经理提出增加人手的情况下，项目经理并没有亲自挑选新成员的权利。这些新成员要么是闲置的，要么是其他团队转过来的，要么是新招聘的。考虑前面两种情况，你觉得这样的成员能够达到及格乃至于优秀的几率会有多大呢？如果是新招聘的，那么拜托，赶快在心里多念几遍“菩萨保佑”吧。总体而言，如果项目经理没有挑选新成员的权利，最佳的选择是非到万不得已不要添加成员。所谓“万不得已”，即是无论如何改进，如何协商，如何提高效率，都无法达成既定目标的情况。
兵贵在精而不在于多。关键在于知人善用，以及合理调度。一个项目经理在组建自己的团队时，必须要了解自己成员的人格特点与技术特点。在理想状态下，如果项目经理具有挑选成员的权利，会具有更大的成功率。如果项目过大，那么必须建立层级式的组织架构，而在划分出的各个小组中，却应该以扁平的平等架构为最佳。这样就能够自由而不失于集中，平等而又不至于缺乏效力。当然，具体的组织架构应依据企业文化、产品性质、开发规模、团队成员特点等各个因素综合考虑，不能死搬硬套。在安排人手时，要注意对技能型人才和管理型人才的使用，注意对领域专家和系统架构师的使用，注意对开发人员和测试人员的使用，注意对编档人员、QA、配置管理员的使用。此外，还需要养成从容不迫的心理，即使最终期限火烧眉毛，迫在眉睫，仍然要保证对架构的设计、对编码的测试以及合理考虑产品性能、可用性和产品质量。
5、开发环境的保护与基础设施的维护。兵家云：天时、地利、人和。没有一个好的开发环境，很难想象开发人员能够高效率的工作。开发环境必须是相对独立，又利于交流与沟通的工作室。具体的说，项目组的工作环境必须拒绝项目无关人员的干扰与破坏，但却无阻于项目成员，特别是同一小组成员的交流。此外，会议室的数量非常重要。我在管理一个项目时，竟然常常为寻找会议室而东奔西走，将大量的时间浪费在会议准备上。此外，服务器、客户机、网络、打印机、白板、卡片，以及开发工具和软件，例如IDE开发环境、版本控制工具、Bug管理工具等，都需要在团队建立之初就要准备好。对于计算机、网络和相关工具，则必须保证在项目开发期间的稳定性、畅通性。我曾经在项目开发中，因为网络中断、病毒侵袭以及服务器坏掉从而破坏了SVN的版本管理等诸多突发事件，让我在本来就紧张的开发时间里，牺牲了不低于三天的时间，真是让我抓狂不已！所以说，一个好的网络管理中心、一个好的配置管理员，在关键时刻，可以抵得上半打高效的开发人员呢。如果你在项目开发过程中，频繁遭遇这样的问题，我的忠告是，赶紧准备换一家公司吧。
6、合理控制需求变更。需求变更是软件开发必然遭遇的暴风雪，也是导致“没有银弹”的渊薮。传统的瀑布开发模型在项目后期遭遇需求变更时，只能束手无策，但RUP与敏捷方法却能够坦然面对需求的变更，Kent Beck甚至在敏捷开发中提出了拥抱变化，真是足够勇敢与足够信心的宣言啊！在软件开发中，若要应对软件开发，一般的做法是合理设计，以求系统与架构具有足够的可扩展性；其次则是采用迭代的开发方式，通过定期甚至是短周期地交付可工作的产品，以印证需求与实现是否一致。同时，在项目中通过引入客户的积极参与，使得项目组与客户的交流能够畅通无阻，从而避免因为隔阂而导致需求分析产生的误差，以及需求变更无法及时提出。此外，利用原型快速开发方式，可以尽快地交付一个无具体实现的产品框架或原型，以验证业务规则、业务流程以及客户对GUI的要求。然而，需求变更绝对不能无休止地进行，这会导致迭代的永无眠日。即使是敏捷开发，我们仍然要设定客户委托事项的基本线，一旦超出这一基本线，变更委员会（CCB）或其他担负这一职责的角色就必须提出异议，与客户协商或探讨这种变更是否是必须的。控制需求变更的一个实践是，获得客户对分析出来的功能点的书面确认。虽然在发生变更时，客户的意见甚至可以无视这种书面文章，但至少可以在与客户的谈判中抢得先机。根据Mark Lines所说，通过变更控制的增强还可以降低项目风险。确实如此，在与客户谈判中，我们要学会说出“拒绝”两个字。当然，在对需求变更做出决定性意见之前，必须分析判断这样的变更是否合理，是否必要，或者优先级高。一种折中的办法则是，欣然承诺此次变更，但需要延迟最后期限，或者放在下一次版本迭代之后。
