記得有一次，在每日早上的專案例會中，進行了一次專案的Bug Review，其中有一個Bug令人印象深刻。那次的Bug是這樣的，在後台的一個報表頁面中，設定了搜尋條件，看起來搜尋出來的資訊，不如搜尋條件設定的預期，於是就被QA人員報出是Bug。
QA：「這個Bug的狀況是這樣，就是在這個頁面中設定搜尋條件後，進行搜尋，可是搜出來的資訊和設定的項目不一樣，再麻煩工程師確認一下。」
前端工程師：「這個我不知道喔，因為我就是抓後端來的資料。」
後端工程師：「不可能，我送出的資料是正確的，應該是前端抓錯資料。」
前端工程師：「不可能啦，我就是打你的API啊，抓的資料怎麼會有錯，除非你的資料本身就錯了。」
後端工程師：「我送出的資料應該是正確的，你要不要再確認一下。」
PM：「…那，我們可以怎麼確認？」
會不會覺得在鬼打牆？但是這種衝突，其實日常到不行，比較沒有經驗的PM，就會在工程師與工程師之間打轉，然後還是不知道問題出在哪邊。當然，你也可以說這些工程師怎麼都不先回去確認，要在會議上爭辯，浪費大家的時間？
但是這也是正常的，因為大多數的系統開發案，用來考核工程師的KPI，最常見的指標就是BUG，其中BUG的產出數量、BUG的修復率，還有處理BUG的時間，這幾個指標是最常用來評估工程師的產出品質。而工程師為了不要認列BUG，影響自己的KPI，可是會跟你拼命到底的。當然，有些人也會反彈說這些KPI的指標不公平，有可能因為專案的複雜度高，所以BUG的產生數量就會多，處理時間就會長，資深的工程師經驗較多，所以BUG的數量本身就會比較少，處理時間也會比較快。不過，不管怎麼調整，核心的KPI指標就是BUG的產生與修復。針對KPI的戰爭，又可以再寫一篇了(笑)。
於是，一個BUG產生後，前端工程師就說是後端工程師的問題，後端工程師就說是前端工程師的問題，就這樣把問題拋來拋去。當然也不是每個工程師都這樣，只是這樣的風景實在太常見…。
那這個時候的PM扮演怎樣的角色呢？
通常就是在前端與後端工程師間溝通協調，讓這個BUG有人可以去處理，於是各種偷拐搶騙、循循善誘，總之就是要讓工程師可以去處理BUG，而不是吵說「這BUG不是我的」。
這個時候，如果PM沒有具備一些基礎的前端與後端的概念，那會發生什麼狀況？
就是當前端工程師和後端工程師在討論時，基本上應該聽不懂他們再說什麼。什麼「拋資料」「抓資料」「打API」，工程師講得很輕描淡寫，PM在旁邊就只能乾瞪眼，心裡想著「可以講人話嗎？」。
當然這個討論也是會有一個結論。只是這個結論通常取決於「哪個工程師講得比較大聲」，而這個大聲地底氣，多半來自於「實力」、「資歷」、「年紀」，最後，還有「脾氣」。
依據工程師「實力」和「資歷」所下的結論，通常不會有太大的問題。「年紀」的話，大部分團隊成員還是會禮讓三分，所以也不會有太大問題，起碼不會有爭吵，還是會有一個方向可以去執行。而最需要花時間處理的就是「脾氣」了，當某一方的工程師脾氣上來後，要花更大的心力去處理，最後就會變成不是在解決「BUG」，而是在解決「情緒」。
也許有人會說，工程師在討論這些BUG的時候，只要有更資深的工程師在，不就解決了？很遺憾的，不是每次的BUG討論會議都會有資深工程師在，而且資深工程師也有可能會偏袒某一方。找資深工程師可能是一個解法，但是未必能解決每一次的問題。
因為在討論這些BUG的時候，負責這個專案的PM應該都會在場，這時候PM就可以扮演一個很重要的角色。
「潤滑劑」？不是
「和事佬」？不是
「即時口譯」？當然也不是
其實是「引導者」，PM的技術能力肯定比不上工程師，畢竟專業不同。但是，讓雙方重新釐清問題的方向，這點倒是做得到的。
剛剛那個狀況，其實還有後續。
PM：「不好意思，可以麻煩再試一下剛剛那個BUG嗎？我想再確認一下。」
QA：「好的。」
PM：「恩恩，我大概知道狀況了，其實剛剛QA測試了幾次，有發現到搜尋出現的資訊，似乎都沒有變過。」
QA：「好的。」
PM：「再麻煩重試一下搜尋的功能。」
QA：「好的。」
PM：「如果每次搜尋的結果都一樣的話，那可能要確認幾個方向。第一點，前端這邊送給後端的搜尋條件是否都是固定的；第二點，後端回傳給前端的資訊是不是寫死固定的，不是去資料庫取得的資料。」
前端工程師：「…好，我再回去確認一下。」
後端工程師：「好…，我們這邊也回去確認一下。」
於是這個問題就這樣解決了。
這個案例是真實發生的事情，問題本身一點都不困難，對吧？但是，為什麼這樣的狀況卻一再地發生在系統開案上？其實，在心理學上，這只是人類的「自我防衛機制」被啟動而已。加上KPI績效的催化，有些工程師在這種狀況上的反應就會非常的巨大。
那要如何成為可以「引導」前端工程師與後端工程師的PM？
當然，溝通協調的能力絕對不能少，但是還須具備一個能力，就是可以講「和工程師對話的語言」，這才能讓我們聽懂工程師在說什麼，工程師也才能聽懂我們說的。
首先，第一步就是要先知道前端與後端，在系統開發上，扮演怎樣的角色。
在《我的專案筆記 #18》搞懂客戶需求，以及需求背後的需求中，有提到「前台」與「後台」的概念，如下圖。如果還不是很清楚的，可以去看看那一篇。
不管「前台」或是「後台」，大部分都是無法直接與資料庫直接溝通。都需要透過一個「服務」，而那個服務就是所謂的「後端」，使用者看到的畫面就叫做「前端」，如下圖。
其中，「前端」與「後端」是透過「API」進行溝通，也就是進行資料交換，如下圖。
於是，以一開始的案例來說，要正確顯示「搜尋條件」的資料，會有如下圖的四個步驟。
1. 前端網頁送出的搜尋條件
2. 依據搜尋條件，對資料庫進行讀取
3. 從資料庫取得對應的資料
4. 回傳資料庫取得的資料，並在前端顯示
因為前端無法正確顯示「搜尋條件」的資料，針對每個步驟，就要去找找問題出在哪邊，舉例來說：
1. 前端網頁送出的搜尋條件，可能有問題的地方
(1) 前端是否有成功送出資料
(2) 送出的搜尋條件是否正確
(3) 後端是否有成功收到資料
2. 依據搜尋條件，對資料庫進行讀取，可能有問題的地方
(1) 針對資料庫下的指令是否正確
(2) 後端與資料庫的連線是否正常
(3) 資料庫是否有對應的資料存在
3. 從資料庫取得對應的資料，可能有問題的地方
(1) 資料庫是否有成功將資料送出
(2) 後端與資料庫的連線是否正常
(3) 後端是否有成功取得資料
4. 回傳資料庫取得的資料，並在前端顯示，可能有問題的地方
(1) 後端是否有將資料成功送出
(2) 前端是否有成功取得資料
(3) 前端是否可以成功顯示資料
也就是說，無法正確顯示「搜尋條件」的資料，需要確認上列的4個步驟，共12個部分。而這次的案例中，在第一個步驟就發現問題所在了，也算是蠻幸運的。
簡單來說，
「前端」扮演的角色，顯示畫面。
「後端」扮演的角色，處理資料。
「API」扮演的角色，前端與後端溝通的橋樑。
當然，還是有一些例外，某些時候「前端」不僅僅只是顯示畫面，有時候也是需要進行資料的統計。例如針對畫面顯示的資料進行加總計算。
「前端」的數據統計時機：畫面中顯示的數據筆數可以依據使用者調整，例如：20筆、50筆、100筆，而要針對這些數據進行即時統計，則會由「前端」計算。
「後端」的數據統計時機：需要進行大量的數據統計，且為固定時間區段的數據，例如：日報表、周報表、月報表…等。這類型的數據，則會由「後端」計算。
這樣，對於「前端」和「後端」是不是更有概念了。
不懂前後端，眼看工程師的爭端；搞懂前後端，讓你成為工程師的神隊友。
如果覺得這篇文章有幫助到你，歡迎分享給更多的朋友知道。
大家好，我是廣三(HeroMi)，從事多年的遊戲及軟體專案開發，親身經歷大大小小專案開發的戰場，希望透過經驗分享，讓我們一起學習成長。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱和分享。
留言