經(jīng)常出現(xiàn)，主管領(lǐng)導(dǎo)都看到了某些信息，而該部門還沒有發(fā)現(xiàn)；或者發(fā)現(xiàn)問題后去實(shí)地調(diào)研的時(shí)候才發(fā)現(xiàn)，證據(jù)早已經(jīng)遭到破壞，難以取證、實(shí)施處罰。所以希望采購一個(gè)智能線索發(fā)現(xiàn)系統(tǒng)，能夠自動采集互聯(lián)網(wǎng)中的海量信息，利用機(jī)器學(xué)習(xí)的方法針對海量數(shù)據(jù)進(jìn)行甄別，篩選出有效線索，推送給工作人員。

安迪獲得了對方提供的一些相關(guān)資料，如下：

1. 少量以往發(fā)現(xiàn)的網(wǎng)貼線索；
2. 工作人員平時(shí)重點(diǎn)關(guān)注的幾個(gè)網(wǎng)站；
3. 部分搜索關(guān)鍵詞。

安迪在研究資料時(shí)發(fā)現(xiàn)，對方提供的關(guān)鍵詞，專業(yè)術(shù)語比較多，有些通過字面意思也難以理解，不過他也并未深究。

由于業(yè)務(wù)需要，boss要求必須在一個(gè)月內(nèi)完成產(chǎn)品的demo，指派了參與該項(xiàng)目的技術(shù)負(fù)責(zé)人擔(dān)任項(xiàng)目經(jīng)理，其他成員包括前端、后端工程師、算法、UI設(shè)計(jì)參與項(xiàng)目。

接下來，安迪開始了原型設(shè)計(jì)以及PRD文檔的寫作。經(jīng)過了幾天的忙碌，安迪產(chǎn)出了產(chǎn)品的初版原型及需求文檔，產(chǎn)品主要包含如下功能模塊：“信息采集、篩選、傳播分析、自動預(yù)警、生成簡報(bào)、用戶管理”等幾大部分。其中，在數(shù)據(jù)獲取的環(huán)節(jié)，直接采用了對方提供的關(guān)鍵詞信息和采集網(wǎng)站。

隨后，項(xiàng)目組進(jìn)行了內(nèi)部評審，產(chǎn)品經(jīng)理整體講解了該系統(tǒng)的應(yīng)用場景、設(shè)計(jì)理念以及整體的交互邏輯等等，會上，項(xiàng)目組成員針對產(chǎn)品原型和PRD文檔并未提出太多問題。最后，會議決定，砍掉了諸如傳播分析等實(shí)現(xiàn)難度比較高的功能，以確保在1個(gè)月內(nèi)完成產(chǎn)品demo。

項(xiàng)目經(jīng)理針對工作任務(wù)進(jìn)行了分解、排期，給出了初步的項(xiàng)目管理計(jì)劃，報(bào)送給領(lǐng)導(dǎo)，擇期進(jìn)行了公司管理層的產(chǎn)品及項(xiàng)目評審。領(lǐng)導(dǎo)在初步方案的基礎(chǔ)之上，提出了不少修改意見，需求調(diào)研及原型輸出的結(jié)果不太滿意。

又經(jīng)過了一系列的修改，產(chǎn)品進(jìn)入了研發(fā)階段。在此過程中，研發(fā)同學(xué)開始不斷的提出各種問題，例如信息篩選的具體規(guī)則存在沖突；導(dǎo)出文本的樣式、模板；關(guān)鍵詞搜索的匹配問題；權(quán)限管理中的細(xì)節(jié)問題等等接踵而至。

產(chǎn)品經(jīng)理經(jīng)常需要穿梭于前端、后端的工位之間，解答各種問題。其中，部分問題是在原型和文檔中已經(jīng)明確標(biāo)識的；有些問題是由于表述不清，研發(fā)同學(xué)理解存在偏差；有些問題是在UI進(jìn)行設(shè)計(jì)的過程中，沒有完全按照原型及需求文檔的功能要求，遺漏了某些功能點(diǎn)；有些問題則是產(chǎn)品設(shè)計(jì)的邏輯漏洞。

