本篇文章借用項目實例進行找問題和做分析，然後分爲產品管理和項目管理兩個角度進行總結。

　　項目管理的考試中，有這樣一類題型，我們俗稱“找茬兒”題。題目要求是，簡述一個項目管理的實例，讓考生在整個案例中找出問題並進行分析。

　　今天，我想借用這種形式，以一個完整的TO B產品的研發過程作爲實例，和大家探討一下，在產品設計、研發的過程中，容易出現哪些問題？從產品管理和項目管理兩個角度剖析一下這個“集大成”的失敗案例，是如何一步步走向失敗的？

　　案例詳情如下：

　　某單位智能線索發現系統

　　某日，公司（該公司爲人工智能領域的高新技術企業）副總找到產品經理安迪，告訴他公司要研發一個針對環保類問題的線索發現系統，環保部門有潛在用戶正在接觸。安迪在接到了任務後，像領導諮詢了產品的應用場景、核心需求等背景資料。

　　對方痛點是“在進行環保監管的時候，難以及時發現有效的線索。”

　　經常出現，主管領導都看到了某些信息，而該部門還沒有發現；或者發現問題後去實地調研的時候才發現，證據早已經遭到破壞，難以取證、實施處罰。所以希望採購一個智能線索發現系統，能夠自動採集互聯網中的海量信息，利用機器學習的方法針對海量數據進行甄別，篩選出有效線索，推送給工作人員。

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

　　少量以往發現的網貼線索；

　　工作人員平時重點關注的幾個網站；

　　部分搜索關鍵詞。

　　安迪在研究資料時發現，對方提供的關鍵詞，專業術語比較多，有些通過字面意思也難以理解，不過他也並未深究。

　　由於業務需要，boss要求必須在一個月內完成產品的demo，指派了參與該項目的技術負責人擔任項目經理，其他成員包括前端、後端工程師、算法、UI設計參與項目。

　　接下來，安迪開始了原型設計以及PRD文檔的寫作。經過了幾天的忙碌，安迪產出了產品的初版原型及需求文檔，產品主要包含如下功能模塊：“信息採集、篩選、傳播分析、自動預警、生成簡報、用戶管理”等幾大部分。其中，在數據獲取的環節，直接採用了對方提供的關鍵詞信息和採集網站。

　　隨後，項目組進行了內部評審，產品經理整體講解了該系統的應用場景、設計理念以及整體的交互邏輯等等，會上，項目組成員針對產品原型和PRD文檔並未提出太多問題。最後，會議決定，砍掉了諸如傳播分析等實現難度比較高的功能，以確保在1個月內完成產品demo。

　　項目經理針對工作任務進行了分解、排期，給出了初步的項目管理計劃，報送給領導，擇期進行了公司管理層的產品及項目評審。領導在初步方案的基礎之上，提出了不少修改意見，需求調研及原型輸出的結果不太滿意。

　　又經過了一系列的修改，產品進入了研發階段。在此過程中，研發同學開始不斷的提出各種問題，例如信息篩選的具體規則存在衝突；導出文本的樣式、模板；關鍵詞搜索的匹配問題；權限管理中的細節問題等等接踵而至。

　　產品經理經常需要穿梭於前端、後端的工位之間，解答各種問題。其中，部分問題是在原型和文檔中已經明確標識的；有些問題是由於表述不清，研發同學理解存在偏差；有些問題是在UI進行設計的過程中，沒有完全按照原型及需求文檔的功能要求，遺漏了某些功能點；有些問題則是產品設計的邏輯漏洞。

　　有時候，產品經理與研發人員達成口頭協議修改了需求，但是並沒有在文檔及原型中體現出來；有時候修改了文檔，但卻沒有修改原型；在一些涉及產品邏輯的修改中，由於受到當前系統架構的限制，在功能上不得不做出調整，或者降低相應的要求來契合當前的情況。

　　在這個過程中，管理層也時常提出一些新的需求，並且要求在此版本中做出調整。產品就在不斷的調整與妥協中艱難前行，在這過程中，還出現了前端無法勝任工作的情況，分配的任務屢屢無法按期完成，給其他成員的工作帶來了很大的不便，拖慢了整體的研發速度。

　　產品的基本功能研發告一段落之後，測試介入項目，每天禪道之上都會提出很多的bug。從樣式到核心流程，種種問題暴露出來，在測試過程中，測試同學還要不斷的和產品經理覈實需求，因爲有些需求已經修改，但是需求文檔內沒有體現；有些關於系統中的極端情況，在設計過程中沒有進行考慮；有些功能因前後端的技術限制只是實現了其中一部分等等情況，不勝枚舉。

　　時間就在不斷的抱怨、反覆修改中過去了，雖然同學們每天都加班加點的奮鬥，但是工期還是不可遏制的超了又超，以至於前期規劃的所有功能並沒有如期完成，再一次的壓縮精簡之後，發佈出了第一個版本。

　　在將該版本提交給客戶之後，對方給予如下的回應：

　　採集到的垃圾數據過多；

　　相關數據的地域分佈不準確；

　　存在大量重複信息；

　　針對數據的篩選交互體驗較差；

　　數據不完整；

　　信息的更新不及時等等情況。希望可以針對以上問題進行修改。

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

　　故事的結尾是這樣的，又進行了一段時間反覆的修改和接觸以後，當時積極推動該項目的領導離職，公司對於項目進行了重新的評估，認爲當前的算法能力對於完成核心任務有一定的差距，對於系統能夠實現的結果持悲觀態度，並且認爲應用場景過於狹窄，決定項目暫時擱置……

