# EP10 - 向前一步(Lean In)

## 本集介紹

討論主題：向前一步(Lean In)

短述：在協作的過程中，大家都身兼多職，難免會有認知落差不同步的狀況。「尊重專業分工」有時我們會讓我們陷入「自掃門前雪」的消極心態而不自知，**忘了大家要協作，就是為了要成就更大的目標呀**！當我們受到挫折而意志消沈，不知自己的工作為何而戰，甚至和協作的伙伴有了信任距離，只想釐清責任時，我們要怎麼再向前一步，打破僵局，克服困境呢？

## 訪談內容

### 乃宏

#### 節目介紹

大家好，歡迎來到「改變共和國」Republic Of Change。

這是一個和商用研三的 ROC 電子報連動的一個 Podcast 作品，也是我們希望帶給大家更多正能量和啟發的新嘗試。這個節目會以 ROC 週報的內容挑一個主題，請投稿的作者一起來談談在反思，觀察及改變的過程，他們觀念改變的契機，遇到的困難和拉扯，以及改變後收獲了什麼。

#### 討論主題

《挺身而進(Lean In)》是臉書首席營運長雪柔．桑德伯格(Sheryl Sandberg)於2013年出版的書，講述女性在事業上應該突破框架，向前一步，爭取成為該領域的領導者。這一集我們很榮幸的"致敬"一下這個很棒的標題。

在前兩週的週報，有一些伙伴寫到在協作中，和專案單位認知落差不同步的狀況，有時讓我們困擾，甚至讓我們心態變得消極及防衛。但他們都不讓自己就這麼陷入低潮，他們都找出了讓自己「向前一步」的方法，如果對方動彈不了，就讓自己去帶動整個協作的節奏。在春假的最後一天，我想這是個很好的題目，讓大家帶著滿滿的鬥志，迎接新的~~董事會~~人生挑戰。

#### 來賓介紹

今天的來賓是引擎組中的技術高手錦頤，我們大家通常都叫他「小葉」，等等我們也會這樣稱呼他。另外還有網頁組的網頁程式高手，來自馬來西亞的語哲。以及品檢組的宗輝。我們請他們跟大家自我介紹，簡述一下自己的職務及服務項目。

> 小葉：大家好，我是引擎組的小葉，近期都在做一些整合相關的事情。
> 宗輝：大家好，我是品檢組的阿輝，主要工作是協助商用部門的產品測試。
> 語哲：大家好，我是網頁組的語哲，來自於馬來西亞，如果等下有我表達不清楚的地方，請大家多多包含。

### 02:30 小葉 / 「想法keep在某人的腦中」這件事在協作上真讓人困擾，以你自己的經驗來看原因為何？你做出了改變，收獲了什麼效果？

> 很大部分都跟過去開發的經驗有關，可能是專案在**維護跟更新上遇到一些困難**，曾經也討論過要怎麼去解決，但可能**礙於時程以及優先度**問題，遲遲無法處理，也就沒有所謂的參考程式或是文件。

> 這也是為什麼每次我們試圖要去解決過去的問題時，專案往往能夠提供反饋卻無法提供文件。這次活動模組由於很時程較急，又需要同時解決各部門的問題。如果等專案提供資料除了時間來不及之外，在決策會議上也會因為執行人員真正問題沒有被解決，導致在決策會議前專案會有很大的反彈。

> 乃宏：永遠都有「更重要」的事情，永遠都會有「插件」，對吧？🥴

> 小葉：對，專案那邊常常都會這樣，由於研三本來就是進行整合的單位，所以內心掙扎了一下後，就決定一個一個部門去訪問並把他們的想法記錄下來，會議結束後再將這些資訊圖像化並反覆確認，同時也將各部門的反饋在去同步給其他部門知道，最後也將每個部門的想法整理到回饋表單上，最後才能夠順利將規範定版。

> 至於收穫什麼效果？就...對方會從原本兇巴巴的同事，變成和藹可親一起解決問題的同事。

> 乃宏：真的假的！？為什麼他們要兇巴巴呀？我們不是去幫他們的嗎？

