论给延期项目加人的正确姿势
软件工程领域有一句来自人月神话的至理名言：“给延迟的项目中添加人手，往往只能使项目更加延迟”。道理也是显而易见的，当预见到项目要延期的时候，一般来说已经是执行阶段的中后期了，当然，要排除一开始就预见到资源不够，有延期风险，但是又没有足够的人力资源可以协调的情况。此时，给项目添加人手，最直接的影响就是增加了相当大的沟通成本，新成员需要融入当前的团队文化、重新熟悉项目、了解项目、可能还需要一定的技术培训，当人手添加到一定数目之后，会使项目进度变慢，因为浪费在信息交流上的成本很可能远远大于实际的执行成本。举个例子，一件事情，让一个熟手可能需要半个小时，但是如果让这个熟手教这个新手大概花20分钟，新手自己做大概又需要40分钟，这样下来，总共需要1个小时才能完成原本只需要半小时就能完成的事情。关于沟通交流成本，也是有理论依据的，把项目中的每个人看做一个借点的话，所有节点组成一个完全连通图，图中的边也就是人与人之间的沟通。在有n个人的项目中，就会有（n^2-n）/2条边！
但是，在互联网行业，时间有的时候就是一个团队甚至一个公司的绳命呀，唯快不破，宁愿给更多的资源也别给延期呀，实在是空间换时间的表率呀！话说，互联网也是个神一样的存在，神通广大，无所不能，有互联网在，大门不迈，二门不出的，这生活照样可以过的倍儿滋润，再说回来，那咱互联网界的兄弟姐妹们也得神通广大不是呗，延期这种事情，那自然也得搞的定！补充说明，这里不考虑因为项目范围变更导致的延期。这种情况，一般可以争取到一些额外的时间资源，潜在的延期也很可能在各个干系人的预料之中。
姿势一：心态很重要，坦诚开放、互相信任。无论是对原班人马，还是对后加入的“新人”来说，这点都很重要。程序员最忌讳的就是“文人相轻”，你看不起我写的代码，我还瞧不起你的小智商，然后呢，一出bug的时候，即使嘴上不说，暗地里也互相推卸责任，不是我改出来的问题，我才懒得管，誰叫你瞎捣腾我的代码，如果发生这种情况，PM就该哭了，项目不但得延期，还会闹得大家不欢而散。所以说，还是毛主席懂的人心，神马枪杆子里出政权，都没有思想教育工作来的更实在，不但是我党打江山平天下的基础，更是我党守江山的镇山法宝。先做好大家的思想工作，达成统一战线，这后面的事儿自然也就好开展了。
姿势二：就近般救兵。这个就近不但包括地理位置近，还包括文化“近”，技术能力“近”，好吧，说人话！具体说来就是，能在公司内找合适的人，就别去找外包；部门内能协调过来的就别去上一级组织要人；需要做前台开发的，就别拉个后台过来等待，诸如此类。道理也是显而易见的，相同的文化，相同的技术背景，臭味相投，沟通更方便，也好干事儿。
姿势三：分而治之。当有更多人加入到项目中来的时候，还真不适合C/S架构的集中管理模式，P2SP我认为更好。多啰嗦两句，C/S模式在这里指一个人管一堆人，除了项目经理或者技术leader外，下面的人都是在一个“平面”上的。P2SP是P2P网络的一个变种，在这里SP指一个能力更强的人，这样，可以将原本在一个“平面”的人根据技术能力或者管理能力的不同，再进行区别对待，能力强的人，带几个人形成一个小团体。小团体内部高度集中，尽量减少团体之间的沟通，有点儿类似我们在做软件设计时说的，模块化和低耦合。这样一来，人员在物理层的划分就可以直接映射到软件的逻辑区分上，不同的小团体尽可能负责独立的模块，模块之间只需要接口通讯即可，SP也就是各个小团体中的主要负责人。
姿势四：代码走查。既然项目中间随时都可能因为需要添加新的人手，何不让代码走查成为一个习惯。尤其是核心模块的代码，以及“新人”提交的代码，虽然我们提倡互相信任，但是预防错误和疏漏也是必须的。
姿势五：“核心”一定要是稳定的。不管是核心的代码还是核心的人。如果没有特殊情况，核心模块的代码还是继续让原班人马打造。其中的道理也是显而易见的，不得不承认的是，原班人马在原始知识积累（包括：软件结构设计的考虑、技术要求、业务要求等）方面比“新人”更胜一筹。而且，核心模块一般而言，也是由团队里能力最强的那些人在担当，如果不放心他们，还能放心誰？
姿势六：这个必须是大招 —— 重新规划。还有些时候，我们即使想了各种法子来避免延期，但是还是难逃厄运，发生这种情况的原因，大多时候是因为团队一开始的估计过于乐观，这时候，项目经理不防重新审视下眼前的现状，承认失误，厚着脸皮争取更多的时间资源，好让计划更靠谱些。
姿势七：这个必须是大招中的大招 —— 项目经理要修身，最好牛掰到接手的任何项目压根儿就不延期！
当然，项目的实际情况往往比我们这里谈的要复杂的多，多变的产品需求、挑剔的视觉审美、还有不靠谱的第三方等等，总有这样或那样的因素干扰着项目一开始的规划，项目经理该有这样的思想准备：跟计划完全一致的项目不一定会成就好的结果。产品是在探索中前进，项目又何尝不是在前进中探索呢。