如何在阿里作一個靠譜的前端 PM

本文來自飛豬前端@九屻同窗（也叫狗哥），深刻業務側開發多年，在項目中有深厚PM的經驗，給飛豬新同窗梳理了這篇《前端PM手冊》,借飛豬前端團隊微信公衆號分享給前端的開發同窗，期待能夠給大夥一些阿里項目開發管控過程當中的一些輸入，歡迎一塊兒交流！

前端PM防diss指南

從開始作飛豬前端導購業務項目至今已有一年多時間，在大大小小的需求洗禮下自認爲對前端需求的掌控度尚可，可是在接到個別需求時仍是會有一些不在掌控、千頭萬緒的感受，會怕遺漏一些應該作的對接或者評審，也會遇到一些情況外的問題，更是會遇到「模棱兩可」的選擇題，尤爲是我這種比較糾結類型的人，好比：

• 這種相似的場景見得太多了，看一下就直接跳過吧？
• 需求評審時已經說清楚了，需求也不大，技術評審還要作嗎，是否是能夠直接拉排期了？
• 技術評審某個同窗沒參加會議，我也不直接依賴他，是否是不來也不要緊？
• 這個功能點到預約時間了還沒完成，釘釘催下進度就行了？
• 要發項目週報嗎，好像不發也能夠？
• ......

當由於生怕遺漏而焦慮時，是否有一個能夠check的「應作事項list」？當遇到情況外的問題時，是否有「指南」能夠學習？當面對上面的選擇題時，是否有前人的經驗能夠幫助決策？哪些是不變的定論，又有哪些是須要因地制宜的思考，這個準繩是什麼？其實目前現有的技術PM定義裏面已經包含了答案：

• 技術：提供技術方案,解決產品可用性、易用性問題，同時確保技術上的健壯性和系統性，對用戶體驗和有效的實施過程負責。
• PM：確保成員對Task理解清晰，邊界清楚，對工期預期一致，組織推進落地，調動資源，化解風險，對交付物質量負責

可是「定義」，通常都是抽象的，具象到現實的導購場景上時咱們該怎麼作，哪裏能有一個清晰的答案，哪怕是經驗？
爲了防止本身後續再陷入這些問題，根據我以往作前端PM的經驗和教訓，基於現有阿里業務項目總結出一份《前端PM手冊》，若是你是其餘業務線的小夥伴，可將本身的業務以及工具代入閱讀。但願這份手冊能對我和其餘同窗在以後的工做中有一些幫助，也但願能對其餘業務線的同窗有些啓發，歡迎你們批評指正。

需求評審

評審前的準備

能力準備

• 熟悉對應業務，對業務有本身的體感，清晰業務範圍和邊界
• 熟練業務經常使用工具：好比依賴的搭建平臺、業務邏輯處理的工具（圈特定的人、選擇合適的商品）、模版搭建工具；算法規則配置等等
• 熟悉項目平常工具：需求週期管理平臺、數據埋點平臺、ABTest工具、玩法活動平臺等等

和PD事先溝通產品意圖（通常發起評審前會PD先找主要開發者溝通）

• 對不是通用能力解決的場景，態度明確的提出意見，建議PD從新審視需求和資源
• 對不熟悉當前業務運營工具、實現流程的，須要科普
• 對不熟悉項目歷史（指已有項目作更新迭代）的PD，須要科普並提供本身的看法
• 對重複實驗性改動（既以前作過相似改動可是效果並不理想）提出意見，尤爲是背景和目標無太大區別時態度要堅定
• 要充分傾聽PD的改動背景、設計思路、產品預期，能據此提出的意圖給出本身的建議或意見（技術上或者業務上），能對PD和業務有必定的輸入
• 對PD不熟悉須要涉及資源的狀況，要及時給出負責人或者範圍或者方向，讓PD有大體的體感

溝通後的工做

• 仔細閱讀PRD，須要對每一個模塊用到哪些能力有清晰的體感
• 需求的業務目標必須清晰合理，投入產出太低、目標模糊的須要反饋給PD從新審視
• 涉及到本身不熟悉的領域要及時補足信息

  • 例如：這個活動頁面須要用到秒殺功能，秒殺功能對應的活動玩法體系本身是否瞭解？
  • 例如：本次有招商的商品進入，招商的流程、招商商品和普通商品的差別本身是否瞭解？
• 不涵蓋在本身理解的業務範圍內需求，要及時和老闆溝通業務範圍和邊界，而後反饋給PD
• 功能改動涉及到開發人員不清楚的話，及時諮詢，防止評審時漏人
• 有新技術、新工具挑戰，要及時作好技術儲備

需求評審邀請

