Blog Cover Image

Inspire you to have New thinking, Walk out your unique Road.

有的時候,你無意間遇到的一些故事,會激發你的靈感,改變你的想法,接下來你會用與之前全然不同的觀念去創造屬於你獨特的故事。

Sign @MinaYu.

[產品開發日記] 這半年的時間開發Miri第三版本的感想與進步 | 開發日記系列(3) | 開發感想

Posted on

回想這段日子,彷彿好像事情昨天才發生,時間很快就過去了

這段日子帶給我很多收穫,雖然在期間我曾經懷疑陷入茫然不安的情緒中,但是堅定的直覺力,讓我即便承受著極度茫然與悲傷的情緒中,還是努力繼續做直到完成。

那麼就來看看這半年的故事吧!


第四章 - 來自同事的鼓勵

2020/10/16,我彷彿已經提前感受到我們部門可能會面臨解散的可能,那種感覺騙不了人的,跟我在第一家公司即將要被迫離職時的氣氛很相似。

中午我拿著公司發的便當和同事坐在一起吃飯

哎我感覺這個氣氛要是再延續下去,可能我明年就會離職了

上一家公司是傳統產業公司,基本上你入職的開始,他就等同於公務人員般穩定,可以穩定待30-40年都沒問題。

卻沒想到在進入公司的即將一年前感受到了一種部門即將滅亡的感受。

三個人坐在一起,我一邊吃飯,一邊打趣地拿起手機看一下我的紫微斗數命盤,來看看有沒有可能在明年會有離職的可能性。

未來總是不可測,尤其我的命運常常是一下高飛一下又重摔在地,如果有驛動的可能性,則代表我的感受也許不會錯。我一般很少主動想提離職,我的意思是我很少會有一種我決定只做到明年這種想法,因為我大部分都想久待,第一份工作想待六年,第二份工作原本想待2-3年,原本想說第二份工作至少能待久一點,沒想到若命運是如此,那是不可違抗。

明年的2-3月或者4-5月有離職的可能性,我來細看一下,應該是2/28號吧!

我細看自己的命盤,然後說出可能的時間。

你傻了呀,2/28日是星期天,你星期天提離職做什麼?,部門內最叛逆的同事回道。


我們將時間快轉到離職前20天,我在電話中和我的人資朋友聊著,事實上在這之前我有找他吃過幾次飯聊這個事情。

我要定下離職日期了,你覺得要什麼時候呢?,回想起10月時和同事提過的離職時間,被笑說週日(2/28)提什麼離職,頓時我也不知道要將離職時間定在幾時。

就2/28日吧,做完整個月,人資朋友說道。

我真的是嚇了一跳,自己準確預測了第一家公司跟第二家公司的離職時間,當初還想說2/28是週日,假日為什麼要請假?

結果當人資朋友一講出日期後,我整個人都笑了起來

該來的還是會來的,跑也跑不掉的


離職時間敲定後,我利用剩下的上班時間,偶爾請假去淡水散步,畢竟這家公司就在淡水附近,要是離職了,我應該也會比較少來淡水玩。

不過淡水真的是不錯,平時下班疲勞,晚上很少去海邊,但是下午請假去淡水散步,會讓人覺得既舒壓又舒服,很懷念那種感覺。早上上班,下午衝淡水,就這樣一個人當著觀光客散步。

在離職前的某個週六,和很要好的設計師同事一起前往我在淡水的愛店餐廳之間,以及在淡水附近散步。

在一邊前往餐廳的路途中,在冬天多雲舒適的氣溫下,一邊和設計師同事討論Miri的事情。

我以前真的是對Miri太沒信心了,我只覺得自己做了一個很弱的小玩具,完全不覺得這是一個好題材,我有能力可以好好發揮她

我從內心壓根就不覺得Miri可能發展為產品,自然就不會想到要規劃去開發她

只是說真的,我工作兩年了,而且也在不同的公司工作過,我卻沒有一個可上線的作品,秀給大家看

赫然我想起,有一個程式已經上線兩年,她在我跟大家聊天時,面試時,可以隨時拿出來秀給大家,而且沒有壞掉過,她就是Miri。

那Miri為什麼叫作Miri呢?

因為我一開始是想做Siri那樣的人工智慧管家,所以我就把我的名字縮寫M加上Siri,變成Miri。


事實上在前些日子,我就已經先把第二版本擁有盧恩符文的Miri介紹給同事玩,我當時覺得不過就是只有一個抽取盧恩符文的功能,再加上弱弱的文字回覆,使用者引導還做得十分破爛,和自己正在做的IOT太陽能資料收集系統跟IOT路燈資料收集系統差得太多了,我自然也就對Miri沒有抱著太大的信心,也許被其他人或者面試官看到,還會覺得這是什麼呀?

在某次下班後的晚上我也是和朋友約在之間,在等待朋友的時間和設計師同事聊了20分鐘,才前往餐廳。

他只有一個盧恩符文的占卜功能,而且還一堆錯字,跟蠻弱的使用者引導

可是我不覺得Miri差唷,他其實是可以發展成一個產品的,我已經想到Miri賺錢的方式了

什麼?是什麼?

嗯,妳是未來的老闆,妳自己想囉!至少我已經想到了不只一種賺錢方式


這次離職後,我決定隨著我的直覺,鼓起勇氣給自己半年的時間做Miri,希望能夠將她發展下一個新的版本,一個至少可以讓使用者玩,可以秀給別人看,而不覺得內疚難堪的版本。


第五章 - 第三版本

離職前夕,我就開始著手規劃下一版本也就是第三版本Miri的功能要有哪些。

至從Miri做了一個盧恩符文的占卜功能後,Miri的定位越往占卜跟命理主題走。想起先前自己看星座命盤的財帛宮時看到自己可能會做占星、命理類的產品賺錢,再加上Miri目前唯一的功能是占卜相關,我就更篤信的要把Miri的未來發展朝向占卜跟命理

這次給自己預計半年的時間開發第三版本,所以3月開始規劃跟實作,大約7月跟8月能夠完成第三版的開發。

由於思想已經比之前成熟,所以在這半年內,一樣會希望規劃第三版本時,能夠會是一個比較階段性完整的版本,同時又能夠在半年時程下完成開發,因此會針對程式架構、UI跟其他功能有顯著的擴增,規劃的功能如下:


  • 希望從一種占卜擴增到六種占卜

離職前那個月,我很常跑神秘學的店家,買了蠻多牌卡來玩,其中也有幫忙一些朋友占卜。所以就想過,除了盧恩符文以外,也可以放多一點不同的占卜方法甚至是不同性質的牌卡進入占卜。

第二版本有一個盧恩符文的占卜,那麼第三版本就想著要從原本的只有盧恩符文一個占卜選項,新增到六個占卜選項。

  • 不同的使用平台

由於原先只有Line社交軟體可以使用,也就是說不普遍使用Line的地區,將無法使用Miri,考量到未來找工作可能傾向往國外公司找,而Line目前僅在亞洲地區使用,所以我希望能夠再新增另外一個社交平台且比較偏向不同區域,這樣可以讓亞洲地區以外的使用者可以使用Miri。

剛開始我想到的選項是 What's app,但我發現What's app的bot api發展的好像不是很完全,加上商業帳號跟個人帳號的號碼綁在一塊,意味著當我在使用商業帳號時,會被迫登出個人帳號,也就無法收到朋友們傳來的訊息,在開發上造成些許不方便。

我感覺用What's appMessenger來作為第二使用者平台的選項不太適合,後來和一個俄羅斯的朋友討論後,他告訴我TelegramLine一樣有 bot api 可以使用,經過搜尋還有使用各種通訊軟體平台後,我認為Telegram的性質和Line是較為相似,bot api也發展得比較完全,再加上目前Telegram的普及區域與Line不同,所以選擇它作為Miri的第二的使用者平台選項。

