工作當中一些項目管理的心得體會
基本上,產品開發過程中的一些重大的關鍵問題,都是需要產品經理來拍板;至于拍板之前的種種溝通、權衡等,就要靠產品經理本身的“素質”了,正文開始:
“1人100個月完成的項目,不是100個人1個月就可以完成?!?/p>
項目管理是讓項目活動中相互競爭的各類制約因素:質量、進度、資源、風險等取得平衡的藝術,同時也是平衡項目干系人的各種需要、關注和期望,帶領不同的人朝著相同目標邁進的領導藝術。
成功的項目管理可以簡單理解為:按時、在預算內+滿足產品需求+滿足質量需求 地完成項目。
以下是我對項目管理的一點體會記錄。
需求等級
視覺 A:圖片沒有分享功能嗎?
技術 K:圖片有鏈接轉發分享、微博或郵件形式分享等多種分享,全部開發的話需要推延時間表。
策劃 D:圖片只做預覽、下載已經足夠了,暫時不做分享。
交互 E:如果我們的用戶是基于郵箱用戶,圖片的郵件分享還是建議做。
如果在前期產品需求文檔中沒有明確定義每個需求的優先等級,或者說項目成員對需求的優先等級沒有明確的意識,可能類似的爭論會時常發生在項目成員之間,每個人會基于自己對產品目標的理解來考慮這個需求是否要做,什么時候做,做到什么程度而產生分歧,因而增加項目推進的阻力。
所以在前期產品需求文檔中,必須明確定義出每個需求的優先等級,需求的粒度可細化到每個大功能下的子功能需求,如:圖片分享功能的轉發鏈接分享、郵件形式分享這樣的子功能需求。等級的劃分依賴于前期的用戶需求調研、產品的預定目標、開發成本、運營計劃等;
一般的需求等級劃分:
P0 -Must have: 如果缺失,產品不能發布
P1 -Should have: 如果缺失,產品能發布,但不能達到預定目標(功能/性能)
P2 -Nice to have: 做了則更好
P3 -Neutral: 對產品沒有明顯的好處,用戶不在意
每個需求的優先等級確定之后,產品經理根據產品預定目標、開發成本、運營計劃等來定義一個等級分界線,高于或等于這個等級分界線的需求在本期開發,部分根據成本、運營計劃等因素調整到下期開發,而低于這個等級分界線的需求則只會在下期開發,這樣讓全體項目成員對本期要做的需求達成共識。
需求等級的實際應用:
WBS各工作包Triage的參考基準之一;Triage即確定需求任務是否要做,是否要現在做的一個共同決策過程;在Triage的過程中,任務owner對自己的任務以及其他人的任務有更全局的認識。
Bug的Triage的參考標準參考基準之一(也是zero bug *注1 和code freeze *注2 時間節點計算的參考基準之一);Triage即確定測試中的Bug是否要修,是否要現在修;如:在功能開發期間,P0、P1、P2及以上的Bug都要修;當進入接口凍結期后,只有P0、P1normal及以上的Bug才允許修,以保證優先的Bug問題更快地被解決。
*注1 Zero Bug:當前不存在active bug,或不存在高優先級或特別嚴重的bug
*注2 Code Freeze:除高優先級或特別嚴重的bug外,代碼凍結不再接受提交
WBS
技術 K:相片上傳的界面還沒有搭建好嗎?這部分我們需要先做起來。
前端 J:視覺設計師沒有完成呢!
視覺 A:我在做相片的展示頁面,還沒有做到相片上傳。
項目各成員對自己需要負責的任務粒度細分不到位,每個任務的交付時間點不夠明確,對任務之間的依賴關系也不夠清晰,造成項目推進中的協作成本提高,項目時間預估準確率不高,項目控制的風險增加;
因此在產品需求文檔確認之后,必須做工作分解 WBS(Work Breakdown Structure),即把需求分解成較小的、易于管理的工作包。一般的工作包是最小的“可交付成果”。工作包必須詳細到可以對該工作包進行估算(成本和工時)、安排進度、分配負責人員或組織。
項目經理、項目成員和所有參與項目的職能主管都應該參與WBS工作,根據項目規模情況,可以由項目經理或各模塊主策劃來組織。組織方負責召集有關人員,集體討論所有項目工作,確定項目工作分解的方式后,各職能方提交各自的WBS,匯總后畫出WBS的層次結構圖。結構圖中應包括每個工作包名稱(內容定義)、指派人員名稱、所需工時、可能的依賴關系等;
WBS的工作包,最終以任務形式錄入到QA中進行跟蹤管理。
WBS的好處:
為資源、成本、進度、質量等控制奠定共同基礎,確定項目進度和控制的基準;
為各獨立工作包分派人員,規定這些人員的相應職責,便于項目職責的落實和明確劃分;
針對各獨立工作包,進行時間、資源需要量的估算,提高時間、資源估算的準確度,并確定工作順序,提高協作效率,利于更準確的制定項目進度計劃表;
——————————————————————————————————————————–
QA可視化項目管理
技術 K:我完成到圖片分享功能,圖片下載的bug已經就提交上來了,但是我現在沒有時間改bug。
測試 F:我已經提了一輪的bug了,但是我不知道bug什么修好,然后我可以去復查。
交互 E:圖片分享功能開發完成了?可以測試了嗎?
產品經理 :現在大概還有多少P0的bug?zero bug時間節點是否需要后延?
如果沒有QA,項目的狀況不是對每個項目成員透明化,就會出現以上的各種情況;
QA作為協同式任務管理工具,通過對每個任務的記錄和跟蹤,讓項目成員對整個項目的情況有直觀的了解,項目經理可隨時監控項目推進中的風險是否在可控范圍,并提前快速作出調整。
不管是前期開發的工作包還是后期的測試bug,均以任務的形式錄入在QA里,然后對這個任務的一些基本屬性做設置,如:屬于哪個milestone、哪個模塊等,然后由各個階段的Triage的負責人按照需求等級標準來對任務作分類定級,并確定是否做,是否現在做;所有的任務都必須經過Triage并approve通過,才能開始工作。Triage的決策需要多個層面的知識(結合產品、技術、進度等多方因素),特別是在大項目中,Triage往往是一項群體工作,以功能小組(feature team)或產品決策組的方式來進行。在項目的不同階段,可以由不同的角色來主導Triage流程。
在任務approve后,各職能方leader將任務指派給相應具體執行的人員。執行人員,也就是任務的owner,必須設置任務的Status date,如:Status任務狀態是Working(進行中);Status date即完成日期點,Status date應真實反映實際工作計劃,并應契合項目時間表。
在執行人員完成任務時,QA會通知各職能方leader去關閉這個任務,關閉的意義在于通知任務的相關跟蹤者,可以著手下一部分的工作,如某功能代碼任務關閉,即相關測試人員就知道可以開始這個功能點的測試工作;
通過任務在QA系統里的記錄和跟蹤,以及任務狀態的實時更新,最終會匯總生成各種可視化的圖表,項目進展直觀,且可度量,能夠很好的把握整個項目推進的節奏,對項目中各項問題和風險定位更容易,并可在周會上對項目的所有成員公開進度信息,便于協調一致;
其中最重要的圖表:glide path任務走勢圖:
“實際任務走勢”與“計劃任務走勢”的對比,可以衡量出計劃與實際的偏差。
每日構建
技術 K:我們只在每個小milestone才會打build。
交互 E:希望可以每日bulid,我可以每天拿到最新的版本進行測試。
測試 Q:我建議測試前期可以每個milestoen打版本,但是中期開始,每日build。
每日構建(daily build)是指每天對整個項目做一次完整的自動構建,生成可執行文件的過程,對Web類產品,每日構建通常要伴隨自動部署的過程,將這些可執行文件部署至測試環境,并按照一定的規則對這個安裝包或測試環境做版本編號,是一種Public build的管理方式。
每日構建是編譯管理的一種方式,項目初期,可根據根據需要按照一定的頻率打,如:每周、每個milestone,隨著項目的進行頻率逐漸增加build的頻率,如:每天build。
每日構建的好處:
每日構建讓從產品經理、項目經理、策劃、交互、視覺等所有的項目人員從第一個小功能模塊完成開始,能夠隨時測試最新的版本提交bug,并能及時了解技術開發的進度;
每日構建讓測試人員從第一個小功能模塊完成開始,能夠每天測試最新的版本,提交新bug和復查部分bug,而不需要等著某個小milestone或者所有的功能代碼都實現了,再開始測試,大大增加了測試和開發的重疊時間,測試更充分,測試和開發的迭代效率更高,產品質量控制得更好;而且bug提交到qa上,也會一并附上build版本號,方便技術還原現場,更快地解決bug;
每日構建使得技術必須對每天自己輸出的代碼負責,一旦每日build失敗,必須檢查原因,并糾正不可再犯,以避免再次build失敗,這樣能非常有效地提高所提交代碼的質量,減少bug的產生,加快開發效率;
雖然搭建并維護daily build,需要比較大的工作量,但絕對物有所值。
- 目前還沒評論,等你發揮!