• 需求評審會議邀請由PD發出，PM須要檢查與會人員是否涵蓋全部必要人員以及必要人員是否能準時參加
• PD沒有項目釘釘羣的，須要拉釘釘羣，由PD負責闡述需求背景等，需求PRD地址須要放入羣公告
• PD沒有提早溝通需求的，仔細閱讀PRD後若是有疑問，根據對項目的影響決定是否馬上須要找PD溝通

  • 對於業務邊界、資源優先級等 直接影響項目開展的問題，須要馬上找PD溝通，須要PD理清邊界、協調資源
  • 部分模塊技術上不可行、目前工具沒法承接等問題，能夠在評審時拋出討論

評審

需求評審會議

• 確認必要人員所有到場
• 需求的業務目標必須清晰合理，有量化可追蹤

  • 例如：本期重點關注的指標是點擊率，須要明確點擊率在多久內達到多少，對比哪一個時期提高多少
• 需求評審的重點是評審需求的合理性，以各需求相關方承認爲準，沒必要在技術細節上過多討論，此類問題可記錄後在技術評審上肯定

  • 例如：某個商品字段可否取到這種問題，只要不是本期特別關注的字段能夠先記錄下來，由於有可能交互稿也只是示意圖，能夠在UI評審時確認，技術評審時肯定
• 需求點必須作到徹底清晰，不可想固然如此，必需要各方肯定方案，而且要確認方案的可行性
• 需求使用交互稿評審的，須要關注前端的交互問題，在需求評審時就拋出，防止拖慢UED進度
• **有討論後確認的模塊的需求，或者特殊的模塊需求，須要有文字記錄 **

  • 例如：秒殺模塊倒計時需求，是運營填寫倒計時的時間點仍是讀取活動的接口，倒計時結束後模塊更新成什麼內容，異常兜底怎麼處理。這種產品、運營、技術溝通後造成的共識，必定要記錄下來
• 對於須要會後確認的點，要記錄清楚問題、指定到人以及要肯定在什麼時間能夠確認好，確認好以後要有反饋（在UI評審上或者羣裏給到回覆）
• 肯定後續UI評審的時間，資源不肯定的狀況下除外

需求評審會議結束後

• 將記錄的結論、問題以會議紀要的郵件形式發出同時同步到釘釘羣和PRD的評論中，要求有疑問立馬反饋。對於肯定到某我的的某個時間點必須給出結論的事項，必定要標註清楚問題、人和時間
• 到了肯定的deadline無進度回覆的，須要聯繫問題的負責人肯定進度，並將進度周知各方

UI評審

評審前的準備

預覽設計稿

• 預覽一遍設計稿，設計稿主要關注常見的問題點

  • titlebar是常態的仍是異形的，目前是否支持
  • 當前技術棧下是否與特殊排版沒法實現
  • 每一個卡片字段取值來源
• 模塊和需求設計相差較大的，須要記錄並在評審時提出

UI評審邀請

• 需求評審會議邀請由PD或UED發出，PM須要檢查與會人員是否涵蓋全部必要人員以及必要人員是否能準時參加
• UI稿地址須要放入項目羣公告

評審

UI評審會議

• 確認必要人員所有到場
• 需求評審待確認事項同步

  • 全部關於需求的待定事項必須此時完成確認
• 模塊和需求設計相差較大的，須要和PD、相關方溝通確認並記錄
• 設計稿交互、排版不合理或者沒法實現，或者實現成本大可是業務收效低的須要提出溝通，並將最終結果記錄下來
• UI稿的評審要精確到商品或內容的字段，尤爲是牽涉到不常見字段時必定要重點關注，須要和服務端同窗一塊兒在會上溝通肯定可否拿到，不肯定的須要將該問題跟進的負責人和時間點記錄下來
• 須要能掌握每一個模塊對應的先後端、算法等開發者是誰，開發者的依賴方不在場的須要記錄下來，以確保技術評審無遺漏相關方
• 會上除了沒法確認的純交互、排版外，其餘事項須要所有肯定下來，單純的UI問題須要具體到人到什麼時間確認，確認時間須要在技術評審以前，將負責人和時間點記錄下來

UI評審會議結束後

• 將記錄的結論、問題以會議紀要的郵件形式發出同時同步到釘釘羣和PRD的評論中，要求有疑問立馬反饋。對於肯定到某我的的某個時間點必須給出結論的事項，必定要標註清楚問題、人和時間
• 到了肯定的deadline無進度回覆的，須要聯繫問題的負責人肯定進度，並將進度周知各方

技術評審

評審前的準備

心理準備

