[經驗] 連夜趕工隔天交付的程式

這是筆者以前的一次工作經驗,因為進度落後導致熬夜趕工,記錄下來算是學一個教訓,畢竟冰凍三尺,非一日之寒,往往是多個原因堆積出這個結果,如果當中能及早發現,及早改善的話,也許不至於落得這般田地。

公司接到了一個專案,需要提供導覽機硬體、軟體以及控制後台,硬體是一台觸控且配有 Webcam 的 Windows 大電視作為導覽機,需求功能有:

  1. 呈現觀光相關的導覽資訊,並且能操作互動
  2. 能夠讓客人拍照掃描 QR Code 傳到手機
  3. 沒拍照時,記錄操作者的停留時間、性別、年齡等特徵

另外後台是以網站形式配合帳密登入,讓客戶可以:

  1. 編輯導覽素材和呈現方式
  2. 監控導覽機的狀態,可遠端截圖、重開機
  3. 報表
    1. 操作者的統計資訊
    2. 導覽素材的點擊次數統計…等等

當時和另一位同事搭檔,我負責導覽機軟體、Web 網頁呈現導覽資訊和部分後台頁面,畢竟導覽資訊幾乎都是連結到網頁,所以就使用內嵌的方式呈現,網頁讀取完成後,再另外疊上返回按鈕。同事則支援我其餘的後台頁面,素材管理、導覽頁版面編輯,不過因為整個架構主要是我規劃的,前期一直後在測試導覽頁的套件、內嵌Web的效果還有人臉偵測的套件,稍微花比較多時間,所以後期來不及時,才找同事臨時來支援,但這也是兵荒馬亂的開始。

同事臨危受命,邊了解邊時做的情況下,速度和我所想的有些落差,再加上溝通時間不夠,有時做出來後才發現某些地方雙方理解不同,又要花時間修改,若是一開始就適度讓他參與,了解架構和規劃,也許會比較好,而我也因為回答和溝通佔用了不少時間,導致開發時間更少了。

後台網站的部分,兩人會同時開發同一個程式專案,當時還沒有導入版本控制,所以整合程式時,又多花了一些時間在排除合併後的問題,常需要手動複製檔案到線上檢查的工具,才能知道差異在哪邊,現在想想真是太花時間了。

在功能開發好後,我們測試得不夠完全,當時還沒有單元測試的概念,全部都是簡易手動測試,沒有太多時間做 Monkey test,後期讓非開發人員的同事來使用時,常常發現一些莫名的問題,沒那麼容易重現,又因為沒有留Log,要花更多時間測試和找問題。

最後就是每天和同事加班,甚至到了交機前一天,還在寫功能、找問題,一直忙到凌晨3點才算告一段落,勉強有一個可操作版本,可以先應付,後續還是要把一些隱藏問題修掉,真是吃足了苦頭。

現在來看,大部分問題都可以藉由工具或是開發方式加速,也許初期會多花一點時間,但長期來看絕對值回票價,這也是這些工具存在的價值,期許這個教訓能讓我時時警惕,不再重蹈覆轍。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

在 WordPress.com 建立網站或網誌

向上 ↑

%d 位部落客按了讚: