我們大多數(shù)的運(yùn)營人、產(chǎn)品人都曾經(jīng)是從執(zhí)行小角色做起，我們都一直期冀著自己終有一日能成為一個(gè)獨(dú)當(dāng)一面的項(xiàng)目owner。筆者從業(yè)經(jīng)驗(yàn)已有6年，現(xiàn)在我從自身的項(xiàng)目經(jīng)驗(yàn)和心得出發(fā)，來跟大家一起探討項(xiàng)目管理與實(shí)施中遇到的問題及其解決的辦法。

項(xiàng)目核心

作為項(xiàng)目負(fù)責(zé)人，我們要在項(xiàng)目開展之前做足充分的可行性分析，這幾個(gè)問題必須思考清楚：

• 我們的用戶對象在哪里？他們是一個(gè)怎么樣的畫像群體？
• 我們的商業(yè)模式是什么？如何實(shí)現(xiàn)商業(yè)變現(xiàn)？
• 整個(gè)市場的競爭環(huán)境如何？我們的產(chǎn)品差異點(diǎn)在哪里？

只有明確了我們的盈利模式，反向推導(dǎo)出我們目前這個(gè)階段要做的事情是什么，才有利于保持項(xiàng)目開展過程中目標(biāo)的一致性。

項(xiàng)目開展前期

企業(yè)內(nèi)部通常都會(huì)出現(xiàn)資源緊缺的問題，每個(gè)部門、每個(gè)人都在爭取項(xiàng)目資源，因此一般來說在項(xiàng)目前期遇到的最大困難就是項(xiàng)目推動(dòng)難的問題。

解決這個(gè)問題的辦法可以從這3個(gè)角度出發(fā)：

1. 邏輯和數(shù)據(jù)層面

人和人之間之所以容易出現(xiàn)矛盾和不解，主要是因?yàn)樾畔⒉粚ΨQ的問題。

當(dāng)我們在跟產(chǎn)品經(jīng)理溝通項(xiàng)目的時(shí)候，一定要跟對方交代清楚項(xiàng)目的業(yè)務(wù)背景：可行性分析結(jié)果（市場分析結(jié)果、用戶調(diào)研結(jié)果、商業(yè)模式）、產(chǎn)品規(guī)劃（產(chǎn)品定位、產(chǎn)品藍(lán)圖、用戶群體）、項(xiàng)目目的和目標(biāo)等。以此從邏輯層面去告訴對方項(xiàng)目的業(yè)務(wù)合理性。

每個(gè)產(chǎn)品經(jīng)理和技術(shù)人員手頭上可能都手握多個(gè)項(xiàng)目，因此他們是非常關(guān)注每個(gè)項(xiàng)目能帶來的業(yè)務(wù)價(jià)值。因此我們在溝通項(xiàng)目的時(shí)候，需要提前評估出該項(xiàng)目能帶來的數(shù)據(jù)化業(yè)務(wù)價(jià)值。

如果這是一個(gè)從0到1的新項(xiàng)目，我們需要結(jié)合市場情況去預(yù)估大概的業(yè)務(wù)數(shù)據(jù)；如果這是一個(gè)成熟的老項(xiàng)目，我們需要通過歷史數(shù)據(jù)去預(yù)估上線后的數(shù)據(jù)。

清晰的業(yè)務(wù)背景和明確的數(shù)據(jù)化業(yè)務(wù)價(jià)值是解決項(xiàng)目推動(dòng)難最得力的方法。

2. 管理層層面

當(dāng)你已經(jīng)嘗試了邏輯和數(shù)據(jù)層面的溝通方式后，仍舊無法說服對方，那此時(shí)急需要上升到上級層面，讓上級幫你去進(jìn)行部門間的溝通。當(dāng)然該辦法的前提是你必須把整體的業(yè)務(wù)背景和目標(biāo)與領(lǐng)導(dǎo)傳達(dá)清楚，他才有底氣跨部門幫你進(jìn)行溝通。

3. 降維打擊的MVP方案

當(dāng)我們在數(shù)據(jù)和邏輯層面盡力了，管理層也溝通了，可是客觀情況是項(xiàng)目資源的確緊缺，或者是CEO有更看重的項(xiàng)目，此時(shí)我們看似無計(jì)可施了。

別著急，我們來個(gè)降維打擊！

這時(shí)候項(xiàng)目owner需要梳理出整個(gè)項(xiàng)目的板塊結(jié)構(gòu)，將項(xiàng)目進(jìn)行拆解，通過MVP（最小可行產(chǎn)品，Minimum Viable Product）方式，退而求其次選擇次優(yōu)的方案，將較長的開發(fā)周期縮短成若干個(gè)較短的開發(fā)周期，實(shí)現(xiàn)快速上線、快速驗(yàn)證和快速迭代。

對于用戶體驗(yàn)而言，各板塊的影響力如下：

產(chǎn)品功能>交互設(shè)計(jì)>視覺設(shè)計(jì)