• 須要到場的相關方是否都已清楚、明確
• PM必須清楚各位開發和業務方站位

  • 例如：一個典型的促銷活動頁面，商品池是誰提供（算法仍是運營），商品字段由誰來補充（服務端取值仍是算法計算產出），投放的方式是怎麼樣的（運營配置入口仍是個性化算法），生產的方式是怎麼樣的（算法仍是運營配置），入口有哪些case，每種入口展現須要哪些字段
• 需求和UI是否已經瞭然於胸，每一個模塊須要溝通的功能點是否已經心中有腹稿
• 前期遺留的待定事項是否都已有確切結果
• 哪些是重點問題，哪些是一帶而過的點，要分清主次

  • 常見的功能點是次，新的功能點是主
  • 簡單的模塊是次，複雜的模塊是主
  • 單個開發者自給自足的模塊是次，多方合做實現的模塊是主
• 技術評審的主要目的不是爲了拉排期，而是爲了信息互通、肯定技術方案、理清各開發者邊界和合做方式

技術評審邀請

• 需求評審會議邀請由技術PM發出，PM須要檢查與會人員是否涵蓋全部必要人員以及必要人員是否能準時參加

評審

• 全部開發人員&測試人員&PD必須所有到場，若是須要運營配合的，運營同窗也必須到場
• 評審參照UI視覺稿逐模塊進行
• 每一個模塊的每一個字段由誰提供、怎麼實現要溝通清楚

  • 對於某些特殊字段，須要文案記錄取值邏輯，誰來實現，怎麼實現都要記清楚
• 對於以前未接觸過的功能點，須要文案記錄技術方案
• 對於須要多方合做完成的模塊

  • 須要各方對技術方案達成共識，要探討到具體的實現流程，不能有含糊的想固然

    • 例如：某個數據誰來給數據依賴方，數據從哪裏來又將經過什麼方式給到依賴方，是事件通知、sql仍是離線表，這個數據實時性的要求如何，穩定性的要求如何
  • 須要清晰到每一個開發者負責哪些、提供哪些、上游下游是誰
• 對於各方難以抉擇的邊界問題，及時拉上相關方主管確認邊界劃分
• 各個模塊的方案溝通清楚後，協商排期

  • 通常的需求，須要後端提供功能聯調的，須要確認的時間點按照時間線正序：

    • Kickoff時間
    • 先後端數據協議約定
    • 後端mock數據提供
    • 後端真實數據提供
    • 先後端聯調時間
    • 提測時間
    • 驗收時間
    • 上線時間
  • 通常的搭建需求，須要確認的時間點按照時間線正序：

    • Kickoff時間
    • 前端建立完成模塊時間
    • 運營同窗商品池建立完成時間
    • 運營同窗數據投放平臺配置完成事件
    • 提測時間
    • 驗收時間
    • 上線時間
  • 後端也有依賴改動的，除通常需求的必須時間點外，須要清晰到各個被依賴方能提供出數據或能力的時間點，必需要知足依賴方的開發工期
• 會議結束後須要有一個明確的開發排期

項目進度跟蹤

項目啓動

是否須要Kickoff郵件

• 除平常迭代外全部項目均須要Kickoff郵件

Kickoff郵件內容

• 基本要素：項目背景、項目目標、項目節奏、項目成員、項目資料
• 明確闡述項目範圍和開發內容，後續開發範圍以此爲準，不在該範圍內的變更均算需求變動
• 郵件接收人爲全體項目成員，抄送主要相關方（PD、運營、UED、先後端、算法、測試）主管 + 本身所在團隊項目成員，重要項目須要抄送到推動此事各團隊或BU負責人

項目週報、日報

是否須要項目週報或日報

• 原則上鼓勵項目週報
• 重要或特殊項目（如：涉及相關方多且跨團隊甚至跨BU的項目；相關方多，信息難以同步的項目），必須有日報周知
• 開發工期在兩週內的平常迭代項目，能夠沒有項目週報或者日報，但須要天天要關注各個開發者的進度
• 開發工期在兩週內的平常迭代項目，因非資源問題開發進度受阻未按時提測的，須要有項目日報周知進度
• 除以上類型外的項目須要有項目週報

項目週報、日報內容

• 本週/日工做進度：具體到每一個事項以及事項對應的負責人
• 整體進度：明確進度百分比，概述目前完成的功能
• 問題&風險

  • 問題：本週/日發現未解決但已有解決方案的
  • 風險：有可能影響項目內容或進度的事項，須要標紅警示
  • 不可控風險：基本肯定影響項目內容或進度的事項，置頂標紅警示
• 下週/明日工做安排：具體到每一個事項以及事項對應的負責人

風險&延期