於是除了原先Line平台之外,第三版本會新增Telegram平台作為第二的使用平台。

  • 帳號系統與不同語言

就像上述提及,考量到未來可能會找國外的工作,加上決定開發Telegram平台,因此除了繁體中文外,還需要其他語言讓外國使用者選擇,考量到目前英文是第一使用多的外國語言,加上目前的時程只夠開發一種新的外語,所以選擇新增英語作為另外一個對話預設語言。

既然需要紀錄使用者跟語言,那就會需要帳號管理,不排除未來可能會開發更多跟帳號相關的內容,所以新增帳號管理功能,主要目的是紀錄使用者、使用平台及使用語言,這麼一來就不用每次使用Miri都要設定一次語言了。

  • 使用者引導

我想新增上述的功能已經是蠻完整的第三版開發規劃了,但最後一項我覺得是特別重要的部分。在第二版的Miri,需要使用者自己在對話框輸入盧恩符文才會驅動占卜的功能,甚至當使用者將Miri加為好友後,並沒有任何的提示或手冊,常常讓人加入好友後,便不知道如何開始。

然後,由於先前盧恩符文的占卜流程太過簡略,還有不夠清楚,導致很多使用者常常還沒冥想占卜問題,就點了按鈕得到答案,這次也會規劃擁有整個占卜流程,包括選擇牌陣跟冥想,也會把占卜流程的程式規劃分開,使其容易閱讀跟整理。

所以說整體使用者的流程都蠻簡略且粗糙,這部分也列為此次需要優化跟加強的範圍,所以新增的部分像是:

  1. 新增使用者引導手冊
  2. 新增選單
  3. 優化占卜流程

也就是說再加為好友的瞬間,剛開始先選定預設對話語言,然後會有訊息引導或者介紹怎麼使用Miri,詳細的話還沒想到,但是會新增這方面的功能。

再來就是選單的部分,在第二版的Miri,可以發現當使用者使用完一次後,下次使用還是得再輸入盧恩符文驅動占卜功能,再加上這次更新會新增很多不同的占卜方法跟功能,所以我認為需要製作一個選單,讓使用者無論是在使用過程還是之後再次使用,都可以透過選單點擊功能,而不用手動或陷入不知道如何使用的窘境。


第六章 - 做產品哪有這麼簡單

既然要從原先只有一種占卜功能擴增到六種,再加上原本只有Line的平台,現在要新增Telegram的平台功能,想必程式的架構需要重新設計。由於第二版本的Miri在開發時,我的程式設計能力還只是停留在實作功能規劃架構程式設計可讀性效能完全是沒有考慮到的。Miri已經不再是一個小功能小玩具,她開始規劃作為一個軟體或一個系統的目標前進。

首要任務就是將原本Miri的程式架構依據第三版的功能,再加上未來可能會新增的功能,來考量重新設計程式架構。這個部分由於在第二份工作已經大量學習到規劃架構跟設計程式,因此沒有遇到什麼困難,大概花費2週時間就完成。


接下來我的順序會是:

  • [API] 先確認後端程式和前端溝通無礙

    • 這次由於前同事的推坑,我打算把使用的API服務從Flask框架改成FastApi
    • 為符合新增的Telegram功能,需要調整原先的API程式架構
    • 重新設計Line平台API跟處理程式
    • 規劃與設計Telegram平台API與處理程式
  • [占卜功能] 主要是依照流程撰寫程式

    • 規劃統一的占卜流程
    • 依據不同的占卜方法刪除或增加流程
    • 實作
  • [帳號與語言] 新增帳號管理功能,紀錄語言為其中一個功能

    • 規劃與實作帳號功能
    • 規劃與實作語言設定與切換功能
    • 規劃與實作帳號綁定預設語言功能
  • [占卜內容] 等到大部分的程式都寫完後,開始針對占卜牌卡內容跟解釋撰寫

    • 實作跟填寫每個占卜方法的牌卡資訊
    • 規劃與實作解釋功能
  • [使用者引導] 像是訊息引導或繪製圖像介紹或者是選單的部分

    • 預先選擇語言功能
    • 使用者引導功能
    • 使用者引導手冊
    • Menu選單功能

