起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何寫好一份項目可行性報告？
在多數公司中，開始做一個項目前都需要準備一份項目可行性報告，告訴領導項目的機會、風險如何，同時需要哪些資源。那這個報告由哪些部分組成，如何準備？來看看作者的分享。
一、為何要寫項目可行性報告
項目可行性報告，相信各位日常工作中聽得不少，寫得更多。在講如何寫好這樣一份報告之前，我們先來搞搞清楚，為什么要寫這么個項目可行性報告？
到底是形式主義還是真有必要？
至少在筆者看來，是真有必要。
首先，我們來明確一下，項目可行性報告是項目可行性分析這項工作完結時所要交付的一個結果性文件，它的內容直接指向經過分析最終形成的結論。那么，一般在什么時候會開啟“項目可行性分析”這項工作呢？
沒錯，當企業或某個團隊有一些想法，甚至一個念頭，需要全方位科學地判斷某件事該不該干、可不可干的時候。
至此，我們就可以明確，項目可行性分析是為了獲得一個問題的答案而存在的，這個問題是：某件事該不該干、可不可干？
而要得到該問題的答案，不是拍腦袋定的，而是需要經過一系列科學嚴謹的業務分析活動，包括：信息收集、內外部調研、信息整合與分析等。
接下來，這項工作的重點便可以翻譯為：為了科學準確地判斷出項目可行性，如何設計和開展調研工作，需要拿到什么關鍵結果？如何拿到？
二、業務調研
要知道一個項目/業務該不該干，須得先摸清楚業務的現狀、目標、可行性和投產比等一系列事宜，也就是先做好業務調研。那么，開展業務調研工作是不是一個猛子扎進去，直接找到相關業務方做溝通訪談，干就完了呢？不是的。
業務調研也是要有章法的，所謂謀定而后動。在開展具體的業務調研工作之前，需要先制定業務調研的計劃，明確業務調研目標(包括內外部目標要區分開來)，被調研對象，時間計劃等。此外，整個業務調研需要基于方法論先搭建框架，再通過具體的調研過程填充血肉，帶著目的和問題去調研，在調研過程中捋清事實找答案，最終形成可以回答目標問題的結論。
1. 業務調研核心成果——業務流圖
完成業務調研后繪制的業務流圖一定可以被稱為整個調研工作成果的靈魂，亦是整個項目可行性報告的“報眼”之一。
以B端產品經理的工作為例，開展業務調研是做某個業務系統產品規劃和方案設計的必備前置工作項，通過業務調研梳理出完整的業務流，才可以對應得出應規劃哪幾個模塊，每個模塊承載什么工作及各模塊間的關系，用戶主操作流/異常信息流等關鍵性信息用以指導產品設計。
再以數據產品經理的工作為例，最為關鍵的數據流同樣要依賴業務流才能整理出來。并且從站位更高的視角來看，數據價值的體現必然要從業務流和管理流中尋找可落地融合的場景和機會點，因此，即使是不直接操刀業務系統設計的數據產品經理，對業務流有完整而深入的認知也是項目成功的助推器。
2. 如何搭建業務調研框架？
接下來，我們來講講搭建業務調研框架的方法論。換句話說，一個完整的業務調研框架需要哪幾個要件？請往下看。
業務現狀
屬于對內調研的范疇，摸排清楚自己要做的業務線->企業->生態的業務現狀是必不可少的，但對于這三個不同層級對象的摸排工作細致程度的要求也是依次降低的。
對于業務現狀，我們需要通過調研結果了解到關鍵業務和期望獲取的關鍵業務結果是什么，以及目前業務是如何跑起來的。
比如某視頻平臺會員事業部的關鍵業務就是會員管理，期望獲取的關鍵業務結果有三個：1.新會員增速上升20%以上；2.老會員續費率不低于70%以下；3.會員粘性日均提升0.1h。會員管理手段主要是引流、提供優質會員內容和做會員權益成長體系。
痛點問題
摸排清楚業務現狀之后，我們就需要分析并梳理出現狀中存在的痛點和問題，并明確這是當下亟待解決的問題還是當下并不凸顯但可能在未來帶來不利甚至致命打擊的問題。
我們也需要對痛點問題進行分類，比如哪些是組織缺位，哪些是能力缺失，哪些是流程規范性滯后或不匹配等。不同類型的問題有不同的最優解法。不宜一概而論，宜分類討論，各個擊破。
業界做法
屬于外部調研的范疇，在搞清楚自己企業的相關業務領域現狀和痛點問題后，也先別急著一股腦輸出需求索要排期接著直接開干，這樣做是體現了極強的執行力，但可能用的是蠻力，也可能不是全局最優解決方案，最終一算投產比，不劃算。對于已經明確的痛點問題清單，除了根據業務上的緊急程度和價值來評定優先級外，還可以同時采用的辦法就是外部調研。
有句話叫做，太陽底下沒有新鮮事。我們要知道，當前我們所面臨的問題，很可能不是獨一份的。可能別的公司早已出現過并解決了。那么我們就可以站在巨人的肩上來尋找最有效最省力的辦法。
磨刀不誤砍柴功，多研究相似業務場景和問題背景下的業界做法，仔細分析其中的差異點，能夠起到很好的方向指引和借鑒作用。
理想架構
在了解清楚業務現狀和目標后，針對梳理好的反映現狀的業務流圖，可以改一版理想中的業務流圖出來，對照來看，分析目前差距在哪里，是否能補齊等。
比如，在發票單據管理這個場景下，業界最優并且也是目前理想的做法是，對接訂單系統拉取必要信息自動化生成單據，并執行每日自動化校驗，對于不一致單據或有漏掉的單據缺失等情況做糾正或告警。而業務現狀中的做法是人工拍照上傳紙質單據再手動綁定訂單。
需求分析
基于痛點和問題轉化為需求，將提取出來的需求整理成清單，進行相應的分析，包括初步解決思路、需求價值、優先級等。
對于需求價值可以專門提出來說一說，可以用四象限法來輔助判定需求價值。X軸可設定為緊急程度，Y軸可設定為重要程度，業務層面亟待解決但也僅僅針對當下業務情境，而不具有長遠可持續性的問題可以歸類為緊急不重要需求；而對于當下問題未凸顯不尖銳但隨著業務規模高速增長，在可預見的未來會產生巨大價值和前瞻性紅利的需求，依據時間窗口特性、實際資源及項目周期等情況，可歸類為緊急且重要或重要不緊急需求。
解決方案分析
統合需求清單，站在整體解決方案的角度對需求進行合并同類項、依賴關系識別綁定、不可行需求剔除等處理，形成有限幾個整體性解決方案(如A、B、C)，明確每一種解決方案的技術目標。
可行性結論
對每一種解決方案的技術目標和最終提供的功能與業務目標進行對標匹配，得出是否具有整體可行性的結論。
路徑推薦
對于具備可行性的解決方案，再基于實現難度、項目周期、成本投入(人員及資金投入)和項目長短期收益(如?解決當前業務痛點問題/完成初級智能算法能力建設等)，給出帶有優先級和優劣勢說明的路徑(解決方案)推薦，目的在于陳清利弊，便于決策。
三、技術調研
要知道一個項目/業務可不可干，即?是否在實現上具備可行性，則是要做好技術調研。技術調研的最終成果要能夠回答兩個問題：
- 這個項目在技術實現上是否可行？什么時候可行？
- 要落地該項目，并實現技術目標，需要多大投入？最小可行性版本如何？高含金量版本又如何？
要弄清楚以上兩個問題，不同角色的人開展技術調研，方式和側重點也會有所不同。
1. 產品經理做技術調研
產品經理做技術調研，目的主要在于通過了解在目前已較為成熟的技術領域是否有先行案例來判斷技術上的可行性。通常包括研究業界實踐案例和現成的商業化產品白皮書等方式開展工作。對于有外采意向的項目，產品經理要做的技術調研其實就更類似于選型分析了，不僅需要仔細研究意向商業化產品的功能、與需求的匹配度、用戶上手難度等，還需與供應商溝通如報價、培訓、定制化開發等事宜，從而完成綜合評估。
2. 研發人員做技術調研
而研發人員去做技術調研，更多地是出于實現需求的目的，比如可能會去開源社區尋找可用/可改造的“輪子(單元性程序代碼)”等。
四、碎片化信息整合
1. 過程性文檔管理
不管是針對內部開展的問卷式、訪談(座談)式調研，還是帶著問題在外部閱讀各種資料尋求經驗與答案，都應該有過程性文檔的沉淀。而這些過程性文檔就可以視為碎片化信息，是非常重要的。但又不是都重要，這就需要我們對信息進行去偽存真，重點標注，前后聯系等工作，將碎片化信息進一步消化后形成信息精華，用于最終的報告編寫。
2. 有邏輯地重構串聯
最后，必須要強調的是，項目可行性報告絕對不可以是碎片信息的拼湊堆砌，而應該是以符合認知習慣的、強邏輯性的方式組織串聯并呈現出來，類似于上學時寫的議論文，但又要結合金字塔原理，做到：結論先行，論點分明，論據充分合理。
五、結語
不管是項目可行性報告的撰寫還是項目可行性調研工作的規劃與開展，都是一門很深且很有意思的學問，值得我們職場打工人不斷精進，在實干中鉆研，鉆研成果繼續服務于實干，愿各位都能成為項目領域的邏輯專家，表達能手。
本文由 @maggieC 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
