來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