[感想] 遇到的困難與障礙

我想大致上的開發任務都列在上面,就不一一撰寫開發日子了,每天的日子都是早上起床吃早餐,接著就坐到電腦前進入開發模式,下午跟吃飽飯後的時間是最能專注跟最清醒的時刻,一天開發時間大該也約是8小時,其他吃飯跟洗澡時間都會拿來思考跟解決遇到的難題。

但整個開發過程中,總會遇到一些困難跟一些障礙,讓我有所突破跟成長,接下來的篇章就讓我來撰寫那些日子我遇到的困難。


UI/User Flow的重要性

作為後端工程師兩年的工作經驗,一直以來從我都以後端的角度來看事情,在和前端工程師合作時,一定都會先以前端工程師方便的規格為主討論API跟程式設計,所以與前端的對接只需要討論跟規定API規格就好。

然而,這次的前端是先藉由Line跟Telegram Bot作為前端呈現,所以不會有設計前端的問題。

在剛開始結束重構後,我就自行依據上述列的功能開始往下規劃跟實作後端程式的部分,但實作沒多久,開始要和前端平台對接並由前端使用來測試時,我才發現我後端的功能雖齊全,但和前端甚至是使用者流程完全不符合,開發一陣子了,結果完全沒辦法從使用者方面來測試功能面。

哎糟糕,怎麼越開發越茫然的感覺,後端程式寫一寫,搭配前端平台測試,沒點幾下前端按鈕,就需要這邊改一改,那邊改一改,然後前面跟後面剛改完又不對盤。

這時候我才發現,原來一切都需要回到最原本的使用者端的角度來規劃後續的功能實作計畫。

也就是說,我得把自己轉換成使用者,今天我希望Miri呈現給我的整個使用者流程是怎麼樣,然後再去設計UI呈現跟模擬的流程圖。

使用者想看到的功能跟流程 -> UI設計與模擬功能流程 -> 實作前端部分 -> 實作後端部分

結果由於本身是後端工程師,所以居然是一開始就直接寫後端的部分,難怪越寫越茫然。

看似這個道理很簡單,但其實很多工程師都是以工程師的角度實作專案或產品,不太會從使用者角度去考量事情。

所以後來我先用Ipad的App來規劃使用者流程,接著再依據規劃出來的流程設計後端的功能來串接。

開始開發一個產品前,先把自己當作使用者來發想,我想看到什麼畫面跟功能面,接著去設計使用者流程跟UI介面,最後才會是前端與後端依據設計內容來實作功能。

一個軟體開發團隊,每個角色都很重要,但也正因為每個角色都是專業且以自己的角度看世界,所以溝通與尊重變得重要。


不同前端平台與後端程式設計的整合性

由於先前的開發經驗都偏向於單一前端平台,但這次除了有Line介面之外,還新增了Telegram的平台提供使用。

實作Line跟Telegram Bot的功能都不算困難,但困難的點是這兩個通訊軟體有著不同的訊息型態,Line Bot Api 提供 Template 訊息型態,使一個訊息能夠同時夾雜 圖片標題描述按鈕,可是在Telegram Bot Api中只能用InlineKeyboardButton作為傳訊型態(有描述按鈕),這樣對於兩邊平台的使用者而言,Telegram的使用者會沒辦法看到圖片,只能看到描述按鈕,使用者的體驗就會有差別。

我花在這邊的規劃與設計的時間也蠻多的,要同時作為使用者去規劃LineTelegram的訊息必須同步跟克服訊息型態不一致的問題,還需要將角度切換回後端,去思考這樣使用者的流程規劃如何和後端功能搭配,因為後面是共用同一個後端功能,不可能因為有兩個不同的平台而寫兩套程式。

Line的Template Message

Telegram仿照Line的模式去設計相似的訊息型態

