今天我想聊一聊在產(chǎn)品需求進入正式的開發(fā)流程前我們需要做些什么？

起因是最近項目組公測「指的是功能已通過測試，服務端已發(fā)布線上生產(chǎn)環(huán)境，App端暫未提交應用市場，僅在公司小范圍內(nèi)進行正式的體驗」了新的App版本，這次的發(fā)布讓我感到非常尷尬。

關聯(lián)發(fā)布項未提前溝通

發(fā)布前，測試確認了當前版本迭代的內(nèi)容在預發(fā)和測試環(huán)境是測試通過的，準備發(fā)布線上生產(chǎn)環(huán)境，這時候項目遇到了第一個嚴重問題：優(yōu)惠券要如何生成？這個版本需要發(fā)布邀請活動，但是由于一些歷史原因，邀請活動的優(yōu)惠券需要在其他平臺上生成，并關聯(lián)至代碼中，才可以保障邀請活動的正常運行。
最后是在緊急聯(lián)系了運營人員后，確認了優(yōu)惠券規(guī)則，然后找對應平臺產(chǎn)品新建了這次活動所需的優(yōu)惠券，才解決這個問題。

配置項臨時溝通并進行配置

這個版本涉及到多項運營配置項，需要相關人員配置以后才可以在前臺有比較好的體驗。公測版本服務端發(fā)布至線上后大約3小時后，產(chǎn)品經(jīng)理才在溝通群里和相關運營溝通需要配置的項以及配置的要求，最終完成配置時間距離公測服務端發(fā)布已超過24小時，大大延后了公測的時間。

新增需求項

公測版本發(fā)布后，主要以該項目組為核心，在產(chǎn)品技術組內(nèi)進行產(chǎn)品體驗，體驗過程中發(fā)現(xiàn)一些明顯不合理的界面或邏輯問題，而這些問題理應在項目進入正式的開發(fā)流程前就應該被提出來就行修正。

需求無法被實現(xiàn)，臨時變更需求

數(shù)據(jù)埋點的需求開發(fā)工作安排在公測至發(fā)布市場階段完成，公測版本發(fā)布后，項目進入埋點需求開發(fā)，開發(fā)過程中發(fā)現(xiàn)部分埋點需求無法在當前需求基礎上完成。由于相關功能已按照現(xiàn)有需求開發(fā)完成，所以只能在現(xiàn)有功能上根據(jù)可行性調(diào)整數(shù)據(jù)埋點需求，無法同預期一樣完成數(shù)據(jù)的收集。

以上這些問題反映出在產(chǎn)品需求進入正式的開發(fā)流程前并沒有做好產(chǎn)品上線相關準備工作。

那可能有人就會問了，產(chǎn)品上線的準備工作，為什么要在進入正式開發(fā)流程前就確定呢？不是產(chǎn)品上線前做好準備就可以了嗎？

這里要區(qū)分一下具體的概念，產(chǎn)品上線前的準備工作包括兩部分：清單&執(zhí)行。

產(chǎn)品上線前的準備工作執(zhí)行動作完全可以安排在上線前進行，但是清單需要在進入正式的開發(fā)流程前就準備完畢。

這樣做的好處是什么呢？

保證需求的完整性和合理性

有種說法是，產(chǎn)品經(jīng)理和程序員是天生的宿敵。這其中最主要的原因往往是產(chǎn)品經(jīng)理交付的需求在邏輯上不夠自恰，合理性和完整性層面上容易經(jīng)受程序員全方位的挑戰(zhàn)。

如果在進入正式的開發(fā)流程前，我們可以先想好這個版本我們的目標是什么，那么就可以以終為始，根據(jù)確定的目標，再梳理要達成目標，我們需要什么樣的資源，經(jīng)過怎樣的努力，才可以達到目標。

這有點像做菜，一般情況下，我們在燒菜前，首先都會想好，我們想要吃什么菜，然后根據(jù)這個菜譜，再去準備相應食材，這樣，我們才能燒出我們想吃的菜。

當達成目標的資源和行動項都可以被拆解到清單可落地項時，基本上需求也就想清楚，想明白了。這個時候產(chǎn)品經(jīng)理交付的需求產(chǎn)物在需求的完整性和合理性上都有極大保障，即便在具體實施細節(jié)上因為某種原因無法實現(xiàn)，開發(fā)團隊也可以根據(jù)目標給出相應的技術方案去實現(xiàn)目標。

降低需求變更可能性

需求變更主要由2種場景引起：業(yè)務變更引起的變更；需求未想全面就進入開發(fā)流程引起的變更。

日常工作中，大多數(shù)變更來自于需求未想全面引起的變更。

如果在進入正式開發(fā)流程前，我們就已經(jīng)想清楚，想全面了需求的方方面面，那么將極大降低由想法不全面引起的需求變更可能性。

有序的項目管理

產(chǎn)品上線準備工作的清單整理出來后，我們就可以對這個版本有明確的認知：目標是什么？要實現(xiàn)目標我們要怎么做？etc.

結(jié)合開發(fā)團隊給出的項目計劃，我們就可以整理出上線清單，包含以下內(nèi)容：

• 非開發(fā)資源什么時間準備到位？
• 相關人員什么時間進入驗收階段？
• 相關人員什么時間執(zhí)行上線配置操作？
• etc.

有了上線清單，我們就可以對版本內(nèi)所有事情做到了如指掌，在項目執(zhí)行過程中就會比較容易把控進度和質(zhì)量，做到有序的項目管理。

在產(chǎn)品需求進入正式的開發(fā)流程前，我們應嘗試以終為始，依照最終的目標反向推導達成目標所需的資源和執(zhí)行項，補充完善產(chǎn)品需求，整理上線清單，推進項目有序、效率完成。