來TID做重構兩年多了，眼看著團隊像自己一樣，從無序到有序，從青澀到成熟，一步步成長起來。從最初的每次例會上輪流抱怨需求變更、需求插單，到現在井然有序的需求排期、專案郵件，這其中的蛻變，看似簡單，實則十分不易。前不久支援“XXX”專案時，看到上游的小夥伴們還在混亂中摸爬滾打，故寫下此文，希望對這方面有需求的同學有所幫助，也希望這方面有想法的前輩、同學指導、探討。
開始之前，有幾點需要特別宣告下：
- 此處所說的“專案管理”並非專業的專案管理（所以我打了個引號），專案管理這碗水太深，並未做過甚至都沒看過別人做的我不敢在這兒評頭論足。這裡只是作為重構，作為專案的一個環節，對所遇到的問題及解決方法的一點淺見。
- 我所謂的解決方法，主要是團隊leader鬼哥和bboy90的思想和方法，我只是從執行者層面表達一下自己的看法和認識。
- 每個團隊的情況都不一樣，遇到的問題和適用的方法也不一樣。這裡的團隊背景是，需求（包括日常優化需求和專案）由產品經理來規劃並跟進實施，對效果負責，也就是說，產品經理是需求的主導者。支援需求的各方資源，如互動、視覺、重構、前端、後臺等都是公共資源，並不100%跟某個專案，而是在自己負責的產品線內，哪裡有需要，哪裡就現身影，也就是說，每個環節的資源（如重構）和產品經理之間是一對多或者多對多的關係。
好了，說這麼多，開始進入正題了。問題大概是這樣的，支援“XXX”專案時，頻頻收到來自上游的變更，與其溝通後發現他們也是深受其害而不知如何應對。下面是大概的溝通內容：
重構：親，互動不是已經定稿了嗎？怎麼還在持續更新啊？
互動：沒辦法啊，之前開會提到過幾個問題，產品方案做了點變更，互動也要重新設計下呀。
重構：為什麼不讓產品提個需求變更呢？這樣你可以集中處理，也方便排期，對下游的影響也小一點。
互動：開會一起討論過的，不用產品提變更了吧？
重構：那你其他需求不會受影響嗎？
互動：會！有個“YYY”的專案，本來幾天前就該啟動的，這幾天一直在優化我們這個，那個專案已經推遲4天了。領導一定覺得很奇怪，你這個專案不是已經結束了嗎，怎麼還在做。我也很無奈啊。。
……
重構：你最近很忙吧？除了我們的“XXX”專案，聽說還在支援其他幾個需求。
視覺：是啊。
重構：那你是在並行處理嗎？應付地過來嗎？
視覺：是啊，沒辦法，一起給過來了，都很急，只能自己撐著了。
……
這樣的情況比比皆是，尤其是在新人中。因為大多數同學會有一個誤區，覺得自己是來幹活兒的，如果活兒來了自己反饋數量太多應付不來，會讓人覺得工作態度不積極，或者能力有問題。所以都會先攬下，然後，要麼很幸運的，有個專案卡在了上游環節，就可以理直氣壯地說那啥啥稿還沒提供過來；要麼自己拼死拼活加班趕；要麼忽悠產品經理，評估多點時間；要麼誰催得緊先做誰的，催得鬆的就往後延唄，反正一般也不會投訴的。據我感覺，最後一種情況最多，第一種次之。羊毛出在羊身上，大家都是人，不是神，沒有三頭六臂，工作多的時候也不過在一定程度內提高點效率而已，不可能同樣時間內有多少就能解決多少的。大家都明白這個道理，但大家都不敢把它放到檯面上來講，就像皇帝的新裝一樣，於是大多數人就這麼糊里糊塗地躲過了一劫又一劫。通常，陷入這種境況時，除了手忙腳亂，還會很苦惱。明明自己很辛苦，明明自己已經盡力了，明明自己的工作能力也不差，卻總是心虛的，怕這個催那個問。放在前面支援的，產品也不過是道聲辛苦，放在後面支援的，產品雖也表示理解，但難免有不滿的情緒。這種時候，也唯有祈禱上游提供得晚一點，或者會議、插單的事情少一點。
其實，這個問題並非沒法破，只是對於新人或者資歷尚不是很深的底層員工來說太難了。因為他們不夠自信，他們知道自己的工作質量、效率都不是一流的，他們知道自己還有很大的提升空間，如果把問題丟擲來，那就意味著要被挑戰。這也是為什麼say“Yes”容易，say“No”難的原因。所以，這個問題歷史性地落在了專案管理或者團隊leader的肩上。
所幸我所在的團隊leader很給力，這方面一直管理有方，而且也在持續改進。下面就大概說下我們團隊的“專案管理”之術吧：
- 首先，每個人都是資源，而且是稀缺資源 ，一個人工作一天的工作量叫1人日。假設團隊有3個人甲、乙、丙，那一週可以支援的總工作量就是3人*5日=15人日。
- 假設這個團隊要支援的產品線有兩條，產品線A和產品線B。產品線A重要程度更高些，工作量也更大些，經協商，對產品線A和B按3：2的比例來安排資源支援，也即每週為產品線A投入9人日，為產品線B投入6人日。那資源的安排上，3個人中會有一個人（比如甲）全部投入到產品線A，一個人（比如乙）全部投入到產品線B，另外一個人（比如丙）部分支援A，部分支援B。
- 對於各產品線的需求，由產品線自己的介面人進行優先順序排列，週一早上統一發給支援方介面人（如產品線A的需求優先順序列表發給支援方的甲），支援方介面人評估每個需求需要的時間，根據協商好的人力數（如每週9人日），按優先順序列表進行排期，若列表裡的需求都排上了，固然最好，若排不完，看其他產品線的資源有沒剩餘的，即看乙和丙有沒有剩餘的人力，若有，則尋求支援，若無，排不完的需求順延到下週再排。
- 若在支援需求期間，有新的需求插單，則插單需求的產品自行與其他產品協商，確定出誰的優先順序更高。支援方只需關注協商的結果即可，若同意插單，則其他需求排期順延，若駁回插單，則按原計劃進行。
- 若在支援需求期間發生需求變更，視變更大小更新需求檔案或重提需求，支援方重新評估工作量並修改排期。
如此，把原本就該產品內部協商的優先順序問題拋回去了，支援方不必再為先支援誰的需求左右為難了，需求時間衝突時，也不必並行支援多個了。當然了，世上沒有免費的午餐，要求別人規規矩矩地，那自己也不能亂來。這樣做了之後，對自己的要求也更高了：
首先，需求的時間評估要準確。
其次，排期結果要反饋給產品，要按自己承諾的時間完成。
不想別人渾水摸魚，自己首先就不能渾水摸魚了。
當然了，制度是死的，人是活的，實際操作中可以適當靈活點。比如需求變更不大時，在自己可承受的範圍內可以開開綠燈；比如緊急需求插單時，可以幫產品分析如何既支援插單需求，又把對原需求的影響降到最低。制度是為了讓整個流程更規範、更順暢、更高效的，但遵守制度的同時我們也要時刻記住，我們的目的是為了解決問題，為了更好地解決問題，而不是拉仇恨的。在別人需要的時候幫別人一把，不但是職業素養的體現，也為自己日後尋求別人幫助打下了基礎。不過一定要把握好度，切記過猶不及。
上述方式對於日常需求來說可以了，但對於專案還遠遠不夠。因為專案規模比較大，時間比較長，支援期間難保有其他事情插單、上游提供內容不及時、專案變更等等意外情況。諸多的意外可能造成你專案延期，或者完成後又返工，但其他人是不知道箇中緣由的，別人只會看到你沒按計劃完成，看到你流轉下游後還在修改。誇張點說，你可能在背黑鍋，你可能在背黑鍋你都不知道。這種情況怎麼辦？透明化！在我們團隊，是有一套專案專用的郵件模板的：
開發計劃模板主要內容，用於專案啟動時：
專案變更模板主要內容，用於專案內容有較大變更或者有其他需求插單時：
專案待確認模板主要內容，用於本環節完成時：
通過幾個階段的郵件，使自己的計劃、輸出清清楚楚，不但有利於自己的時間管理，保護自己免於各種誤會，還可以使產品和上下游清晰地知道你的程式以及對他們的影響，減少溝通成本。而由於這些郵件都有現成的模板，你只需填內容進去即可，並不需要花多少時間在郵件的編輯上。
Ok，回到最初的問題，如果上下游都這樣管理自己的專案，自然就沒有問題了。在上下游都有序管理自己的專案的前提下，如果進行過程中，專案變更了，該當如何呢？結合當時大家的討論結果和自己的想法，簡單總結一下：
變更內容由產品經理通過需求管理系統或郵件發出，儘可能集中。根據變更內容對現有開發的影響程度和變更量的不同採取不同的措施。
以上，歡迎拍磚~通常來說，明事理的產品經理都是支援資源方這樣管理自己的專案的，因為這樣也更利於他們對專案進度和專案風險的把控。總之，一切只為合作更愉快，一切只為工作更順暢，一切只為專案更高效！
以上，歡迎拍磚~
2014.6.19