　　the end

　　接下來，我們從產品管理和項目管理兩個角度，針對項目中的問題進行梳理、分析，看看這個項目到底敗在何處？又能從中吸取何種教訓？

　　一、產品管理

　　任何一個產品或項目，在立項之初，要解決的最重要的問題如下：① 需求、應用場景是否明確？② 核心痛點是什麼？③ 市場覆蓋面有多大？④ 競品的情況如何？⑤ 我們的產品有哪些優勢，壁壘有多高？在這些問題未解決的情況下，輕易投入研發，風險會非常大。

　　需求分析階段亦存在明顯的缺陷，既然“要求一個月內完成”，則必須要圍繞用戶的核心痛點進行設計，一些旁支、輔助的功能，例如“自動預警、生成簡報、用戶管理”等則大可不必急於開發。看似功能強大，實則沒有抓住用戶的核心痛點。

　　產品設計缺乏整體規劃，科學的做法是圍繞着用戶的核心需求和痛點，設計出產品的整體結構和功能脈絡，在提交MVP版本的同時，也爲用戶提供產品整體規劃和迭代的方案。告訴用戶，在此基礎之上，我們後續還能滿足哪些需求，這種方式即可以進一步瞭解對方的需求，又可以增強客戶對我們的信心。

　　在案例中，產品經理直接採用了對方提供的關鍵詞信息和採集網站。並未對客戶提供的內容進行深入分析，例如：① 提供的數據源覆蓋面是否能夠滿足需求？② 爬取數據時，是否存在難度？③ 網帖線索作爲標註數據，是否能夠滿足算法需求？④ 以現有關鍵詞作爲爬取數據的手段，是否能夠獲取到有效信息？對於上述問題都未能進行深入的瞭解，就造成了最終的垃圾數據過多、數據不完整等等情況，爲產品失敗埋下了伏筆。

　　安迪應該在獲取信息不足的情況下，主動與領導及客戶方溝通，以便進一步獲取信息，例如：可以到該部門針對業務人員進行實地調研；請對方派人支援數據標註；或是請行業專家提供行業背景知識。

　　在進行管理層評審之前，產品經理最好爲重要的干係人單獨彙報一下產品的設計意圖和功能脈絡，以便取得初步的意見統一，這樣在評審會上的壓力就會相對減少。

　　在產品發生任何需求變更時，都要在原型及需求文檔上面體現出更新內容。在修訂記錄上也要呈現，以便研發人員查找。日常工作中，產品經理總是抱怨，研發同學不看需求文檔。洋洋灑灑幾十甚至上百頁的需求文檔，對於研發人員來說，確實是個不小的負擔，所以我們在書寫文檔的時候，要儘量做到簡明扼要。

　　設計產品的過程中，一定要明確近期目標和長遠規劃，要使產品的系統架構滿足未來擴展的需求，不能每次開發都推到重來。

　　二、項目管理

　　項目經理由技術經理兼職存在問題，項目經理需要兼顧各方的情況和利益，通過不斷的平衡和取捨來達到最優組合，以便更爲高效的完成任務，技術經理雖然在技術方面存在優勢，但往往在項目管理方面缺乏經驗，在未經專業培訓的情況下，是很難勝任項目經理工作的。

　　在產品需求不明確的情況下便指定了項目組成員，存在較大的風險。很可能會造成資源與需求不匹配的情況。項目經理要針對項目組成員進行技術能力方面的評估，以便了解組內成員是否能夠滿足需求。對於關鍵崗位還要有儲備資源，以便應對人員變更的風險。

　　在項目內部評審時，相關的技術人員未能深入、透徹的瞭解產品的功能需求和交互邏輯。以至於在後期的開發中，還需要不斷的和產品經理確認需求。在評審階段確認需求的重要性是不言而喻的，這時需求調整的代價是最小的。所以最好在評審之前一到兩天的時間，把文檔和原型給到項目組成員的手中，每個人在這期間都要仔細研究自己職責範圍內的問題，發現其中的問題、是否存在技術難點？工期內是否能夠完成？

　　通過正式評審的產品原型、需求文檔以及項目管理計劃，應該請相關領導簽字確認，以便規範後期的需求變更。

　　在輸出UI設計稿或者測試計劃的時候，都要有相應的評審，以確保視覺設計、測試計劃滿足產品功能，真實、完整的體現了產品需求。

　　需求變更對於IT項目來說，幾乎是無可避免的，所以在處理變更請求時一定要慎重，項目經理需要對變更的影響、進度、成本、效果等情況進行綜合分析，以確定是否執行變更。不能一味的迎合領導的需求。

　　測試應該在項目立項之初，就參與其中，根據文檔和原型，撰寫測試計劃，要對產品的功能、架構做到充分了解。測試完畢之後輸出測試報告。

　　好了，針對這個虛擬項目的分析就告一段落了，希望我的一些觀點能夠起到拋磚引玉的效果，歡迎小夥伴們提出一些更有建設性的意見，大家一同探討、共同進步。

　　本文由 @小建 原創發佈於人人都是產品經理。未經許可，禁止轉載

　　題圖來自 Unsplash ，基於 CC0 協議目標和長遠規劃，要使產品的系統架構滿足未來擴展的需求，不能每次開發都推到重來。