因此在建設(shè)產(chǎn)品時(shí)，需要先做加法，通過充分地討論，窮舉所有需求和可能性；然后再做減法，對項(xiàng)目進(jìn)行拆解，重新調(diào)整項(xiàng)目需求的重要層級。

項(xiàng)目開發(fā)階段

當(dāng)項(xiàng)目終于如我們所愿推動(dòng)起來后，你以為就高枕無憂了么？不，還有更多問題等著你去解決！

在項(xiàng)目啟動(dòng)后，接下來是項(xiàng)目的需求排期、產(chǎn)品的設(shè)計(jì)方案、技術(shù)的設(shè)計(jì)方案、項(xiàng)目的開發(fā)和跟進(jìn)、項(xiàng)目的上線前測試和預(yù)發(fā)等，基本上每個(gè)階段都需要項(xiàng)目owner參與。

在這個(gè)階段中，會(huì)出現(xiàn)很多無法預(yù)知的問題，影響項(xiàng)目的正常開展，而問題的根源主要有如下4個(gè)方面。

1. 業(yè)務(wù)邏輯完整性問題

我們在提出業(yè)務(wù)需求時(shí)，可能會(huì)在某些細(xì)節(jié)層面有所缺漏，沒有把需求的整理鏈路想清楚，這時(shí)候就需要重新去完善需求細(xì)節(jié)。

2. 數(shù)據(jù)邏輯完整性問題

大多數(shù)企業(yè)都會(huì)有自己的數(shù)據(jù)后臺(tái)，而搭建數(shù)據(jù)后臺(tái)的工程量是龐大的。搭建期間會(huì)遇到非常多棘手的問題，比如數(shù)據(jù)來源不全面和不可靠、數(shù)據(jù)清洗不干凈、數(shù)據(jù)埋點(diǎn)缺漏、數(shù)據(jù)統(tǒng)計(jì)不精準(zhǔn)等。這時(shí)候項(xiàng)目owner就需要跟數(shù)據(jù)部門同事一起去進(jìn)行數(shù)據(jù)來源統(tǒng)計(jì)跟蹤、數(shù)據(jù)清洗方式跟蹤、數(shù)據(jù)統(tǒng)計(jì)方式跟蹤等，找出問題的根源并解決掉它們。

3. 產(chǎn)品實(shí)現(xiàn)合理性問題

在跟技術(shù)進(jìn)行技術(shù)方案設(shè)計(jì)確認(rèn)的過程中，技術(shù)可能會(huì)反饋部分功能無法實(shí)現(xiàn)的問題。這時(shí)候需要項(xiàng)目owner和技術(shù)方同時(shí)進(jìn)行技術(shù)調(diào)研，確認(rèn)問題的本質(zhì)是什么：

• 開發(fā)成本高，需要較長開發(fā)周期。
• 技術(shù)人員開發(fā)能力不足以擔(dān)任該開發(fā)工作。

此時(shí)作為項(xiàng)目owner，需要了解該問題無法解決的本質(zhì)是技術(shù)人員能力不足還是市場成熟度不足的，千萬不能因?yàn)榧夹g(shù)說無法實(shí)現(xiàn)，項(xiàng)目owner就直接妥協(xié)。

作為項(xiàng)目owner要明白一個(gè)原則：現(xiàn)在沒什么事情是解決不了的，只是成本高低的考量問題。如果的確在現(xiàn)階段無法以最優(yōu)方式解決，則需要調(diào)整開發(fā)方式，選擇次優(yōu)的技術(shù)方案；或者是跨部門進(jìn)行調(diào)研，了解其他部門是否已有相關(guān)的功能組件可直接使用，通過跨部門整合資源降低開發(fā)成本，節(jié)省開發(fā)時(shí)間。

當(dāng)我們在進(jìn)行項(xiàng)目評審的時(shí)候，一定要將相關(guān)的人員集合到位，包括項(xiàng)目owner、產(chǎn)品經(jīng)理、開發(fā)人員、測試人員、UI等，否則前期的點(diǎn)對點(diǎn)溝通極容易出現(xiàn)信息不對稱的問題，導(dǎo)致后期出現(xiàn)諸多的意外。

4. 測試和預(yù)發(fā)問題

項(xiàng)目在上線前，會(huì)經(jīng)過測試和預(yù)發(fā)階段。一般測試階段是測試人員介入，在預(yù)發(fā)階段才交由給需求方介入。以我個(gè)人的經(jīng)驗(yàn)建議，項(xiàng)目owner在測試階段就該介入。

為了項(xiàng)目的快速上線，往往預(yù)發(fā)階段非常的短暫。假若是產(chǎn)品bug的問題，技術(shù)倒愿意快速解決；假若是產(chǎn)品功能完整性與原需求不匹配，技術(shù)可能會(huì)以功能不緊急為由拖延至下期開發(fā)，否則項(xiàng)目owner將只能接受項(xiàng)目延期上線的結(jié)果。我

