臨時項目經理
公司的PM（項目經理）採用了輪流制，這次輪到我來做了。
與上一任PM溝通後，發現風險並不在於技術方面，主要還是在於需求和跨組協作方面出現了問題。
具體包括需求評審不夠細，有遺漏，導致實際所需時間比預期長；操作變更未通知其他組人員；缺少UI評審環節等。
讓我印象最深刻的是一個發送站內信的功能，因為客戶端與產品對於兼容程度的理解不同，而導致項目延期了多天。
一、需求和技術評審
1）需求評審
鑒於之前的經驗教訓，此次需求評審做的比較細緻，開了一個小時左右。
但是從各方的表現來看，在開這個會議之前，大家都未細看需求。在會議上，也只是單方面的聽產品說明需求。
如果讀過的話，那麼肯定會有更多思考，在會議上與產品的互動也會更多。在會上有一個重要資訊，那就是當前的需求是不完整的。
還有兩個重要的需求，正在策劃中，隨時會添加進來。當前的話還是按計劃執行，我會用飛書製作一張開發進度表。
表格中包含需求名稱，版本，優先順序，平台，開發人員，進度，工時等列，每個組對應的需求都會有單獨的一行。
將原始需求拆解成任務，這個工作還是客戶端做比較適合，因為版本迭代時，其他組都是為他們服務的。
而且我還需要與客戶端溝通制訂一些迭代中的時間結點，這樣我就能更精確的把握開發進度，保持資訊同步，也能預判是否有延期風險。
在初評之後，還有個詳評，但鑒於需求比較明確，我將詳評和技術評審合併在一起了。
2）技術評審
在第二輪的技術評審之前，我們組詳細的閱讀了需求的每個字，其實如果細看的話，可以發現很多沒注意到的盲點和細節。
我在閱讀第一遍後，就找到產品核對了好幾個細節和歧義，讓她也補充了圖示，還特地讓她完善了兼容性說明。
在會議之前，還讓客戶端按照他們的節奏制訂了需求開發的順序，這樣我們其他組可以配合他們，提前準備好介面或數據源。
在會議中，會針對每一個需求，每一個組，從頭過到尾，從介面數據結構到一張表的欄位，盡量做到不遺漏，會議也進行了半個多小時。
總體來說，將看的到的，都核對了一遍，另外的細節，各個組在會後再討論。
在會議中又提到了一次前後端分離的問題，因為這次有個廣告需求，這些業務的表都存在我們維護的資料庫中。
服務端既不想連接這個資料庫，也不想做解析，他們希望我們提供介面給客戶端，服務端只做一層轉發，那我肯定不會答應的嘛。
如果直接與客戶端交互的話，那麼我們這邊就要做進一步的優化，防止在用戶量上來之後，出現性能瓶頸。
並且一旦有問題，調試鏈路也變長了，與營收相關的業務，公司肯定會重視，下班時間有問題還得配合排查，很多現實問題讓我不得不仔細斟酌一下。
後面經過討論後，他們希望再招一個人，來應付這些需求，那和領導申請即可，上半年完全沒有名額，現在現金流好點了，名額也開放了。
不過在人到崗前，還是得先把任務職責劃分好，最後還是由他們和客戶端對接。
在進一步與客戶端溝通開發節點時，iOS表示目前還無法給出明確的時間點，他們還有一些特殊的事情需要完成，而Android表示最快這幾天就可以開始了。
二、項目過程
在需求評審召開一周多的時間之後，各個小組才陸陸續續的正式開發。之前在處理上個版本的問題，或其他雜七雜八的需求。
直到現在服務端還沒有評估好開發時間，更沒有給出初步的提測時間，於是我又做了張表格，用於記錄各端的提測時間。
目前給我的感覺就是服務端對項目管理並不是很配合，其他組的話，催促一下會有點反映，但他們組的響應總是會慢幾拍。
1）時間結點
各端將提測時間制訂好後，粗略算了下，都要十多天的開發時間。
為了能及時的了解進度情況，需求評審時我是想讓客戶端制訂一個各個功能的時間結點，然後我就在這個時間點確認是否完成，以此了解開發進度。
在正式與客戶端表明意圖後，他們表示這個操作可行性很低，無法執行。就比如最近服務端有個人休假了，那麼與他配合的功能就不能按計劃開發了。
如此一來，之前訂的時間結點就無效了，客戶端表示，他們目前可以給出功能優先順序，同時他們建議各端及時的更新進度表中的狀態。
這樣也就能了解當前版本的整體進度了，並且每天固定時間在群里和各個組同步進度，詢問是否有需要溝通的問題。
服務端未能在規定的時間提測，這其實也在我的預料之中，因為這些天的開發過程中，有一個組員的進度慢了一天多。
2）測試用例評審
QA會準備一份詳盡的測試用例，涉及到這次版本功能的方方面面，以表格或思維導圖的形式展現。
他們會將版本迭代的相關人員組織在一起，開一個評審會議，一般在一個小時左右。
在討論用例的同時，也會再一次與各端確認技術細節，同步對功能的認知。
大家面對面的談，也能讓QA及時的更正那些他們對需求的誤解，儘早發現問題，也能避免更多的損失。
3）UI和業務驗收
QA經過測試和預發兩個環境的驗收並通過後，接下來需要產品和UI的驗收。
業務方包括產品和運營等人，她們會查看功能是否有遺漏，版本的實現能否達到她的預期，由於時間的關係，對於用戶體驗的要求不會很高。
UI會查看頁面與設計稿之間的匹配度，他會將需要修改的部分配上像素值和截圖，並且也會提一些體驗修正。
開發會對體驗方面的問題做些適當的調整。
4）復盤
首次需求評審時的版本比較簡單，兩周左右就能完成。後面加了一個比較重要的營收功能，一下子就拉長了整個開發周期。客戶端比預期的提審時間玩了幾天。
iOS希望這次版本能將之前用戶提的問題一併修復，提升用戶滿意度。iOS工程師認為期待了那麼久的新版本，卻沒有修復預期的問題，非常影響用戶心情，於是就延遲了提審時間。
整個版本迭代周期差不多是一個月多幾天，其實我個人感覺周期有點長，期間會發生變數的概率比較高。如果每次提審時間都延遲個幾天，那麼積少成多，可以加起來都有一個月的。
服務端的人員變動也間接影響著版本迭代，期間有個人是經常請假或來半天，導致客戶端雖然布好了頁面，但無法聯調。另一個在版本迭代快結束時離職了，由於在後期，所以並沒有影響提審時間，不過上線後的維護多多少少會有點影響，畢竟換了個工程師。
客戶端和服務端積累著不少陳年Bug，這些Bug一旦爆發，那麼就會非常影響迭代進度。一般的話，偶現的問題都會先放放或加埋點，必現且嚴重的就會騰出手來修復。雖然這個雙月提出了清零計劃，但看目前的進程來看，很難按計划行事。
任務進度表只是在前期剛開始的時候大家會維護，後面就形同虛設了，除了我們組自己會更新狀態，客戶端也會更新一點，服務端基本不更新。測試組的進度也不會在此反映。這個表的用途就變成功能分割後的展示了。