• 發現風險必定要第一時間同步PD
• 對於不可控風險，馬上拉動PD和相關開發者會議溝通解決方案
• 資源投入問題

  • 投入產出較低的功能點，優先考慮是否有替代方案甚至去除該功能（例如：商品卡片的某個字段取值邏輯問題，按照既定邏輯須要涉及多方改動，是否可使用現有的其餘取值代替），須要和PD、開發、測試達成一致，發送需求改動通知報
  • 能經過補充人力來解決的

    • PM動員協調項目成員，組織加班，加班須要有加班郵件，郵件內容如日報
    • 若是相關開發人員團隊有富餘人力可由開發者在團隊內溝通協調
    • 沒法協調的，由PD出面協調人力資源
  • 不能解決的，再考慮需求是否有替代方案，須要和PD、開發、測試達成一致，發送需求改動通知
  • 可能因一個功能延期可是該功能優先級並不高的狀況，考慮需求是否能夠分拆到二期進行，須要和PD、開發、測試達成一致，發送需求改動通知
  • 以上都不可行，考慮項目延期，延期須要和PD、開發、測試達成一致，發送項目延期通知
• 功能實現問題

  • 投入產出較低的功能點，優先考慮是否有替代方案甚至忽略該功能，須要和PD、開發、測試達成一致，發送需求改動通知
  • 技術上有實現方案，不過須要既定成員外同窗參與實現的，PM與PD一道協調人力或由PD指定子需求，PM和相關開發同窗確認技術方案可行
  • 不能解決的，再考慮需求是否有替代方案，須要和PD、開發、測試達成一致，發送需求改動通知
  • 無替代方案且沒法實現，考慮去除該功能，須要和PD、開發、測試達成一致，發送需求改動通知

需求改動&延期通知

• 非重大項目需求改動：釘釘羣周知而且在PRD中備註，項目周/日報中體現
• 重大項目需求改動 或者 任何項目延期：除釘釘羣周知而且在PRD中備註，項目周/日報中體現外，須要郵件周知Kickoff郵件的收件人

提測規範

是否須要提測郵件

全部項目均需有提測郵件

提測郵件內容

• 基本要素：功能完成度、是否完成自測、測試包（若是須要）、離線包（若是須要）、頁面地址、二維碼、項目資料
• 中間有需求變動的，須要在提測郵件中着重提醒
• 對測試內容有特殊要求的，須要在提測郵件中代表
• 對測試方法有特殊要求的，須要在提測郵件中標明測試方法文檔地址

發佈

發佈前提

• 必須測試經過
• 必須業務方驗收經過

發佈安排

• 發佈嚴格遵循當時實行的變動紅線，必須作到有灰度、有監控、可回滾
• 按照各方依賴順序發佈

  • 通常被依賴方先發布
  • 若是有影響線上的改動，不兼容舊版一方後發佈
• 發佈後要馬上組織測試和業務方進行線上驗收
• 測試和業務方驗收經過後，發佈正式完成
• 驗收發現線上問題

  • 用戶無感知並可快速修復：修復併發布
  • 用戶無感知但沒法快速修復：和PD溝通是否走平常迭代
  • 用戶有感知並可快速修復：先回滾再修復
  • 用戶有感知但沒法快速修復：參考風險&延期中的指導

發佈後要作的事情

問題記錄

• 養成線上問題排查過程和分析記錄的良好習慣

監控&性能

• 關注監控平臺各項穩定性指標
• 關注是否有輿情反饋
• 採集性能數據，有新舊版本的須要對比先後性能變化

業務數據

• 關注線上業務數據表現，業務目標在預期時間內是否達成
• 分析業務數據：找出表現好和很差的數據維度並分析緣由

是否須要Release郵件

• 有Kickoff的項目，都須要有Release

Release郵件內容

• 業務目標完成狀況，分析業務數據闡述本身的理解

  • 例如：某個模塊點擊率提高顯著，分析是曝光下降致使仍是真實的點擊率提高
• 線上成果展現

  • 線上頁面展現
  • 改版項目，對比新舊版本頁面
• 技術成果總結
• 郵件接收人爲Kickoff郵件接收人

Last but not least

以上即《前端PM防diss指南》所有內容，也是飛豬這邊項目開發過程當中的一個縮影，若是沒有說明白的地方，歡迎評論交流，也歡迎指出不對的地方~

飛豬正在招聘前端，目前咱們在 Serverless 、微前端運營工做臺、端渲染、互動營銷、招選投搭、智能化、體驗技術、數據度量有很多建設，歡迎有能力同窗進來落地技術產生業務價值，想帶人同窗過來直接帶一個方向也是能夠的，歡迎關注微信公衆號來聯繫！

本文使用 mdnice 排版