項目管理大家談
作為組織級項目管理員，我們打交道最多的是項目經理，最需要了解的是項目經理遇到的困難。今天，我們非常高興能邀請到一位有想法、有干勁、擅總結、能創新的新晉項目經理，和我們分享在擔任項目經理以及日常開發運維過程中遇到的痛點與亮點，為中心的項目管理乃至其它管理制度獻計獻策。
被訪談人員均被隱去真名，這也是個小小的伏筆，等系列訪談結束后，我們將統一公布被訪談人員真名，敬請期待吧！閑話不表，直奔主題。
1、痛點一：立項晚、需求急—立項之痛
小新：那我先從立項說起吧。其實我們的項目早就有需求意向了，并且列入了年度計劃，但是從有需求意向到正式下達立項函，耗時半年。其中的原因很多：中心主辦部門不確定、立項流程冗長等。最終受苦的還是項目經理和開發人員。在監管要求下，面臨著工期緊、任務重的難題。需求來得晚、來得急使我們非常被動，只能從別的項目組臨時抽人，加班加點，“壓力山大”。因此我建議精簡立項流程，提高立項效率。
另外總是有些項目存在主協辦爭議，本來時間就緊迫，又被各種主協辦爭議、技術架構爭議等問題耗掉寶貴的項目時間，對業務部門及具體開發人員來說都是很不好的體驗。對此，我的建議是，建立專門的爭議解決通道，迅速找到決策人做出決斷。
小項：我想跟你分享兩個好消息。首先，根據新的項目管理辦法規定，項目立項可以在需求書交付之前進行（具體的中心立項流程可以參考小項的另一篇專題--“小編答疑解惑課堂之一中心立項流程”），已實現了你“精簡立項流程”的提議。其次，中心已有一整套爭議解決機制，使我們可以爭取在3個工作日內解決爭議。我相信，立項方式的改進以及爭議機制的建立會對咱們目前面臨的立項困境有所幫助。
2、痛點二：資源申請不暢—渠道之痛
小新：聽了你的解決方案，我覺得立項已經不是問題了，但資源申請還很成問題。大多數項目都會需要資源，現在的資源申請渠道有PM平臺、IT服務臺、郵件等。我們一般會根據之前的項目經驗直接在這些渠道里申請。渠道多不說，關鍵是它還會變！不僅是入口會變，流程也常常變化，讓我們無所適從。比如我有一次按照原來的經驗在PM申請了網絡資源，后來被告知網絡資源變成從服務臺申請了。這個時候我再換一個渠道申請，耽誤的可是項目的寶貴時間啊！希望咱們能和資源部門做好對接，形成入口統一、審批透明、開放咨詢的資源申請流程。
小項：我們也注意到了資源申請過程中出現的這些問題，也在努力尋求更好的解決辦法。目前由科技局主導，我中心配合建設的ITA（科技綜合服務管理平臺）的搭建正是改進資源申請流程的好機會。該平臺可對科技項目進行全流程管理，提高了各部門之間的信息流轉效率。對于資源申請效率的提高，ITA將是個很好的依托。我們將在后續參與ITA建設的過程中，把資源申請問題考慮進來，盡可能實現你提到的“入口統一、審批透明、開放咨詢”的資源申請流程。
3、痛點三：被逼無奈的創新—協辦之痛
小新：聽起來我們的資源申請未來要輕松簡單很多了。那我再來吐個槽：我們的項目趕上和全行重點項目并行，其中一個協辦說實在抽不出人來實現我們這個項目的需求，只好由主辦自己想辦法。我們真的是想了各種招，終于設計出一套雖可行但非常復雜的技術方案。我對我們的技術創新感到很驕傲，但是同時也覺得非常無奈。放在協辦那里做會很簡單的事情，最后不得不整這么“NB”。要我說，能否在項目前期就做好技術方案與人力資源之間的平衡工作呢？
小項：這里就不得不說說中心的技術評審制度。首先不要把技術評審看成是負擔，而要把它當做是一種保護。不知你有沒有留意，在每一份項目任務分解表中，都有一條“申請架構評審”的任務。我們正在開展架構評審前移行動，從項目到達中心的那一刻起，中心架構管控團隊就已經開始了分析研究，就是為了避免后續出現架構爭議。回到你說的具體困境，顯然是屬于協辦任務的技術方案問題，可以聯系我們啟動前面提到的爭議流程，后續將根據爭議結論決定的技術方案實施。我們與架構管控團隊也會跟進該技術方案的貫徹實施。這樣一來，你的方案就不需要這么“NB”了。
小新：這真是個好消息。我回去跟大家宣傳宣傳，我們就不需要像無頭蒼蠅一樣到處亂撞了。
4、痛點四：測試案例太簡單—測試之痛
小項：項目前期的立項、爭議問題解決了，后面的資源申請也有了解決方案，那么還有其它什么阻礙項目開展的問題嗎？
小新：那我得說說測試問題。開發的時候，我們開發了很多的功能，每個功能都設想了各種可能出現的異常狀況，反復優化程序的分支和結構，就是為了確保程序上線之后能夠安全地運行。有時候我們看到測試案例時，就很納悶，只寫了幾個案例，根本測不完整。出測試報告時，測試的部門還告訴我們報告可以出，責任不能擔。上線之后出問題，只打項目組的板子，而測試的部門卻毫無責任。我建議測試案例也要評審，不能光評審項目組，參與測試的各方都應該接受監督，負起責任。
小項：太好了！這個建議非常重要，將測試案例納入評審是推進測試工作規范化的好想法。評審是手段，責任落實是關鍵。現在根據新版的項目管理辦法（未發布）規定，數據中心已經承接牽頭組織系統測試和業務測試的職能。這說明測試與開發已逐漸明確各自職責邊界。我們也會努力推動，協調好開發與測試之間的職責移交。測試工作的職責明確了，出了錯，落下的板子也就有了明確的目標。有了這樣確定的職責劃分，我想大家都會對測試工作重視起來，評審的手段自然會有落實的動力。
5、痛點五：“愛做飯不愛洗碗”—運維之痛
小新：開發與測試的職責劃分清楚了，運維的職責最好也能劃分清楚。我做新人的時候參與過組內的運維工作，作為運維人員需要24小時開機，隨時應對分行的運維需求。當時那段經歷對我鍛煉很大，運維工作對快速熟悉系統大有裨益，也比較辛苦。但相比運維，我還是更喜歡做開發，大部分人和我一樣，“愛做飯不愛洗碗”，愛開發不愛運維。但是現實狀況是，我們每個開發人員都承接著任務量不小的運維工作，往往分身乏術，導致兩頭工作都沒有做好。
小項：運維移交機制的建立就是為了解除開發人員的后顧之憂，讓程序員更加專注于開發，讓運維需求統一扎口。不過，咱們為了將運維工作更完整地移交出去，也需要注意文檔的沉淀，將日常的運維操作步驟、已有的運維經驗知識盡可能詳盡地總結整理，讓接收運維工作的同事按圖索驥，快速上手。
除了痛點，我們的訪談還發現了項目組的很多亮點，下面就摘錄一個例子，以饗讀者。
6、亮點：咱也可以優化需求
小新：當然了，我們在工作中除了開發外也會提供其它方面的價值。有時候，我們對業務部門提的需求是能夠做出優化的。以我參加的一個項目為例，客戶向業務部門提出了一個很小的需求，業務部門來咨詢項目組，我們分析了這個需求之后，發現可以用同樣的工作量實現更豐富的功能，業務部門把我們的建議轉達給客戶之后，客戶表示非常滿意。
小項：這就是熟悉系統的優勢！咱們開發部門在需求編寫過程中的積極參與能夠為我行贏得更好的客戶體驗，真正實踐了“科技就是生產力”。
每一次與大家訪談，我們小項都受益良多。談話的內容豐富多樣，無法在一篇小文中完全涵蓋。好在咱們這是一個系列，現在不說不代表我們遺忘了大家的建議。可能是問題復雜，需要更多的調查研究；也可能是問題零散，我們會在積累歸并之后統一成文。總之，不管短期長期，20個小項都會把大家的問題放在心上，不放過擊潰它們的任何機會。我們會帶著大家的建議去思考變革的方向，盡我們最大的誠意，切實解決實際問題，準確地為大家做好服務工作。
最后，播放一條廣告，大家如果遇到任何項目相關的問題，都可以找項目管理員，也可以在項目周報中暴露出來，項目周報我們會持續關注，貫穿整個項目的生命周期，我們能解決的一定幫助解決，不能解決的也會給您答復。愿我們共同努力，讓“開心”的項目在開心的氛圍中展開！
