這是筆者以前的一次工作經驗,因為進度落後導致熬夜趕工,記錄下來算是學一個教訓,畢竟冰凍三尺,非一日之寒,往往是多個原因堆積出這個結果,如果當中能及早發現,及早改善的話,也許不至於落得這般田地。
公司接到了一個專案,需要提供導覽機硬體、軟體以及控制後台,硬體是一台觸控且配有 Webcam 的 Windows 大電視作為導覽機,需求功能有:
- 呈現觀光相關的導覽資訊,並且能操作互動
- 能夠讓客人拍照掃描 QR Code 傳到手機
- 沒拍照時,記錄操作者的停留時間、性別、年齡等特徵
另外後台是以網站形式配合帳密登入,讓客戶可以:
- 編輯導覽素材和呈現方式
- 監控導覽機的狀態,可遠端截圖、重開機
- 報表
- 操作者的統計資訊
- 導覽素材的點擊次數統計…等等
當時和另一位同事搭檔,我負責導覽機軟體、Web 網頁呈現導覽資訊和部分後台頁面,畢竟導覽資訊幾乎都是連結到網頁,所以就使用內嵌的方式呈現,網頁讀取完成後,再另外疊上返回按鈕。同事則支援我其餘的後台頁面,素材管理、導覽頁版面編輯,不過因為整個架構主要是我規劃的,前期一直後在測試導覽頁的套件、內嵌Web的效果還有人臉偵測的套件,稍微花比較多時間,所以後期來不及時,才找同事臨時來支援,但這也是兵荒馬亂的開始。
同事臨危受命,邊了解邊時做的情況下,速度和我所想的有些落差,再加上溝通時間不夠,有時做出來後才發現某些地方雙方理解不同,又要花時間修改,若是一開始就適度讓他參與,了解架構和規劃,也許會比較好,而我也因為回答和溝通佔用了不少時間,導致開發時間更少了。
後台網站的部分,兩人會同時開發同一個程式專案,當時還沒有導入版本控制,所以整合程式時,又多花了一些時間在排除合併後的問題,常需要手動複製檔案到線上檢查的工具,才能知道差異在哪邊,現在想想真是太花時間了。
在功能開發好後,我們測試得不夠完全,當時還沒有單元測試的概念,全部都是簡易手動測試,沒有太多時間做 Monkey test,後期讓非開發人員的同事來使用時,常常發現一些莫名的問題,沒那麼容易重現,又因為沒有留Log,要花更多時間測試和找問題。
最後就是每天和同事加班,甚至到了交機前一天,還在寫功能、找問題,一直忙到凌晨3點才算告一段落,勉強有一個可操作版本,可以先應付,後續還是要把一些隱藏問題修掉,真是吃足了苦頭。
現在來看,大部分問題都可以藉由工具或是開發方式加速,也許初期會多花一點時間,但長期來看絕對值回票價,這也是這些工具存在的價值,期許這個教訓能讓我時時警惕,不再重蹈覆轍。
發表迴響