詳細克服的解法也是會在之後的篇章論述,而這個難關也讓我深深的感受到即便我因為時程跟自身能力的關係,用社群軟體的Bot模式代替前端的開發,但是也因為Bot的功能限制,限制了Miri功能跟呈現上的多樣性及變化性,使我埋下之後想將前端獨立出來開發,而非仰賴現有Bot功能的想法。

無論是現成的平台、功能跟函式庫都好,可以節省開發的時間,因為都有人幫你寫好了,但同時也身受限制,倘若需要自訂功能,必定還是需要深厚的底子與自創的能力


程式技術的豐富與使用者使用感想的平衡

這個就很像是程式設計師很Care使用酷炫或者最新的程式技術來實作功能,但酷炫的技術或功能根本就不是使用者要的需求。

其實也不完全是上述的道理。

在實作Miri時,常常我會覺得我撰寫非常多後端程式,我的意思是說後端程式的工很浩大,但感覺呈現在前端平台的功能卻很少,這會讓我很沮喪,讓我覺得說會不會我花了很多時間製作Miri但是由於前端呈現出來的部分並沒有這麼多,所以會被使用者或未來的面試官質疑。

這個困惑曾經不止一次出現在我的腦海中,甚至有時候會讓我陷入低潮的氛圍當中。

像是會不會明明花了半年時間實作Miri,但是卻被說怎麼半年只有這點成就?

所以得承受著類似這種心魔的考驗,在不被打倒的前提下,繼續將專注力拉回繼續做Miri。

無論夜晚多麼茫然跟低潮,哭過一回後,隔天還是保持著希望繼續努力。


不過這樣一說,我在前兩份工作時,常常後端的工程都很浩大,但是在前端顯示的部分卻感覺寥寥無幾,也就是說每個前端呈現出來的功能,其實後端都需要付出很多的工,也許是在後端大量計算與處理後,才會輸出一個精準的數字給前端呈現,是一個精準的數字,在後端的處理部分卻往往需要很多程式跟功能撰寫,但是多麼多的程式,都不會讓使用者看到的。

肯起身去行動去執行,就是個很偉大的行為了,只要用心跟努力去做,無論成果是好是壞,自己才是實際知道付出多少努力的人。


部署與維運能力(資料庫規劃)

這也是最後部署於Heroku伺服器時才爆出的問題,而當時距離自己給自己定下的截止日期超過了2週,雖然是在自己下的日期內成功部署,但是有一個困難的解觀察了2週才解決,當時內心滿是煎熬跟緊張(其實沒人在催,只是因為超過自己定下的日期,覺得沒有達到內心的時程。)

由於對部署的代理伺服器服務不熟悉,造成了一些不知道如何解決也不知道怎麼真錯的問題(確定跟自己本身的程式無關),所以剛開始發現問題時,對自己的心靈造成不小的壓力。

簡單來説,Miri目前為了要求輕便簡單,是使用SQLite來儲存所有的資料,而SQLite是靜態資料庫所以跟程式存放在一起。Heroku的免費方案會每天都重置server,重置到部署的版本,所以如果有資料是部署上線後開始寫入資料庫,那每天都會重置到最初SQLite剛部署的時間點(也就是說新的資料會被消除)

第二版的Miri也是使用SqLite資料庫,但沒有發現問題主要是因為只有單方面的讀取,並沒有寫入新資料的問題。而第三版本規劃了帳號管理功能,除了要記錄使用者及其平台,還需要紀錄使用者所使用的語言,所以只要有新登入的使用者,就會把新的使用者資料寫入SQLite,但上面說過了Heroku server每天都會重置,所以等於新的使用者資料每天都會被刪掉。

起初因為對Heroku的不熟悉,所以發生這個問題時,一直以為是自己程式的問題,直到改了很多次程式後,還是發生一樣的問題。我就暫時擱置然後觀察一週,才找到問題。

當問題解決不了時,不要慌張,也許只是因為你不了解他,給自己多點時間觀察與研究。


程式技術不了解