> 小葉：因為製程標準化是為了後續的移植，但是標準化後對現行運行已久的專案製程會帶來衝擊。最常聽到的反饋是「猴爺的」、「研三的」、「有跟我們討論嗎？」。專案通常都希望是「自己的」，所以會有比較大的抗拒。那我們走這一步就是讓他從誰的誰的誰的變成我們大家一起的，看能不能提高認同感。

> 乃宏：宗輝，你們會需要自己去搞清楚，要測試的遊戲規格是什麼嗎？有文件嗎？如果不是常見的規格，你們會像小葉這樣，"幫"專案寫出規格嗎？

> 宗輝：關於規格這方面的問題，在產品交由我們測試之前，我們都會先和專案的編導、程式一起開一次規格說明會議，在這個會議中有參與產品開發的人員都可以對規格有疑慮的地方提出問題，大家一起進行討論，在達成共識後再由編導產出經過討論後完善的規格文件。這樣產品開發成員在開發階段也能拿來做為依據。

### 07:32 小葉 / 現實總是充滿挑戰，但你主動踏出一步，為大家畫圖，釐清脈絡以利溝通，你覺得是「吃虧」還是「增加工作量」嗎？以後你會繼續這麼做嗎？為什麼？

> 有時候問題其實不是吃虧不吃虧還是增加工作量，那個我想大家應該已經習慣了，往往都是當下的那個「感受」影響「願不願意多做」，合作交流上愉快肯定彼此都會願意多幫一些，所以踏出這一步主要是先付出，讓合作交流彼此愉快跟順暢，專案也會開始往前邁一小步，就能順利將阻力轉成助力。

> 未來應該會用這個方式去比照辦理，因為總得有人去做，不然事情一直停滯不前也會很尷尬。

> 乃宏：語哲，有時用戶會搞不清楚你們設計出來的使用流程，或是搞不清楚他們想要的使用流程，你們會用什麼方式，更進一步去打破僵局？

> 語哲：通常需求進來時大部分是會有負責的窗口做原型的流程，這個流程的好處是讓對方可以先看到一個基本的視覺呈現，然後中間會經過討論，避免搞不清楚流程的狀況發生，直到雙方都有共識的時候才會進行開發。

### 10:05 宗輝 / 雖然你發現了Bug，但專案的回應態度卻很消極，經過「轉念」你仍然更積極的找出你能協助的地方輸出，這個過程你是怎麼"轉"的？

一開始我心情是很低落的，一方面是面對問題時專案的不作為感到焦急，另一方面則是因為自責，若是產品出去之後品質不佳是否會影響到使用者對產品的評價，但越接近測試的末期我越覺得不能讓這種情況繼續下去，應該是這種壓力讓我轉而更積極去提醒專案問題，並提供更詳盡的測試資料如:Gamelog、重現影片等。最終專案正視並認為這個問題會影響產品的品質，即使產品時程延期仍決定將問題解決。

> 乃宏：看起來是一個「責任感」使然，對嗎？

> 乃宏：語哲，你會因為自己判斷這樣子的用戶體驗較好，而加入規格書沒有的檢查或功能嗎？你的想法是？

> 語哲：我覺得不會，是因為組內有設計的同仁把關這件事情，而且每當完成一項網頁的開發後，我們內部所有成員都會測試整個流程，也包含體驗的調整。

### 14:12 宗輝 / 品檢是產品品質的最後一道防線，你們的付出不見得夠明顯被看到，可你們大家還是這麼盡全力把這件事做到最好，除了你，你們其他的伙伴，都是怎麼看待自己「更進一步」的付出的？

的確，大部分的人都不會覺得品檢對於產品有多大的影響，基本上是隱
身在產業中的小齒輪，但我總是希望自己經手測試的遊戲能在市場上發光發熱。當看到自己測試的產品在市場上受到使用者好評的時候，總是感到於有榮焉。畢竟品檢組對於一款產品幾乎是從開始到結束都每一個環節都參與其中，這種成就感就是讓我繼續前進的原動力。

至於其他同事的想法，我也有問過幾個人，就稍微引述一下其中一位的想法:【公司營收成長，其中也有我們努力的成果，並且對豐收感到驕傲。】所以付出是否足夠顯眼應該不是重點，最後豐收的成果才是我們共同努力的目標。

