我們大多數的運營人、產品人都曾經是從執行小角色做起，我們都一直期冀著自己終有一日能成為一個獨當一面的項目owner。筆者從業經驗已有6年，現在我從自身的項目經驗和心得出發，來跟大家一起探討項目管理與實施中遇到的問題及其解決的辦法。
項目核心
作為項目負責人，我們要在項目開展之前做足充分的可行性分析，這幾個問題必須思考清楚：
- 我們的用戶對象在哪裡？他們是一個怎麼樣的畫像群體？
- 我們的商業模式是什麼？如何實現商業變現？
- 整個市場的競爭環境如何？我們的產品差異點在哪裡？
只有明確了我們的盈利模式，反向推導出我們目前這個階段要做的事情是什麼，才有利於保持項目開展過程中目標的一致性。
項目開展前期
企業內部通常都會出現資源緊缺的問題，每個部門、每個人都在爭取項目資源，因此一般來說在項目前期遇到的最大困難就是項目推動難的問題。
解決這個問題的辦法可以從這3個角度出發：
1. 邏輯和數據層面
人和人之間之所以容易出現矛盾和不解，主要是因為信息不對稱的問題。
當我們在跟產品經理溝通項目的時候，一定要跟對方交代清楚項目的業務背景：可行性分析結果（市場分析結果、用戶調研結果、商業模式）、產品規劃（產品定位、產品藍圖、用戶群體）、項目目的和目標等。以此從邏輯層面去告訴對方項目的業務合理性。
每個產品經理和技術人員手頭上可能都手握多個項目，因此他們是非常關注每個項目能帶來的業務價值。因此我們在溝通項目的時候，需要提前評估出該項目能帶來的數據化業務價值。
如果這是一個從0到1的新項目，我們需要結合市場情況去預估大概的業務數據；如果這是一個成熟的老項目，我們需要通過歷史數據去預估上線後的數據。
清晰的業務背景和明確的數據化業務價值是解決項目推動難最得力的方法。
2. 管理層層面
當你已經嘗試了邏輯和數據層面的溝通方式後，仍舊無法說服對方，那此時急需要上升到上級層面，讓上級幫你去進行部門間的溝通。當然該辦法的前提是你必須把整體的業務背景和目標與領導傳達清楚，他才有底氣跨部門幫你進行溝通。
3. 降維打擊的MVP方案
當我們在數據和邏輯層面盡力了，管理層也溝通了，可是客觀情況是項目資源的確緊缺，或者是CEO有更看重的項目，此時我們看似無計可施了。
彆著急，我們來個降維打擊！
這時候項目owner需要梳理出整個項目的板塊結構，將項目進行拆解，通過MVP（最小可行產品，Minimum Viable Product）方式，退而求其次選擇次優的方案，將較長的開發週期縮短成若干個較短的開發週期，實現快速上線、快速驗證和快速迭代。
對於用戶體驗而言，各板塊的影響力如下：
產品功能>交互設計>視覺設計
因此在建設產品時，需要先做加法，通過充分地討論，窮舉所有需求和可能性；然後再做減法，對項目進行拆解，重新調整項目需求的重要層級。
項目開發階段
當項目終於如我們所願推動起來後，你以為就高枕無憂了麼？不，還有更多問題等著你去解決！
在項目啟動後，接下來是項目的需求排期、產品的設計方案、技術的設計方案、項目的開發和跟進、項目的上線前測試和預發等，基本上每個階段都需要項目owner參與。
在這個階段中，會出現很多無法預知的問題，影響項目的正常開展，而問題的根源主要有如下4個方面。
1. 業務邏輯完整性問題
我們在提出業務需求時，可能會在某些細節層面有所缺漏，沒有把需求的整理鏈路想清楚，這時候就需要重新去完善需求細節。
2. 數據邏輯完整性問題
大多數企業都會有自己的數據後臺，而搭建數據後臺的工程量是龐大的。搭建期間會遇到非常多棘手的問題，比如數據來源不全面和不可靠、數據清洗不乾淨、數據埋點缺漏、數據統計不精準等。這時候項目owner就需要跟數據部門同事一起去進行數據來源統計跟蹤、數據清洗方式跟蹤、數據統計方式跟蹤等，找出問題的根源並解決掉它們。
3. 產品實現合理性問題
在跟技術進行技術方案設計確認的過程中，技術可能會反饋部分功能無法實現的問題。這時候需要項目owner和技術方同時進行技術調研，確認問題的本質是什麼：
- 開發成本高，需要較長開發週期。
- 技術人員開發能力不足以擔任該開發工作。
此時作為項目owner，需要了解該問題無法解決的本質是技術人員能力不足還是市場成熟度不足的，千萬不能因為技術說無法實現，項目owner就直接妥協。
作為項目owner要明白一個原則：現在沒什麼事情是解決不了的，只是成本高低的考量問題。如果的確在現階段無法以最優方式解決，則需要調整開發方式，選擇次優的技術方案；或者是跨部門進行調研，瞭解其他部門是否已有相關的功能組件可直接使用，通過跨部門整合資源降低開發成本，節省開發時間。
當我們在進行項目評審的時候，一定要將相關的人員集合到位，包括項目owner、產品經理、開發人員、測試人員、UI等，否則前期的點對點溝通極容易出現信息不對稱的問題，導致後期出現諸多的意外。
4. 測試和預發問題
項目在上線前，會經過測試和預發階段。一般測試階段是測試人員介入，在預發階段才交由給需求方介入。以我個人的經驗建議，項目owner在測試階段就該介入。
為了項目的快速上線，往往預發階段非常的短暫。假若是產品bug的問題，技術倒願意快速解決；假若是產品功能完整性與原需求不匹配，技術可能會以功能不緊急為由拖延至下期開發，否則項目owner將只能接受項目延期上線的結果。我
曾經遇到過在跟技術的前期溝通階段不存在問題，可到了測試階段才發現雙方理解有誤，因此項目owner最好是測試階段介入，瞭解產品功能開發完整性情況，確認整體情況是否與需求保持一致。而在預發階段，更多地是對細節進行調整。
項目線上階段
項目上線後，我們是否就是坐等數據上漲呢？答案是否定的。理想歸理想，產品的市場驗證才正式開始。
1. 項目效果不如預期
如果前期沒有做好用戶調研，以為小眾的用戶需求就是大眾的用戶需求，或者是遇見“倖存者偏差”，錯誤選擇調研樣本，就會出現上線的產品功能並不能很好地滿足用戶的真正需求。
也有可能由於開發時間準備不充分、需求排期不合理等，導致實現的技術功能不符合需求方預期。因此項目owner就需要在項目開發、測試和預發過程中，與產品和技術保持緊密地溝通。
2. 產品bug
技術代碼出錯、其他項目的上線對本項目的影響、測試範圍不完善等都有可能產生bug。我就曾在產品上線後，遇到過如下問題：
- 其他項目上線後，導致我的產品回退。（是不是覺得很無辜~）
- 瀏覽器兼容性測試範圍不全，導致部分瀏覽器打開我們的網頁出錯。
我們需要搭建系統預警機制，實現系統自動報警，當產品出現某些問題的時候，系統自動推送信息給相關的人員，以最快的速度解決問題，最大限度地降低產品bug的負面影響。同時我們作為項目owner，也需要頻繁地以一個用戶的角度去體驗產品，發現產品的鏈路問題，以及時常思考產品的可優化空間。只有日積月累的體驗產品，才能真正的瞭解用戶的訴求。
3. 外部平臺出現負面口碑
當產品推廣出去後，總是會出現不一樣的聲音。此時有可能因為業務體驗差或是產品體驗差的問題，導致外部平臺出現諸多負面口碑。此時對這些負面的聲音我們需要非常重視，儘可能聯繫到相關的用戶，瞭解他們的訴求，從上游去解決問題。否則後期問題可能會上升到媒體公關層面，加大了處理的成本，也失去了負面處理的最好時機。
產品是需要經過不斷地調整、測試和迭代，一個項目可能成功，也可能失敗。如果失敗了沒有關係，更重要地是對項目的覆盤。
筆者曾經在一家4A廣告公司為寶潔服務過，與他們打交道的過程中，學習到寶潔的一種精神：人需要賦予自己和團隊不斷測試和嘗試的精神。市場測試不如預期不可怕，只要從中有所總結，能夠反向推動業務反思和向前優化就是最大地價值。因此項目owner千萬不要害怕項目管理和實施過程中遇到的挫折，要敢於嘗試且懂得覆盤。
最後的話
綜合來看，對一個項目負責人的要求需要具備面面俱到的能力。能力並非一蹴而就，而是一個不斷日積月累的過程。這是我們日夜耕勞和孵化的產品，即便日不懂夜的黑，即便推動過程中遇到種種的質疑，但項目owner都不要氣餒，你要相信你們是一個團隊。
我把全文的邏輯整理成腦圖。大家如果有任何不同的意見或建議，歡迎跟我交流。
本文由 @諾將軍 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