在上家公司時,由於要快速處理太陽能每兩分鐘的資料處理,所以除了大量使用Redis外,也會用到類似使用python的list或dictionary做暫存的設計。

這次也使用這樣的設計,將登入的使用者及選定的語系,存在dictionary中,然後每次有使用者使用Miri時,直接去Dictionary取出使用者的預設語系,而不用再去資料庫取資料,但是不知道為什麼在使用者切換語系時,當dictionary被改動過後,會不太穩定,數值會變動,目前還無解。

也算是自己對利用dictionary當做暫存機制的設計不了解所造成的問題。


以上遇到的問題,並沒有合作的同事可以幫忙解決或合作,但要特別感謝兩個外國工程師的幫忙,當遇到困難時,他們也有提供協助,除了可以透過另外一個人的角度切入外,當自己本身在向對方解釋問題時,同時也是自己正在重新梳理卡住的部分。


第七章 - 未完成前的茫然

終於要迎來這半年開發時程的休止符了,我還記得當時是七月初,我覺得Miri的開發就快要結束了,但實際上又還有一段忙枯燥乏味的路途要走。

在大部分的功能都開發完成後,我把要將每個占卜牌卡的解析留到最後寫,因為他不算在撰寫程式的功能中,所以可以等到所有程式都撰寫完後,在寫解析。

我當時內心的感覺是只剩下每張牌卡的解析,以及最後畫使用者引導的說明書跟部署上線測試。

但我把寫解析的部分想得太簡單了,如果六種方法的話,我們稍微介紹一下:

  • 盧恩符文 25 顆 * 2 個語言
  • 塔羅牌 78 張 * 2 正逆位 * 2 個語言
  • 雷諾曼 36 張 * 2 個語言
  • 筊杯 只有總共6個
  • 自然絮語 50 張 * 2 個語言
  • 智慧箴言 44 張 * 2 個語言

總共以上這麼多張卡的解釋要寫,而寫那些解釋除了參考書中內容之外,我給自己的期望是要加入自己的解讀,還有分中文跟英文兩種語言撰寫。

而本人對於打字工的工作,會感受到枯燥乏味沒有動力堅持,因此在那段日子之中可說是十分茫然、枯燥無聊又必須得保持專注跟耐心去撰寫解釋。

再加上這個部分是完成前的最後幾步,又錯估時程覺得這個部分簡單,眼看著時間一點一滴的過去,彷彿終點就在眼前,但我卻無法完成。

會不會我花了這麼多的時間做Miri,結果換來的是面試官詢問說怎麼做成這個樣子,需要這麼多時間做嗎?

會不會我花了這麼多的時間,結果最後失敗了,做不出來?

大家都在職場上工作,我是不是應該停止開發,停止這個夢想,然後明天開始去找工作?

各種茫然又負面的想在那個時間鑽出,呼應開頭時說過的在期間我曾經懷疑陷入茫然不安的情緒中,但即便有強烈的茫然與負面情緒,我還是保持著 沒有時間寫這麼多,繼續努力的概念繼續做,壓著自己每天至少完成一點進度,即便撰寫解釋再怎麼無聊,直到2021/8/11 Miri上線到現在穩定運行。


以上就是大概這一年發生的事情,正視開發Miri的決定,以及實作第三版本的時光。

在這期間我學習到很多概念跟以前我從來沒遇到過或思考過的事情,如果人生再做一次決定,我會做同樣的決定。

在製作Miri這個產品時,我學到的不只是自己作為後端工程師的本分,學會平衡產品前後端,切換以使用者跟設計師角度切入,還有像個小PM規劃功能跟時程,這段經驗帶給我的又是跟以往完全不一樣的學習,值得啦!

最後,在把第三版本Miri做出來後,我開始慢慢發想產品未來的規劃,像是未來想獨立出前端的部分,就不要再掛在社群軟體的Bot上了,然而最重要的事情,也是最近才新領悟的事情。

我留到下一篇撰寫,跟著未來規劃一起撰寫。