項目開發過程中，你懂得靈活決策嗎？

副標題：0歲PD的項目開發動態管理經驗（強行拗了個詞，哎呦好高大山的感覺）

因畢業答辯，我提前擬定好了項目開發的計劃，給開發同學交代清了需求，放心回了學校：

先做「正式版」的【課程模塊】；同期另一位小夥伴做「乞丐版」的【適配首頁模塊】。

等快回公司的時候，跟開發的同學在微信上隨便聊了幾句，才發現之前定的計劃被部門的小夥伴調整了一下，變成：

【適配首頁模塊】從「乞丐版」直接晉陞為「正式版」；之後再做「正式版」【課程模塊】。

當時我就懵逼了，不是很理解調整的原因——

一層背景是：因為開發資源緊缺，我請求另一位小夥伴先做個「乞丐版」的【適配首頁模塊】，能配合馬上要發布的新版APP做運營。先跑起來，之後再解決美不美觀、好不好用的事；

二層背景：運營同學在「乞丐版」的後台時，會時不時地出現操作上的失誤，比如配置課程的時候忘記填寫價格、不知道如何添加課程小節等。如果這些失誤放到接下來的商業嘗試中，對於內容提供商與合作者來說，可能會發生不必要的麻煩。

嘶......怎麼看這個安排也恰到好處的呀，怎麼說變就變了？

之後，經過智琪的幾句開導，我發現，在這個原始安排中我忽略了後台開發與App之間配合的時間維度。

一、理清現狀

①因為開發資源被優先順序更高的H5活動佔領5天/人，開發後台模塊不得不整體後推1周；②從此時到新版App上線只有8天/人的工作時間，這8天/人得調整開發的優先順序與公司整體進度配合、契合；③在這一階段，開發的主要選項有：【課程模塊】、正式版【首頁配置頁面】、【訂單模塊】；

二、深入分析

①先解決「有」的問題，優先順序上【首頁配置頁面】與【訂單模塊】>【課程模塊】；②【首頁配置頁面】與【訂單模塊】都沒有，但由於目前處於商業化嘗試階段，內容必須撐起產品的門面，那麼保證【課程模塊】的容錯率就使得它的優先順序>【訂單模塊】；③對於「正式版」【首頁配置頁面】與【課程模塊】的分析，就是一個要再討論的問題了！

1、改變後的效率提升上來看

可引入一個邏輯模型：

效率提升量=單次使用效率的提升*使用頻次

①前者得在運營人員具體使用中才能體會，跟產品的性能、設計各方面都相關；②當我們的沒法評估前者時，看使用頻次也是一種好方法！③得出的結論是：配置首頁與配置課程，在使用頻次上都是每天使用的級別，【首頁配置頁面】、【課程模塊】應屬於「P0」這個最優先的主幹功能模塊，即使有使用頻次的差異，也是微小且毫無意義的對比。

所以，我們這一項對比就不太行得通，但是這個思維的過程，非常重要。

2、從deadline來分析

新版App發布為我們製造了一個deadline，這8天/人開發時間內各模塊的估算是：

【課程模塊】20天/人「正式版」【首頁配置頁面】5-8天/人【訂單模塊】5天/人

綜上，在deadline之內，我們有且只有選擇「正式版」【首頁配置頁面】來作開發，其次是【課程模塊】（這一階段可以通過人工監督來盡量減少失誤），最後才是等新版App上線1-2周左右才開始用的【訂單模塊】。

之後，智琪還點了一句：

早完成早使用，盡量避免重建部分工作量浪費。

當然，還有各種各樣的因素影響者決策，so...在資源緊缺的條件下做出對的決策，是產品經理的必修課，fighting~

該分析方法適用於：開發資源緊缺的條件下（或以職能劃分的產品團隊中）。6月1日 凌晨

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！