有時(shí)候，產(chǎn)品經(jīng)理與研發(fā)人員達(dá)成口頭協(xié)議修改了需求，但是并沒有在文檔及原型中體現(xiàn)出來；有時(shí)候修改了文檔，但卻沒有修改原型；在一些涉及產(chǎn)品邏輯的修改中，由于受到當(dāng)前系統(tǒng)架構(gòu)的限制，在功能上不得不做出調(diào)整，或者降低相應(yīng)的要求來契合當(dāng)前的情況。

在這個(gè)過程中，管理層也時(shí)常提出一些新的需求，并且要求在此版本中做出調(diào)整。產(chǎn)品就在不斷的調(diào)整與妥協(xié)中艱難前行，在這過程中，還出現(xiàn)了前端無法勝任工作的情況，分配的任務(wù)屢屢無法按期完成，給其他成員的工作帶來了很大的不便，拖慢了整體的研發(fā)速度。

產(chǎn)品的基本功能研發(fā)告一段落之后，測試介入項(xiàng)目，每天禪道之上都會提出很多的bug。從樣式到核心流程，種種問題暴露出來，在測試過程中，測試同學(xué)還要不斷的和產(chǎn)品經(jīng)理核實(shí)需求，因?yàn)橛行┬枨笠呀?jīng)修改，但是需求文檔內(nèi)沒有體現(xiàn)；有些關(guān)于系統(tǒng)中的極端情況，在設(shè)計(jì)過程中沒有進(jìn)行考慮；有些功能因前后端的技術(shù)限制只是實(shí)現(xiàn)了其中一部分等等情況，不勝枚舉。

時(shí)間就在不斷的抱怨、反復(fù)修改中過去了，雖然同學(xué)們每天都加班加點(diǎn)的奮斗，但是工期還是不可遏制的超了又超，以至于前期規(guī)劃的所有功能并沒有如期完成，再一次的壓縮精簡之后，發(fā)布出了第一個(gè)版本。

在將該版本提交給客戶之后，對方給予如下的回應(yīng)：

1. 采集到的垃圾數(shù)據(jù)過多；
2. 相關(guān)數(shù)據(jù)的地域分布不準(zhǔn)確；
3. 存在大量重復(fù)信息；
4. 針對數(shù)據(jù)的篩選交互體驗(yàn)較差；
5. 數(shù)據(jù)不完整；
6. 信息的更新不及時(shí)等等情況。希望可以針對以上問題進(jìn)行修改。

接下來更戲劇性的一幕出現(xiàn)了，公司由于其他項(xiàng)目人手緊張，經(jīng)過評估，該項(xiàng)目需要進(jìn)一步縮減人手，不在持續(xù)投入人力進(jìn)行迭代了。所以，后來針對篩選信息的算法一直成為制約項(xiàng)目進(jìn)行的瓶頸，對方一直不滿意，所以也就遲遲沒有立項(xiàng)的意向……

故事的結(jié)尾是這樣的，又進(jìn)行了一段時(shí)間反復(fù)的修改和接觸以后，當(dāng)時(shí)積極推動該項(xiàng)目的領(lǐng)導(dǎo)離職，公司對于項(xiàng)目進(jìn)行了重新的評估，認(rèn)為當(dāng)前的算法能力對于完成核心任務(wù)有一定的差距，對于系統(tǒng)能夠?qū)崿F(xiàn)的結(jié)果持悲觀態(tài)度，并且認(rèn)為應(yīng)用場景過于狹窄，決定項(xiàng)目暫時(shí)擱置……

the end

