概述
在今年的一月份，公司出了個新戰略，想做一箇中心平臺，以品牌旗艦店的方式，爲品牌商塑造名氣。原有公司的技術平臺不太支持這個模式的，如果要做的話，工作量將非常大。大老闆非常看重這個項目，希望儘快啓動，一個半月完工上線。像這樣的大項目，在時間短的情況下，要順利完成任務，是非常困難的，稍微處理不好，分分鐘項目會以失敗告終。還好在一幫好兄弟的協助下，項目順利上線。我是這個項目的技術主導者，下面簡單說一下，遇到緊急大項目的一些處理手法。
技術架構和評審
無論項目開發週期多短，架構設計和評審絕對不能馬虎，這一步做的不好，項目將會以失敗告終。因此，團隊的技術負責人，一定有這個意識，要能頂住所有壓力，儘量爭取多一些時間進行架構設計。像當時我們這個項目，光是技術架構設計就討論了三次，只要沒定下來，就不會開工。尤其是在原有技術平臺上實現一個新模式的時候，就更加要多多討論。
任務拆解
當架構設計定向來後，第一件事情，就是任務拆解，方便指定到人和評估具體的工作量。拆解這件事情，難度非常高的，得考慮如下幾個因素：
- 任務優先級，哪些是高優先級的，必須優先做。比如說，後臺的管理界面是用於造業務數據的，因此界面以及對應的後臺管理API就必須優先完成，不然的話，面對用戶的C端接口，就不太好測試，得自己造數據了。如果不考慮好優先級這個因素，開發節奏就絕對會亂掉，變得非常不可控；
- 任務的大小粒度，任務不能拆解的太大，一個任務如果需要五天完成，就不太可控，一般建議最大不要超過3天，以小任務的方式，逐漸提交給測試人員測試。
- 任務的通用性，一定要事先分析出哪些任務是比較通用的，以任務的形式列出來，優先完成，代碼抽取到一個地方，這樣就不至於非常類似的功能，各個同事都用不同的代碼實現了一套，非常不易於維護，且也浪費了人力和時間。
項目整體排期
當後端開發切分好任務後，第一件事，就是拉上PMO和測試人員，大家一起討論項目整體排期是否合理。後端開發千萬要注意，任務提測後，是需要測試人員去測試的，他們也需要時間的，可能是一個星期或者兩個星期。假設項目是2019年4月14日上線，那麼就不能有開發任務在最後幾天才提測，不然測試人員的壓力就非常大，上線的風險也非常大。
因此必須按照上面提到的任務優先級的理念，梳理出哪些任務可以優先提測，儘快讓測試人員在早期就有可以測試的功能點了，儘早的介入進來，保證節奏，降低風險。
分配任務，指定到人
對於那些難度高又重要的任務，儘量讓資深人員來做，最重要的原因是，讓厲害的人來做，技術組長可以不用怎麼操心，能有部分精力去應付除了代碼開發之外的其他東西，像進度、風險、彙報、溝通等等問題，一般來說，技術組長，只有百分六十的時間是用於代碼開發的。
如果你分配出去的任務，自己也不太清楚，這個時候，你只能相信組內的同事了，直接分配給他，讓其自行搞定，中間遇到問題的，你再幫忙一起解決。
每隔兩天，開進度對齊會
一個任務要能真正提測，是要多方都完成纔可以的。比如說，某個後臺界面管理功能，是需要後端UI和後端API都完成了，才能提測的。這裏就涉及到前後端了，因此很有必要定時跟進一下進度，看看是否有哪方進度落後了，有風險了。及時的進行調整。這個間隔時間，我建議是兩天，每天對則太頻繁了。
主流程功能儘量全的做迴歸測試
緊急項目，測試人員更加要重視迴歸測試，因爲在進度緊張的情況下，開發人員可能改壞了以前的代碼。因此，測試人員需要給出迴歸的Test Case，然後與開發人員溝通，看看是否有漏掉的場景，儘量將重要的主流程場景全部迴歸一次。這樣的話，項目一上線，就算有問題，也不是大問題，可以臨時fix bug或者在下個迭代進行修復。
再次強調一下，這一步實在太重要了，尤其是緊急大項目。
小結
網友也可以幫忙補充一下，上面只是我想到的幾個點。