概述
在今年的一月份，公司出了个新战略，想做一个中心平台，以品牌旗舰店的方式，为品牌商塑造名气。原有公司的技术平台不太支持这个模式的，如果要做的话，工作量将非常大。大老板非常看重这个项目，希望尽快启动，一个半月完工上线。像这样的大项目，在时间短的情况下，要顺利完成任务，是非常困难的，稍微处理不好，分分钟项目会以失败告终。还好在一帮好兄弟的协助下，项目顺利上线。我是完整参与过这个项目的，下面简单说一下，遇到紧急大项目的一些处理手法。
技术架构和评审
无论项目开发周期多短，架构设计和评审绝对不能马虎，这一步做的不好，项目将会以失败告终。因此，团队的技术负责人，一定有这个意识，要能顶住所有压力，尽量争取多一些时间进行架构设计。像当时我们这个项目，光是技术架构设计就讨论了三次，只要没定下来，就不会开工。尤其是在原有技术平台上实现一个新模式的时候，就更加要多多讨论。
任务拆解
当架构设计定向来后，第一件事情，就是任务拆解，方便指定到人和评估具体的工作量。拆解这件事情，难度非常高的，得考虑如下几个因素：
- 任务优先级，哪些是高优先级的，必须优先做。比如说，后台的管理界面是用于造业务数据的，因此界面以及对应的后台管理API就必须优先完成，不然的话，面对用户的C端接口，就不太好测试，得自己造数据了。如果不考虑好优先级这个因素，开发节奏就绝对会乱掉，变得非常不可控；
- 任务的大小粒度，任务不能拆解的太大，一个任务如果需要五天完成，就不太可控，一般建议最大不要超过3天，以小任务的方式，逐渐提交给测试人员测试。
- 任务的通用性，一定要事先分析出哪些任务是比较通用的，以任务的形式列出来，优先完成，代码抽取到一个地方，这样就不至于非常类似的功能，各个同事都用不同的代码实现了一套，非常不易于维护，且也浪费了人力和时间。
项目整体排期
当后端开发切分好任务后，第一件事，就是拉上PMO和测试人员，大家一起讨论项目整体排期是否合理。后端开发千万要注意，任务提测后，是需要测试人员去测试的，他们也需要时间的，可能是一个星期或者两个星期。假设项目是2019年4月14日上线，那么就不能有开发任务在最后几天才提测，不然测试人员的压力就非常大，上线的风险也非常大。
因此必须按照上面提到的任务优先级的理念，梳理出哪些任务可以优先提测，尽快让测试人员在早期就有可以测试的功能点了，尽早的介入进来，保证节奏，降低风险。
分配任务，指定到人
对于那些难度高又重要的任务，尽量让资深人员来做，最重要的原因是，让厉害的人来做，技术组长可以不用怎么操心，能有部分精力去应付除了代码开发之外的其他东西，像进度、风险、汇报、沟通等等问题，一般来说，技术组长，只有百分六十的时间是用于代码开发的。
如果你分配出去的任务，自己也不太清楚，这个时候，你只能相信组内的同事了，直接分配给他，让其自行搞定，中间遇到问题的，你再帮忙一起解决。
每隔两天，开进度对齐会
一个任务要能真正提测，是要多方都完成才可以的。比如说，某个后台界面管理功能，是需要后端UI和后端API都完成了，才能提测的。这里就涉及到前后端了，因此很有必要定时跟进一下进度，看看是否有哪方进度落后了，有风险了。及时的进行调整。这个间隔时间，我建议是两天，每天对则太频繁了。
主流程功能尽量全的做回归测试
紧急项目，测试人员更加要重视回归测试，因为在进度紧张的情况下，开发人员可能改坏了以前的代码。因此，测试人员需要给出回归的Test Case，然后与开发人员沟通，看看是否有漏掉的场景，尽量将重要的主流程场景全部回归一次。这样的话，项目一上线，就算有问题，也不是大问题，可以临时fix bug或者在下个迭代进行修复。
再次强调一下，这一步实在太重要了，尤其是紧急大项目。
小结
如果你是技术组长，就不能只是管技术，技术牛B就行，还需要懂得一些项目管理的知识，才能应付类似这种紧急大项目。网友也可以帮忙补充一下，上面只是我想到的几个点。