酷播亮新聞
誰也無法預料產品未來的發展，不可能什麼事都想得盡善盡美。
在產品工作中，我們經常會遇到這樣一種情況，等到需要搞運營或推廣活動的時候才發現缺失了必備的產品功能。 本來沒計劃的功能，又變得特別著急，即使立刻啟動開發，也已經來不及。
出現這種情況雖然可以理解，誰也無法預料產品未來的發展，不可能什麼事都想得盡善盡美。 但如果一味的以功能缺失為由拒絕需求，恐怕也有點不太現實，別人可能還會誤以為是你產品經理的能力不足。 所以就需要有一些方法來解決這樣的問題，彌補功能上的缺失。
1、用已有的功能替代
說一個我身邊的產品案例，之前我們跟別的公司合作的一個項目。 技術已經進入到開發末期，很快就要結束了，但當時跟對方的技術人員溝通一個實現方案的時候，雙方出現了一些分歧。 內容聚合頁面的背景圖不能在客戶端中寫死，也就是說只能從服務器中讀取，這樣保證圖片隨時可以更換。 可當時我們確實是把圖片放到了客戶端的文件包裡。
很不幸，由於溝通問題，彼此也都是第一次合作，對於彼此做事的方式缺少了解，這個問題暴露的太晚。 而且我們的後台也沒有讓運營人員上傳這張圖片的功能。 如果臨時修改，一來產品經理要重新設計後台功能，同時也會給技術人員增加開發量，拖延項目的上線時間，不管從哪個角度講都不合適。
可沒辦法，畢竟人家是甲方，執拗不過，我們也必須作出修改。 當時我們想到了一個折中方案，將這個頁面中排序第一的內容的封面圖作為整個頁面的背景圖，這樣背景圖會隨著內容順序的調整而變化，而內容的封面圖是從後台讀 取的，並且在後台可以修改。 這樣相當於背景圖就是從服務器中獲取，算是達到了目的，過了這個坎。
2、用H5頁面替代
用H5頁面是一種非常常見的方式，相比較APP來說H5的好處是功能和內容能夠隨時更新，即使出了錯也能很快改正。
還是拿我做過的一個項目來說，當時要新上一種新的內容，對於這種新的內容類型，已有的頁面排版設計無法很好的展示信息。 甚至是說不能突顯出內容的最關鍵信息，這對內容的銷售來說顯然是很不利的。 可要是對產品重新改版，時間會很長，如果一直等待的話，內容沒法上，也就意味著耽誤了賺錢，所以我們當時就用H5頁面作為了內容的詳情頁。
為了節省效率，還把這類頁面做成了模板，版式相同。 新上一個內容，只換一張封面圖和頁面中的文字即可。
我曾經看過一個APP，當時沒有活動中心的模塊，就用H5頁面做了一個專題的聚合頁面作為所有活動的入口。 不僅活動是H5頁面，活動列表也是H5頁面。
3、通過運營手段修改
有些功能雖然短時間內不能開發完成，但可以通過運營手段來達到目的。
舉兩個例子，一個是當時我們想對平台上售賣的產品在商品圖片上打上“折扣”的標識，吸引用戶點擊。 但是系統沒有這樣的功能，所以就用了一個笨辦法，讓設計師把“折扣”的字樣做到了圖片上，達到了目的。
其實最終效果跟我們開發功能的結果是一樣的，只是這種方式需要設計做圖，比較麻煩，而且針對少量商品的話還可以。 如果商品的數量很多，工作量很大，這種方式顯然就不可行了。
其實利用圖片表達信息這種方式在行業內也算比較常見。 之前看過一個APP，估計是想要在輪播圖上標識內容類型，這樣便於用戶知道推薦的內容是什麼類的。 本來可以在管理系統中做個功能，運營人員在後台設置後，APP的圖片上自動顯示內容類型的樣式。 或許也是由於這個功能還沒開發，所以這個APP也是把標籤做到圖片上。
我們產品中的限免功能，原本計劃是不上的，但是由於運營活動所需，這個功能又要的特別急。 所以當時我們想了一個辦法讓運營人員直接在後台把價格改為0元，等到限免時間結束後，再把價格改回來。 純人工手動的方式，雖然笨拙，但關鍵時候也確實有效。
要提醒大家的是，通過運營手段雖然能夠實現某些功能，但畢竟只是暫時的。 這種方式也會遭到運營同學的吐槽、抱怨。 長期來看還是要把產品功能做好，一勞永逸。
4、通過技術的方式補救
首先要明確技術可以補救的範圍都包括哪些：
第一點是內容數據，技術人員可以通過修改數據庫或代碼中的文字來幫你修改頁面上顯示的內容和數字。 比如說某個商品的圖片需要修改，而係統又沒有這功能，技術人員可以靠修改數據庫的方式來解決；
第二是如果某個功能已經存在，並且是從後台系統中讀取的信息，那麼靠著開發後台的功能就能達到目的。 比如說某些內容已經是從系統後台中讀取，運營人員想調整這些內容的排列順序，那麼就可以在後台中增加調序的功能實現目的。
你可以理解技術是萬能的，但如果利用技術方式進行補救的話卻不是什麼都可以實現的。 產品已經在線上了，代碼上較大的改動會有風險，容易引起別的問題。 而且這種方式非常麻煩，有時候會造成改錯的情況。 所以這種方式保留，免死金牌，輕易別使用。
#專欄作家#
雲瑞，微信公眾號：馬虎眼，人人都是產品經理專欄作家。 原片刻產品經理，6年產品人，走在內容社交產品路上，死磕產品設計，喜歡玩各種APP，玩桌球，打羽毛球，歡迎與大家交流。
本文原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議