解決問題的唯一辦法

1YE1LLNXGB

同事曾問我:「你以前沒有開發過這類產品,也沒有相關經驗,但你怎麼會知道該做什麼?你又是怎麼清楚知道做此產品得做哪些事情?」那晚,他問我好多問題,還等不到回他的機會,他又說:「看你一派輕鬆表情,但你卻沒有開發這產品經驗,可是做起來很清楚知道要做什麼該,往哪去,真的很佩服你,很聰明,具有足夠知識與經驗來面對跟處理。」

 

「我並不聰明,只知道自己夠笨,得花不少心思學習。」我回他。 我跟他分享過去經驗。「以前,我在專案公司,每天接各式各樣不同的案子,客戶需求不同,每一次接到新的案子就像是人生重啟一樣,處理的經驗難以複製,只好硬著頭皮去想像、去想辦法、去試圖解決。」他問我:「你怎麼做到?」我抓抓頭皮回他:「硬幹。」他:「什麼!?硬幹?怎麼說?」我回他:「不懂就想辦法弄懂,不會就自己去學會!」他很好奇,他想聽聽看我是怎麼硬幹出來的,又是怎麼去學會。

 

「有次,客戶的案子要求我們先提出系統架構圖,但公司沒有人手,而技術人員手上全排滿工作,硬要他們去想系統架構圖根本不可能。難過的是,這種東西又不可能外發出去,所以只好自己去學。」同事聽到,問我怎麼學。「Google是學習的好朋友。那時候我不懂,上網去Google系統架構圖,找到一大堆圖片,然後又去讀了Wiki,看到很多系統架構應該要製作的文件,就這樣按圖索驥,我一點一點拼出系統架構圖該要有的資訊。」

 

「你後來拼出了什麼?你怎麼知道自己做的是對的?」他好奇問我。「我發現客戶的需求相對複雜,又從查到的資訊裡得知系統架構設計裡的資料庫結構在一開始很重要,所以我花費許多心思研究資料庫結構。因為資料庫結構沒設計好,之後在資料提取、搜尋、存入,會有很多問題與麻煩,會嚴重影響到系統效能,所以,我看了很多網路上別人畫的DB Schema,畫了一張又一張,耗上三天時間,不知道翻了多少本書,最後畫出連公司內部技術人員都認同理解的資料庫架構圖。另外,藉這機會我自己安裝資料庫,真正試著體驗操作資料庫的感覺。」

 

「但客戶要求又不是資料庫架構,而是要系統架構。因此,我又還得用掉不少時間去了解系統設計文件應該怎麼做,每個欄位的格式是怎麼設定,欄位裡的數字與文字資訊代表什麼,接著就開始設計製作UML(Unified Modeling Language)。我不確定這樣做對不對,但我去詢問技術人員,他們說有這種文件會讓開發更清楚。因此我就貿然做了。」

 

同事問我:「可是你不怕做錯嗎?」我反問他:「我即便做錯,至少別人看了也有可能看我哪邊有機會做對不是嗎?而不是我什麼都沒做,大家都不知道會做出什麼東西。」

 

「看似好像做完UML就差不多,但越跟客戶討論,發現有太多需求難以在三言兩語之間弄清楚。公司的技術人員也辦法辦法深度去理解與研究客戶期望的產品是什麼,於是我又去研究所謂的系統設計。」同事提到:「你怎麼可能會系統設計?你又不是寫程式技術的人,你的系統設計應該問題不少吧?」是的,他說的沒錯,我不會寫程式,也不知道系統設計該怎麼做,可是問題擺在眼前,只要沒有人把客戶需求化為具體文件,產品就難以被實現。不論如何就是得要有人做,我只是選擇嘗試盡力去做。

 

「起先我翻了系統設計的書,讀了幾本程式語言設計的書,大概理解所謂系統設計應該要抓到的重點。但書看再多沒有實作還是難以有感覺。因此我將過去所做的文件整理起來,開始劃分出產品應該會組合的所有功能,寫出一份簡單的功能說明書。當說明書寫完之後,我就開始畫系統流程圖,將每一個功能的關係與順序畫出來,以及到哪個階段需要進入判斷、哪個階段要寫入或讀出資料、哪個階段開始要走迴圈,將各個功能寫出來、畫出來、設計出來。」同事問我花了多久時間。

 

我回他:「每一個下班後的晚上與每一週的週末以及所有我能用的空檔。」他驚訝看著我,問我:「為什麼要做到這樣?」我說:「不懂就學到懂,要學到懂的唯一關鍵就是親自下去做,做的夠多自然就會。即使我們服務的客戶,過去沒有相關開發經驗,但是不代表不能從今天開始有經驗。團隊沒有人有時間,那就我花時間,如果有人可以花比我更短的時間做的比我更好,當然我就不需要做這些事情,可就現況來看並不可能。因此我只好去做,可也因為做了後就把經驗累積起來。」

 