接下來，我們從產(chǎn)品管理和項(xiàng)目管理兩個(gè)角度，針對項(xiàng)目中的問題進(jìn)行梳理、分析，看看這個(gè)項(xiàng)目到底敗在何處？又能從中吸取何種教訓(xùn)？

一、產(chǎn)品管理

1.任何一個(gè)產(chǎn)品或項(xiàng)目，在立項(xiàng)之初，要解決的最重要的問題如下：

• 需求、應(yīng)用場景是否明確？
• 核心痛點(diǎn)是什么？
• 市場覆蓋面有多大？
• 競品的情況如何？
• 我們的產(chǎn)品有哪些優(yōu)勢，壁壘有多高？

在這些問題未解決的情況下，輕易投入研發(fā)，風(fēng)險(xiǎn)會非常大。

2. 需求分析階段亦存在明顯的缺陷，既然“要求一個(gè)月內(nèi)完成”，則必須要圍繞用戶的核心痛點(diǎn)進(jìn)行設(shè)計(jì)，一些旁支、輔助的功能，例如“自動預(yù)警、生成簡報(bào)、用戶管理”等則大可不必急于開發(fā)?？此乒δ軓?qiáng)大，實(shí)則沒有抓住用戶的核心痛點(diǎn)。

3. 產(chǎn)品設(shè)計(jì)缺乏整體規(guī)劃，科學(xué)的做法是圍繞著用戶的核心需求和痛點(diǎn)，設(shè)計(jì)出產(chǎn)品的整體結(jié)構(gòu)和功能脈絡(luò)，在提交MVP版本的同時(shí)，也為用戶提供產(chǎn)品整體規(guī)劃和迭代的方案。告訴用戶，在此基礎(chǔ)之上，我們后續(xù)還能滿足哪些需求，這種方式即可以進(jìn)一步了解對方的需求，又可以增強(qiáng)客戶對我們的信心。

4. 在案例中，產(chǎn)品經(jīng)理直接采用了對方提供的關(guān)鍵詞信息和采集網(wǎng)站，并未對客戶提供的內(nèi)容進(jìn)行深入分析。

例如：

• 提供的數(shù)據(jù)源覆蓋面是否能夠滿足需求？
• 爬取數(shù)據(jù)時(shí)，是否存在難度？
• 網(wǎng)帖線索作為標(biāo)注數(shù)據(jù)，是否能夠滿足算法需求？
• 以現(xiàn)有關(guān)鍵詞作為爬取數(shù)據(jù)的手段，是否能夠獲取到有效信息？

對于上述問題都未能進(jìn)行深入的了解，就造成了最終的垃圾數(shù)據(jù)過多、數(shù)據(jù)不完整等等情況，為產(chǎn)品失敗埋下了伏筆。

5. 安迪應(yīng)該在獲取信息不足的情況下，主動與領(lǐng)導(dǎo)及客戶方溝通，以便進(jìn)一步獲取信息，例如：可以到該部門針對業(yè)務(wù)人員進(jìn)行實(shí)地調(diào)研；請對方派人支援?dāng)?shù)據(jù)標(biāo)注；或是請行業(yè)專家提供行業(yè)背景知識。

6. 在進(jìn)行管理層評審之前，產(chǎn)品經(jīng)理最好為重要的干系人單獨(dú)匯報(bào)一下產(chǎn)品的設(shè)計(jì)意圖和功能脈絡(luò)，以便取得初步的意見統(tǒng)一，這樣在評審會上的壓力就會相對減少。

7. 在產(chǎn)品發(fā)生任何需求變更時(shí)，都要在原型及需求文檔上面體現(xiàn)出更新內(nèi)容；在修訂記錄上也要呈現(xiàn)，以便研發(fā)人員查找。

日常工作中，產(chǎn)品經(jīng)理總是抱怨，研發(fā)同學(xué)不看需求文檔。洋洋灑灑幾十甚至上百頁的需求文檔，對于研發(fā)人員來說，確實(shí)是個(gè)不小的負(fù)擔(dān)，所以我們在書寫文檔的時(shí)候，要盡量做到簡明扼要。