曾經(jīng)遇到過在跟技術(shù)的前期溝通階段不存在問題，可到了測試階段才發(fā)現(xiàn)雙方理解有誤，因此項(xiàng)目owner最好是測試階段介入，了解產(chǎn)品功能開發(fā)完整性情況，確認(rèn)整體情況是否與需求保持一致。而在預(yù)發(fā)階段，更多地是對細(xì)節(jié)進(jìn)行調(diào)整。

項(xiàng)目線上階段

項(xiàng)目上線后，我們是否就是坐等數(shù)據(jù)上漲呢？答案是否定的。理想歸理想，產(chǎn)品的市場驗(yàn)證才正式開始。

1. 項(xiàng)目效果不如預(yù)期

如果前期沒有做好用戶調(diào)研，以為小眾的用戶需求就是大眾的用戶需求，或者是遇見“幸存者偏差”，錯(cuò)誤選擇調(diào)研樣本，就會(huì)出現(xiàn)上線的產(chǎn)品功能并不能很好地滿足用戶的真正需求。

也有可能由于開發(fā)時(shí)間準(zhǔn)備不充分、需求排期不合理等，導(dǎo)致實(shí)現(xiàn)的技術(shù)功能不符合需求方預(yù)期。因此項(xiàng)目owner就需要在項(xiàng)目開發(fā)、測試和預(yù)發(fā)過程中，與產(chǎn)品和技術(shù)保持緊密地溝通。

2. 產(chǎn)品bug

技術(shù)代碼出錯(cuò)、其他項(xiàng)目的上線對本項(xiàng)目的影響、測試范圍不完善等都有可能產(chǎn)生bug。我就曾在產(chǎn)品上線后，遇到過如下問題：

• 其他項(xiàng)目上線后，導(dǎo)致我的產(chǎn)品回退。（是不是覺得很無辜~）
• 瀏覽器兼容性測試范圍不全，導(dǎo)致部分瀏覽器打開我們的網(wǎng)頁出錯(cuò)。

我們需要搭建系統(tǒng)預(yù)警機(jī)制，實(shí)現(xiàn)系統(tǒng)自動(dòng)報(bào)警，當(dāng)產(chǎn)品出現(xiàn)某些問題的時(shí)候，系統(tǒng)自動(dòng)推送信息給相關(guān)的人員，以最快的速度解決問題，最大限度地降低產(chǎn)品bug的負(fù)面影響。同時(shí)我們作為項(xiàng)目owner，也需要頻繁地以一個(gè)用戶的角度去體驗(yàn)產(chǎn)品，發(fā)現(xiàn)產(chǎn)品的鏈路問題，以及時(shí)常思考產(chǎn)品的可優(yōu)化空間。只有日積月累的體驗(yàn)產(chǎn)品，才能真正的了解用戶的訴求。

3. 外部平臺(tái)出現(xiàn)負(fù)面口碑

當(dāng)產(chǎn)品推廣出去后，總是會(huì)出現(xiàn)不一樣的聲音。此時(shí)有可能因?yàn)闃I(yè)務(wù)體驗(yàn)差或是產(chǎn)品體驗(yàn)差的問題，導(dǎo)致外部平臺(tái)出現(xiàn)諸多負(fù)面口碑。此時(shí)對這些負(fù)面的聲音我們需要非常重視，盡可能聯(lián)系到相關(guān)的用戶，了解他們的訴求，從上游去解決問題。否則后期問題可能會(huì)上升到媒體公關(guān)層面，加大了處理的成本，也失去了負(fù)面處理的最好時(shí)機(jī)。

產(chǎn)品是需要經(jīng)過不斷地調(diào)整、測試和迭代，一個(gè)項(xiàng)目可能成功，也可能失敗。如果失敗了沒有關(guān)系，更重要地是對項(xiàng)目的復(fù)盤。

筆者曾經(jīng)在一家4A廣告公司為寶潔服務(wù)過，與他們打交道的過程中，學(xué)習(xí)到寶潔的一種精神：人需要賦予自己和團(tuán)隊(duì)不斷測試和嘗試的精神。市場測試不如預(yù)期不可怕，只要從中有所總結(jié)，能夠反向推動(dòng)業(yè)務(wù)反思和向前優(yōu)化就是最大地價(jià)值。因此項(xiàng)目owner千萬不要害怕項(xiàng)目管理和實(shí)施過程中遇到的挫折，要敢于嘗試且懂得復(fù)盤。

最后的話

綜合來看，對一個(gè)項(xiàng)目負(fù)責(zé)人的要求需要具備面面俱到的能力。能力并非一蹴而就，而是一個(gè)不斷日積月累的過程。這是我們?nèi)找垢麆诤头趸漠a(chǎn)品，即便日不懂夜的黑，即便推動(dòng)過程中遇到種種的質(zhì)疑，但項(xiàng)目owner都不要?dú)怵H，你要相信你們是一個(gè)團(tuán)隊(duì)。

我把全文的邏輯整理成腦圖。大家如果有任何不同的意見或建議，歡迎跟我交流。

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

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