> 乃宏：你們知道「蝴蝶效應」對吧？其實品檢關係到的不只是「玩家有沒有發現bug」或是「有沒有掉圖或崩掉」這麼單純的問題。玩家的體驗不好，反應出來的可能會是留存不好或營收不好，這就直接造成專案人員分析優化的困難(不確定是因為規格不漂亮，還是單純體驗不好？)，不是造成研發人員加班趕工，也會造成營運單位燒腦傷神。你們更進一步，可是很重要的一步。

### 15:29 語哲 / 方便跟我們分享，硬著頭皮幹到最後來回修改，那是什麼狀況呢？不是照著規格書做了嗎？問題出在哪兒呢？

我分享的這個案例比較特殊，線上沒有提供規格文件，只有技術串接文件。所以在一開始規格需求討論的時候，我沒有提出太多意見。拿到技術串接文件的第一時間就是埋頭苦幹的做，不管三七二十一，心想只要跟著文件做就不會有任何問題了。後來上了測試機，運營測試後又想改規格，所以技術文件又不斷調整，最終花了許多時間修改。

我想這邊問題出在，沒有在一開始的需求討論時，找運營或團隊的人一起做確認。因為我內心很憂慮，想著照著技術文件做就不會有錯即發生問題。

但主管其實是希望我能夠去跟運營討倫規格作確認並同步訊息。結果我沒有跟運營做規格的確認與討論，就是在測試的時候發生問題改來改去，比預期花更多時間。

其實事後想了一下，如果當初有仔細的確認規格、討論並做紀錄，確認好問題後才開發，相信這樣可以減少事後的溝通成本。這件事我們團隊也一起花了時間檢討 希望後續能改善這樣的情況。

> 乃宏：小葉，你們會遇到這個狀況嗎？照著規格做，結果還大改？

> 小葉：一直都在發生，因為常常一開始規格不會那麼明確，甚至經過幾次體驗會後，會有額外追加或大改，這種事情有時候真的檔不住，所以我們習慣分階段，而且不會把第一次規格完成當作完成，而是拆成原型階段、產品化階段、優化階段。

> 小葉：這樣心裡感受會好一點，不會覺得是完成100%被打掉重練，而是完成1/3做滾動式調整。

### 19:29 語哲 / 如果之後的合作中，你的主管"們"都覺得規格書沒問題，但你就是覺得怪怪的，你仍然會提出來討論嗎？你會怕被大家認為「很難搞」，「沒sense」，還是「蠢問題」嗎？

如果規格書已經受到大家的認同且確認沒有問題後，我自然也不會有太多的意見，但不至於完全沒意見，一旦發現規格不合理的時候就會提出自己的問題和觀點。我倒是不會害怕大家認為自己很難搞、沒sense或覺得是蠢問題，我會認為只要需求符合我們開發程式的邏輯就不會提出更多的建議。

不過後來有察覺到規格書不一定會把所有細節都寫進去，有部分沒被提到的如效能問題或是使用者的體驗，發現這些都可以被優化的，於是我就先跟組內成員提出自己的看法，討論完之後間接著和專案提出建議，最後自己的建議有被大家運用後，頓時覺得自己解開了心目中的某一個成就。如果之後在合作中遇到有問題或是那裡覺得怪怪的，我會選擇提出來討論。

> 乃宏：宗輝，你們會擔心自己提出「蠢問題」嗎？如果不會，那你們是怎麼看待「蠢問題」的？

> 宗輝：其實我並不擔心提出「蠢問題」，因為我認為產品開發中溝通是很重要的，如過因為害怕提出「蠢問題」而不去溝通反而會造成更多的問題，一個產品開發的流程中會有眾多成員參與其中，如果不經由溝通使大家對產品目標達成共識的話，只會變成大家各行其是甚至是造成反效果，這樣反而會沒有辦法發揮團隊合作的力量。

## 節目結尾(主持人)

當我們本想向前一步，但卻舉步不前時，很多時候就是卡在我們自己的負面想像。一但踏出去做得更多，其實獲得的也會更多，學到的都是自己的養分。

> 每個人都會因為改變而成長，再因為成長而看到更多改變的可能。在共和國內，還有許多人有不同的改變故事，希望能持續帶給大家改變的可能。

我們下次再見，拜拜～

> All：拜拜～
###### tags: `roc_newsletters`