從事遊戲軟體開發至今已經要邁向第17年了，常常有一個感觸，就是當產品企劃或專案經理要和工程師討論需求功能時，常常會遭受到工程師無情的碾壓，產品企畫和專案經理就只能被釘在牆壁上，久久不能忘懷，如果是專案經理的話，還可以找個理由說這需求是老闆的、客戶的，我們要想辦法解決老闆和客戶的困難，但是，如果是產品企畫的時候，經常會收到工程師無情的回饋「做不到」「不可能」，多半的原因都是產品企畫不懂技術，於是無法用技術的語言和工程師溝通。
其實很多時候，連工程師自己在討論事情的時候，也常常會吵架，這時候已經不是技術知識的問題了，而是每個工程師過去的經驗，讓他們下了這樣的判斷，於是指正對方說，對方的方式不行，我的才是正解。為什麼會有這樣的狀況發生呢？
簡單假設一個情境，團隊內有兩位資深工程師，一位是擁有20年長年接案經驗的工程師，一位是擁有20年大型系統開發及導入的工程師，這時候遇到一個客戶需求的時候，會發生什麼事？
擁有接案經驗的工程師想得會是在有限時間內，用盡各種手段，完成專案目標。
擁有大型系統開發經驗的工程師，則會追求系統穩定，穩紮穩打，用盡各種資源，把專案做到最好。
於是這兩位工程師就吵架了，因為在各自專業的背景上，想要滿足的目的其實天差地遠，其實沒有對或錯。兩者的想法也都是對的。
再假設另一個狀況。有一個新的專案剛開始啟動，於是團隊用最快的方式打造了一個專案的Prototype，於是專案經理就跑去和老闆報告，老闆覺得相當滿意，於是希望團隊可以加速完成，時程上又不允許團隊重新打底層的話，實務上很多時候都會妥協用這個Prototype當基礎，繼續往下開發。然後因為要加速完成，增加團隊人力的訴求也會不斷被拿出來討論，因為工程師很長說的一句話「啊，就沒人阿!!」，所以PM就會用盡各種方式把人補齊，不論是招募、從其他單位調派，都是很有可能發生的。
這個時候就會蹦出另一個問題了，新加入的成員會開始反應為什麼這個底層架構會這樣寫，為什麼Code會這麼髒，為什麼這些參數要寫死，為什麼，為什麼，為什麼…有無止盡的為什麼。
接下來團隊的舊成員與新成員就吵架了。
上面這兩個是工程師與工程師之間的經典案例，幾乎每一個專案都會發生上面的狀況，其實看久了，也習慣了。
那產品企畫和工程師的狀況又是如何？
當我還是一個小產品企畫的時候，常常聽到的狀況是這樣，工程師最常抱怨產品企畫的事情是「這個需求就做不到阿」、「目前機制沒有這功能」、「這個做了會有問題」…下略100種做不到的回應。於是，產品企畫就會一頭霧水，這個功能不是很簡單嗎？這個功能有這麼難嗎？為什麼會做不到？「肯定工程師不想做啦」，「工程師只想挑簡單的做啦」，「工程師技術能力太差」…換產品企畫內心有100種工程師不做的小劇場，其實專案經理也是會有類似的小劇場。
所以，產品企畫/專案經理與工程師的戰爭，也是每天每天不停的上演。
那這樣的狀況該怎麼應對呢？
不得不說，「系統分析與設計」是一個軟體開發的產品企畫或專案經理都建議要學習的硬知識。但是也不用覺得很可怕，主要需要學習的項目有以下幾個：
1. 流程圖
2. 循序圖
3. 資料庫
這三個項目最主要的目的都是用來進行溝通用的，當然不要淪落到是不是一定要用很精確的用圖規範，當然有些工程師會很堅持一定要用很正確的圖示，不過我們只是一個小小的產品企畫和專案經理，並非專業的系統架構師或軟體開發工程師，所以出發點是要釐清需求，消除認知上的落差。
簡單介紹一下什麼是流程圖，繪製流程圖的目的，主要是要和團隊成員說明本次要開發的功能他的流程，流程圖的繪製有一些基本的原則，不過這邊只是要介紹一下而已，並不會解釋說要怎麼畫流程圖。
上圖為一個很常見的手機遊戲的登入流程，當然每家遊戲或是產品的流程都會不一樣，會依據實際的狀況(老闆或是客戶的需求)，進行設計，像是有些遊戲會提供試玩帳號，等你體驗過後才創正式帳號，又或者有些遊戲點開就會直接綁定手機，玩家不需要註冊就可以直接進行遊戲，像是這些都是會依據專案需求做設計。
另外，當流程圖畫出來後，也才會清楚知道，原來從啟動遊戲開始，就會有一連串的動作，像是更新最新資料、帳號是否凍結…等等，有這樣的流程圖後，才有辦法回答工程師一連串的問題。
至於什麼是循序圖？循序圖其實比較少聽到，除非學生時期就是學軟體開發的，不然應該很少會接觸到這個部分，那為什麼需要學習循序圖呢？在10多年前的軟體開發，著重在安裝類型的應用程式，就好比是Wondows Office 2010，可是現在很多軟體都向網頁化，也就是透過瀏覽器，如：Chrome, Firefox，就可以直接執行軟體的功能，就像Google 雲端文件，不需要安裝應用程式就可以在網頁上編輯文字、進行Excel的試算，或是做簡報。於是，在軟體開發上的分工就越來越重視前端與後端的專業分工，以往的全端工程師的方式，就變得比較辛苦。那循序圖的概念，就是用來讓工程師更清楚知道哪些項目在前端處理，哪些部分在後端執行。舉例來說，如果我要呈現一個月統計報表的結算，應該要如何處理？
(1) 由後端將所有的資料傳送到前端，在由前端進行統計，並顯示在畫面上。
(2) 由後端將所有的資料進行統計後，將結果傳送至前端，並顯示在畫面上。
答案應該會是後者，後端主要負責所有的邏輯運算、資料處理，前端主要是畫面及資訊的呈現，前端盡量要減少資料的運算處理。
但是你知道的，有些時候，事情都不會如預期的進行。因為資料處理、運算其實蠻麻煩的，所以有些工程師會推拖這件事，後端的會說那是前端要做的事情，前端會說這是後端要做的事情，於是兩邊都不想做，另外有一種狀況就會是，後端工程師說這是前端要做的事情，前端工程師的經驗比較不足或是不想發生爭執，就會變成前端工程師默默處理掉，但是，往往BUG就會這樣毫不留情地跑出來。因此，透過循序圖，可以有效的定義出前後端工程師各自需要處理的部分，當然這依然免不了工程師們的一陣激烈的碰撞，但是，用視覺化的圖像呈現，比較容易讓工程師們聚焦在要處理的項目上。
(圖二) 是一個遊戲很基本的盈虧報表，主要顯示的內容是每款遊戲每個月的儲值金額，或是消耗的點數。在(圖二)的畫面中有兩個部分，一個是表格內每個遊戲的數據資料，一個是這個表格的統計資料，因為這個表格內有兩種數據，所以統計結算的部分就不會全部都由前端處理或是後端處理。
(1) 表格內的資料：由後端統計，因為是結算該月份的資料，常見的做法就是會指定一段時間，例如凌晨3:00的時候，交由系統去統計，並將結果存在某一個資料表中，當進入該畫面的時候，就會去讀取這一個資料表的內容，顯示在畫面上。
(2) 表格外的統計：由前端統計，因為畫面上呈現幾筆資料，後端無法預先知道，例如一個頁面預設顯示20筆、50筆，還是100筆，後端不會知道，後端只會知道我這一次要了200筆資料，至於前端的顯示則會依照頁面的設定去呈現，所以頁面的統計資料就會是前端依照當下的條件去做統計。
(圖三) 是一個依據(圖二)的狀況去描述的循序圖範例，主要就呈現用戶在開啟「盈虧報表」時，前端和後端的一些溝通流程，和要進行哪些的處理。產品企劃、專案經理或是產品經理，往往可以描述(圖二)的項目，但是卻無法清楚描繪(圖三)循序圖的內容，如果可以再討論每一個頁面需求時，透過(圖三)循序圖來討論，是不是會更加清楚。
最後一個建議產品企劃或專案經理也必須理解的技能為「資料庫」，在這邊不是希望產品企劃或專案經理可以去開資料表，而是建議須具備一些概念。
如(圖四)所列，這是一個簡單的儲值紀錄，上面會有一些基本資料，像是帳戶、多少錢、時間點，所謂的資料庫就是類似這種表格的大集合，基本上有一個概念就好，如果想要深入了解，有機會再做進一步的說明。而(圖五)往往就會是懂不懂資料庫設計的關鍵差異，以上列的(圖五)來說，這是一個統計儲值的日報表，有些時候客戶或是老闆想要看到的是即時的資訊，也就是說當我現在是18:30的時候，會想要看到從00:00:00 – 18:30:00的統計資料，可是系統不可能時時刻刻在進行統計，於是這種日報表就會需要有兩種不同的處理方式，當日的資料為即時統計，過去的資料則為系統統計，這麼做的好處在於可以有效地降低系統無謂的損耗，系統可以在用戶最少使用的時段，例如凌晨5:00，進行系統排程的統計。只要產品企劃或是專案經理對於這樣開發的細節掌握不夠的話，其實會變成在「即時統計」與「系統排程統計」二選一，但是在實務上，是兩個都需要的。
「系統分析與設計」是一個軟體開發的硬知識。但是只要掌握「流程圖」、「循序圖」和「資料庫」的概念，基本上不需要學會寫程式，也可以和工程師對等的討論事情，對於軟體開發的細節可以有更高的掌握度。另外，順道一提，只要流程清楚掌握，未來開發上出現各種推來推去的BUG，只要流程畫出來，基本上問題就解了一大半，因為很多工程師都不覺得是自己的部分有問題，但是通常問題都會出在和另一位工程師做串接這件事上，共勉之。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
※本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
留言