不知道大家有沒有這樣的經驗？當客戶提出一個需求功能時，往往講了A之後，在A的執行過程中，又不斷的出現B、C、D…等，然後就不斷的來回確認需求，搞得客戶、PM、團隊身心俱疲。
有做過網站平台的朋友，一定都會遇過一種需求，那就是「彈窗公告」，多數的客戶都會想要把「最新」、「最重要」的公告，在用戶一打開網站的時候就會跳出來，最好是滿版、顯眼、吸金，然後用戶就會點進去消費。
但是，大部分的客戶就只知道他想達到的需求及目的。於是，當PM收到這樣的需求時，就會覺得「沒問題」，這功能很簡單，應該可以做到。接下來，恐怖的故事就要開始了…。
在需求確認的過程中，PM很努力的把示意圖給客戶看，畢竟只是一個「彈窗公告」而已，有什麼難的，確認沒問題後就開始執行了。
當作出一個版本後，PM也很積極地把初版給客戶看，接下來，客戶可能就會提說：「這個彈窗公告，可不可不要只有文字，需要有圖片可以放在上面。」。當然，加張圖而已，不難，可以做到。後來，客戶又問說：「那這個圖片可不可點擊後，跳到指定的活動頁面。」，加個超連結而已，不難，可以做到。
緊接著，客戶可能又會提出說：「我可能會同時上兩個活動，所以，可以公告可不可有輪播的功能。」，這時候，工程師們應該就會炸鍋了。通常的回應都會是：「X，需求可不可以一次說清楚。」，PM此時的心情應該會是：「XX，我以為只是個彈窗公告阿。」
於是，PM再次陷入客戶與工程師的愛恨情仇之中…。
從幾年前開始，就不斷地問自己，「為什麼有些PM總是會遇到類似的問題？是因為他們不會寫code的關係嗎？還是有別的原因？要如何幫這些PM解決這樣的難題？」
還記得剛入遊戲業的前幾年，那個時期的我，對於遊戲開發的全貌還不太了解，對於團隊開發的項目一直都沒有任何的疑問，加上本身也是一位愛玩遊戲的玩家，於是開發的重點都是在遊戲本身，想的都是遊戲系統本身，像是戰鬥系統、公會系統、社交系統…等。
直到，有一次和日本製作人合作的項目，那個時候才第一次接觸到「後台」，只不過那個時候的「後台」，是希望可以讓日本的營運團隊可以方便調整遊戲設定，或是編輯道具、商品之類的功能。這也是第一次對於「後台」有了初步的概念和了解。
後來，因為自己在遊戲研發已經有約8年的經驗，於是想轉換跑道，去接觸遊戲營運，想看看營運單位都是怎麼運作的。在那個時候，雖然沒有直接碰觸到營運產品的操作，但是卻讓我開了一個眼界。原來在營運的世界，有一個專門在管理產品網站的後台，做的功能就是發公告、上Banner、看留言…等。另外，還有一個後台是在做遊戲設定管理的後台，可以即時調參數、盯數據、看統計。
因為以往在開發遊戲時，著重的都是「遊戲本身」，從來沒去認真思考過「遊戲後台」。也因為這個轉換營運單位的經驗，讓我對於產品的設計有了更完整的體悟。
以目前自己在經營的部落格來說，這個畫面就是所謂的「前台」，主要的面向是「用戶」，主要是讓用戶閱讀文章的地方，畢竟定位是部落格。
而這個部分就是所謂的「後台」，主要的面向是「管理者」，目的是要用來管理文章、看各種統計，以及網站設定的地方。
而「前台」與「後台」的關聯如下，「管理者透過後台輸入資料，儲存至資料庫，會員透過前台讀取資料庫，進行觀看。」
當有了「前台」與「後台」的概念後，讓我們重新想想一開始的「彈窗公告」的需求。把「最新」、「最重要」的公告，在用戶一打開網站的時候就會跳出來，最好是滿版、顯眼、吸金，然後用戶就會點進去消費。
- 「最新」、「最重要」的公告：
- 背後的需求 -1：我的公告不是只有一則，而是會有很多則，會需要有一個公告的編輯管理工具，可以讓我新增、修改、刪除公告。
- 背後的需求 -2：然後想要可以顯示「最新」、「最重要」的公告，所以延伸的功能應該就會是「排序」與「時間」，可能依據時間排序，也有可能依據重要性來排序。因此，管理者需要可以設定「公告的時間」或「重要度排名」。或許還有可能要把最重要的公告打個「星星」，最新的公告寫個「New」。
- 背後的需求 -3：「公告顯示的時間」或「重要度排名」的優先序，是先依據時間排序，再依重要度排序；還是先依重要度排序，再依時間排序？還有一種狀況會是，當時間與重要度都一樣時，哪個公告會優先顯示？
- 用戶一打開網站的時候就會跳出來：
- 背後的需求 -1：公告顯示的時機點，或許需要可以提供管理者，指定公告顯示的時間點，例如：12:00:00強制彈出公告視窗，緊急通知用戶「重要訊息」。
- 背後的需求 -2：公告顯示的頻率，或許管理者也想要設定每一次打開網站都會跳出來嗎？還是每天的第一次開啟才會跳出來？還是可以讓用戶點選「本日不再顯示」或是「1小時內不再顯示」？
- 最好是滿版、顯眼、吸金：背後的需求可能不只是文字，更有可能需要的是「圖片」或「影片」。
- 背後的需求 -1：如果需求是圖片，點擊圖片需要跳轉至指定的網頁。而這個圖片與跳轉網頁的路徑，需要可以讓管理這透過後台進行設定。
- 背後的需求 -2：如果需求是影片，影片播完或許要自動跳轉至指定的網頁。而這個影片與跳轉網頁的路徑，需要可以讓管理這透過後台進行設定。
- 然後用戶就會點進去消費：
- 背後的需求 -1：或許需要一顆「明顯的按鈕」，讓用戶知道可以點擊去消費。按鈕跳轉的網頁也需要可以透過後台進行設定。
- 背後的需求 -2：這個按鈕上面的文案，或許可以讓管理這在後台自行編輯，像是寫成「立即購買」「最後優惠中」…等，之類的。
- 背後的需求 -3：是否需要另外製作跳轉後的活動網頁。
是不是有點麻煩？一個小小的「彈窗公告」，背後需要確認的項目與細節其實比想像的更多。
很多時候，我們接收到「需求」時，往往只想到「用戶端」的呈現，尤其是越純的研發人員，越容易有這樣的狀況，因為沒有辦法想到，其實我們的面對的不只「消費者」，更多的時候是「客戶」，也就是「後台管理者」，而這些「後台管理者」的後台需求，也是需要認真思考的。
那，除了「客戶的需求」、「管理者的需求」，還有其他的背後需求嗎？
答案是：「有的」。
做任何的功能都是需要考量是否帶來價值，不然就會變成為了做功能而做功能。而這個「彈窗公告」如果附加的價值是「引導用戶消費」，那就需要額外統計「曝光率」及「轉化率」。
曝光率：究竟有多少用戶看到這篇公告，因為有可能這個公告在第7則，根本沒人看到，也不用想說會點擊了。
轉化率：究竟有多少用戶看到公告後，願意點擊跳轉到商品頁，如果根本沒人點，或許要想的「是不是文案或圖片太不吸引人了」、「連結根本就錯了」、「按鈕根本就無法點擊」…等。
也因為這樣，後台或許又會針對「彈窗公告」新增兩種統計數據「曝光率」及「轉化率」。
是不是越來越複雜？明明就只是一個「彈窗公告」，怎麼背後延伸出這麼多需求。
需求除了要想到「前台用戶的需求」，其實更多的是「後台管理者的需求」。
大家好，我是HeroMi，從事多年的遊戲及軟體專案開發，親身經歷大大小小專案開發的戰場，希望透過經驗分享，讓我們一起學習成長。
*本站所有文章未經授權，請勿任意利用、引用、轉載。
留言