8. 設(shè)計(jì)產(chǎn)品的過程中，一定要明確近期目標(biāo)和長遠(yuǎn)規(guī)劃，要使產(chǎn)品的系統(tǒng)架構(gòu)滿足未來擴(kuò)展的需求，不能每次開發(fā)都推到重來。

二、項(xiàng)目管理

1.項(xiàng)目經(jīng)理由技術(shù)經(jīng)理兼職存在問題，項(xiàng)目經(jīng)理需要兼顧各方的情況和利益，通過不斷的平衡和取舍來達(dá)到最優(yōu)組合，以便更為高效的完成任務(wù)，技術(shù)經(jīng)理雖然在技術(shù)方面存在優(yōu)勢，但往往在項(xiàng)目管理方面缺乏經(jīng)驗(yàn)，在未經(jīng)專業(yè)培訓(xùn)的情況下，是很難勝任項(xiàng)目經(jīng)理工作的。

2. 在產(chǎn)品需求不明確的情況下便指定了項(xiàng)目組成員，存在較大的風(fēng)險(xiǎn)。很可能會造成資源與需求不匹配的情況。項(xiàng)目經(jīng)理要針對項(xiàng)目組成員進(jìn)行技術(shù)能力方面的評估，以便了解組內(nèi)成員是否能夠滿足需求。對于關(guān)鍵崗位還要有儲備資源，以便應(yīng)對人員變更的風(fēng)險(xiǎn)。

3. 在項(xiàng)目內(nèi)部評審時(shí)，相關(guān)的技術(shù)人員未能深入、透徹的了解產(chǎn)品的功能需求和交互邏輯。以至于在后期的開發(fā)中，還需要不斷的和產(chǎn)品經(jīng)理確認(rèn)需求——在評審階段確認(rèn)需求的重要性是不言而喻的，這時(shí)需求調(diào)整的代價(jià)是最小的。所以最好在評審之前一到兩天的時(shí)間，把文檔和原型給到項(xiàng)目組成員的手中；每個(gè)人在這期間都要仔細(xì)研究自己職責(zé)范圍內(nèi)的問題，發(fā)現(xiàn)其中的問題、是否存在技術(shù)難點(diǎn)？工期內(nèi)是否能夠完成？

4. 通過正式評審的產(chǎn)品原型、需求文檔以及項(xiàng)目管理計(jì)劃，應(yīng)該請相關(guān)領(lǐng)導(dǎo)簽字確認(rèn)，以便規(guī)范后期的需求變更。

5. 在輸出UI設(shè)計(jì)稿或者測試計(jì)劃的時(shí)候，都要有相應(yīng)的評審，以確保視覺設(shè)計(jì)、測試計(jì)劃滿足產(chǎn)品功能，真實(shí)、完整的體現(xiàn)了產(chǎn)品需求。

6. 需求變更對于IT項(xiàng)目來說，幾乎是無可避免的，所以在處理變更請求時(shí)一定要慎重，項(xiàng)目經(jīng)理需要對變更的影響、進(jìn)度、成本、效果等情況進(jìn)行綜合分析，以確定是否執(zhí)行變更。不能一味的迎合領(lǐng)導(dǎo)的需求。

7. 測試應(yīng)該在項(xiàng)目立項(xiàng)之初，就參與其中，根據(jù)文檔和原型，撰寫測試計(jì)劃，要對產(chǎn)品的功能、架構(gòu)做到充分了解。測試完畢之后輸出測試報(bào)告。

好了，針對這個(gè)虛擬項(xiàng)目的分析就告一段落了，希望我的一些觀點(diǎn)能夠起到拋磚引玉的效果，歡迎小伙伴們提出一些更有建設(shè)性的意見，大家一同探討、共同進(jìn)步。

本文由 @小建 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議