我跟同事說:「專案公司帶給我最大的收穫就是每次都在工作中重新開機。我的經驗可以累積,但思考事情的方向與處理的方法卻沒有辦法,可也是那段時間的磨練,讓我知道不懂就要去花時間翻資料、找資料,即使得看英文技術文件,看的很痛苦還是得看。因為,那是提昇自己唯一的方法,也是面對未知產品與問題的唯一解法。不做不會知道,做了就會慢慢知道。」他有些不解,他問我:「但你不覺得那些工作不應該是你的嗎?」

 

「是,我知道那些是別人的工作,但如果我去做了,就變成我的工作,變成我的一部分,知識變得更飽滿更豐富,有什麼不好?當自己面對問題的時候都可以輕鬆應對,這種感覺不是很好嗎?」「再舉個例子,當初我們在做劃位系統時,我們會遇到多個使用者可能在同一時間選擇同一個位置,當他們選擇後,只要還沒有結帳,那位置到底是給先選到的人用,還是說先結帳的人用。問題又可以延伸成為如果人們都恰巧再同一時間真的結帳,那位置到底應該留給誰?再把這假設擴大到同一毫秒面臨數十萬人連線,取得同一個位置,那怎麼辦?」同事想一想,他回我:「就用排隊的方式吧!」

 

「我當時的想法也是這樣,但問題是排隊怎麼排?排隊的規則是什麼?可真正問題卻不一定在這。當時技術人員只告訴我要去了解什麼叫做資料庫競賽,同時間資料大量寫入時,資料寫入的順序跟方法要被定義好,不然可能就會發生沒有要劃位的人佔住位置,而真正想要那位置的人卻取不到。人少還好,同時間大量的人做同樣事情,就有很多地方得設計清楚,不然最後這套系統誰都服務不了。大量連線之下,瓶頸出現在某個服務上,整個系統就死在那。」我聽到他這麼說,腦袋好像當機一樣,搞不懂他說什麼。所以我跑去買了本資料庫的書來看。看了很久都看不懂,但是因為有看有概念,我就向外求援。

 

「那時候我在網路上,透過討論區去問一些技術達人,問他們在遇到大量同時間寫入資料時,有些什麼處理方法。從討論區上看到大家你一言我一語的,收穫很多,我將那些別人回覆我的答案,整理成一份資訊索引,提供我去研究書裡面有哪些單元可以去解釋他們所提到的現象。雖然,最後我並沒有真正找出最佳的答案,但公司的技術人員卻藉此想到更適合的作法,啟發他對於處理這件事情的靈感。」

 

我們每天都在面對未知事物,問題在於面對未知事物的時候用何種心態去面對。不要因為不懂就害怕去學習,反而要因為有機會去學習感到興奮。這是墊高人生競爭門檻的機會,只有透過那些人們不懂的事物提昇自己,才有機會令自己比別人還要走得更遠更久,也是那些大量過去所沒有過的知識與經驗,透過學習與嘗試之後,獲得更多不同的知識,進而累積出相關的經驗,問題才能夠被一一化解。我不害怕學習,我只害怕自己學習的速度不夠快,無法反應到我的人生裡。

 

最後同事又問我:「這次開發的產品,專案很大,你又是怎麼看待?」我說:「你看看我的桌上,看看公司的書架上,有沒有發現一堆沒看過的外文書?」他回我:「有,我不知道那是誰帶來的,也不知道為什麼這些書會在書架上。」我回他:「這就是我的答案。那些書是我在做這專案時所買的,當我發現這產品在台灣沒有什麼經驗可以參考,我耗了很多時間在網路上查詢資料,查到有好幾本書可以看,所以從國外把書買回來。不知道花了多長的時間去讀那些書,很難懂,真的很不容易理解與消化,可是我至少看過,知道方向跟概念。」

 

「接下來,我就只要依照書裡面的一部分資訊,像是過去一樣按圖索驥,一點一滴去拼湊出我想要的東西,也能夠驅動團隊前進的燃料,順著就是開始看團隊的發展狀況,逐步改善我們開發的狀態與步伐。過程中,就像是你問我為什麼沒有經驗卻還能繼續做,那是因為我清楚每一天,我都會堅守崗位,了解自己所做的事情,持續學習與精進,想盡辦法將不懂的弄到懂,不會的學到會,從一百個問題裡面,每天知道一個問題的答案,可能幾天之後就會變成兩個、三個,也許不到兩個月,一百個問題就被解開來了。」

 

解決問題的唯一辦法就是把每個問題當課題,認真學習與處理,問題自然就不再是問題,而是訓練自己與團隊成長的動力與門檻,歷練過後,淬煉出來的成果,將會替我們築建出一道別人難以與其競爭的門檻。