close

                                                                                       

 

專案管理本質上是在管理資訊和人,如何將正確的資訊在正確的時間點傳達到正確的人,是一門學問。

本文將從專案管理的5個環節入手,分別介紹每個環節要注意的事項。

一、需求文檔

1. 異常狀態

比如:異常流程、頁面的缺省狀態、資料的溢出空值狀態等。

這些異常狀態,如果在開發階段才被發現,你就不得不向開發做需求澄清,向設計師要求補充UI,他們可能臉上笑嘻嘻,心裡MMP,專案進度也很有可能受到影響。

以前看過一句話,產品經理腦海中的需求變更,才是成本最小的需求變更。

因此,及時在需求文檔階段標明異常狀態。

個人認為,需求文檔寫得最理想的狀態是:任何人但凡有任何需求上的疑惑,你就把需求文檔甩給他看,他就懂了。

2. 動態資料

產品介面上的資料分靜態和動態2種,靜態資料一般是用戶端寫死,動態資料一般是介面傳的。

對於介面的動態資料,可以單獨列一個表格,標明資料名稱、資料格式以及資料的溢出空值狀態。

如果是比較大的項目,可以用Xmind列出產品的總體資訊結構,也就是產品涉及到的全部欄位。

服務端開發可以通過參考你的欄位表,很便捷地創建資料結構,開發介面,從而加快專案進度。

3. 資料指標、埋點需求

臨到專案上線才想起要資料埋點,而具體埋什麼資料不知道,導致資料埋點不準確或不全面,效果評估大打折扣,對於一個專案來說是比較打擊士氣的。

這其實是缺乏資料意識的體現——為了需求而需求。

不知道需求要達成什麼目的,也就不知道衡量目的的資料指標,也就不知道生成資料指標的資料埋點該怎麼做。

理想的解決方案,在需求文檔階段,首先明確衡量需求的資料指標,思考一下指標可以通過什麼資料生成?

通過集成的協力廠商資料統計工具就可以,那就確保統計工具可用。

通過資料庫保存的欄位就可以,那就注意第2項中的動態資料。

如果必須通過資料埋點才行,那就將埋點需求納入需求文檔,作為需求的一部分提給開發。

二、技術評審、排期

1. 技術難點

一旦技術難點在開發階段才被發現, 那將極大加劇專案延期的風險。

都說產品經理要懂點技術,這裡就可以派上用場。

評審前,提前預估技術難點,評審中遇到技術難點,停下來,讓負責的開發注意一下。

能在會上評估就在會上評估掉,如果真的比較複雜,會後讓開發做一下技術調研,再排期。

這樣給出的排期在專案進度上相對可控。

如果評估出來發現技術難點的開發量遠超預期,那就要考慮下需求的性價比,是否有替代方案,是否轉為反覆運算需求等?

如果整個專案的開發量遠超預期,那就考慮根據需求的優先順序,將專案劃分成多期開發。

2. 環節進度可交叉

設計—>服務端開發—>用戶端開發,它們不是一條流水線,一個環節完成才能進入下一個環節,環節進度是可以相互交叉的。

這樣做的好處是:盡可能在一段時間內,充分利用資源。

簡單來講就是:誰都別閑著。

2個例子:

1:設計師可以先設計出整體的UI框架,把介面上元素的位置、尺寸定好,就能給到用戶端開發了,然後再設計iconbanner等相對耗時的元素,用戶端到時候替換一下即可。

2:服務端開發有了需求文檔,也可以著手開發資料庫、介面和管理後臺。

資料庫和介面可以先開發,讓用戶端先接起來,有問題能及時暴露。

介面很多,則可以按照產品模組分批給。

至於管理後臺的功能,開發通過底層資料庫也能實現,因此優先順序可以往後,放到資料庫和介面穩定後再開發。

三、開發

1. 項目例會

在一個中大型專案中,專案例會很有必要,多方可以及時同步資訊,暴露問題。

專案例會的頻率,可以根據專案週期、干係人多少,靈活調整。

如果項目到達一個里程碑,很有必要在項目例會上向大家宣告目前已經拿下的戰果,鼓舞士氣。

2. 需求變更

遇到變更,首先考慮必要性。

如果影響到主流程,不改不行;果斷同步給相關開發,說明變更原因,評估變更額外增加的開發量以及對專案進度的影響。

如果是體驗上的優化,考慮移入反覆運算需求。

對於產品經理來說,完成比完美更重要。

死摳細節,只會加劇專案風險,同時你在專案成員心目中的靠譜值也會被蠶食殆盡。

一旦確定變更納入到本次專案中,將變更記錄到文檔中,說明變更內容、變更原因、負責人等。

3. 提前同步項目風險

遇到項目中可能的延期,提前向項目干係人同步項目風險,說明延期原因。

等到已成既定事實再同步,產品可能不自覺就成背鍋俠了。

四、產品驗收、UI驗收、測試

1. bug收集

產品驗收主流程就行,細節交給測試。

將驗收過程中發現的問題匯總再交給開發,集中處理bug效率更高。

如果bug一個個提,他們肯定煩。

2. UI驗收的優先順序

驗收和測試時間充裕的話,UI驗收可以和產品驗收同時進行。如果時間緊張,UI可放到最後驗收,先把流程和邏輯測好。完成比完美更重要,你懂的。

五、上線

1. 上線通報

及時同步上線資訊給專案干係人,並感謝項目成員的辛苦付出,這既是一個交代,也是對他們付出的肯定。

2. 成果通報

專案有實質性成果,及時通報,成員的士氣會得到極大提振,你在項目成員心目中的靠譜值會上升一點點。

如果成果顯著,向上級申請專案獎金,請專案成員出去搓一頓,你的靠譜值會飆升。

全站熱搜
創作者介紹
創作者 微社群馬丁 的頭像
微社群馬丁

馬丁跟你說

微社群馬丁 發表在 痞客邦 留言(0) 人氣()