我犯的錯誤：1. 沒有把國定假日考慮進來，簡直整死自己 2. 沒有詳細分析導致漏掉一個大功能沒算進來，簡直整死自己 3. 連續排滿四個月沒有中場休息時間，簡直整死自己 4. 以為設計工時只要用產品頁面的數量來估算，簡直整死自己 5. 以為程式複雜度跟專案規模之間只是單純的正比關係，簡直整死自己
最近幾個月重做了公司產品的前端，不算太複雜，是一隻菜鳥勉強可以獨力完成的規模。開發時程是去年的我訂的，後來有微幅變更兩次，總之最後是從 9/24 做到 1/20，總共 17 週。
前半段 UI / UX 原以為已經爛熟，結果花了快兩倍時間。後半段程式開發已經多排了一倍的時間當緩衝，結果不僅緩衝用光光、規格打折扣、還開 turbo 拿肝換，到最後關頭才追上。前陣子趕工趕得快吐血，一邊寫 code 一邊心裡狂幹譙去年的自己，超想坐時光機回去打他啦 (／‵Д′)／~ ╧╧
理論 vs 現實
這張圖的左邊，是最初的時程預估，右邊則是實際的工作記錄。黃底的那幾週，工時還算正常但有負荷過重的主觀感受；紅底的那幾週，則是毫無疑問的過勞。
算一算，原本預估 4 週設計 5 週程式，穿插 4 週的休息緩衝；實際上則是 6 週設計 10 週程式，而且如果把紅色的加班工時攤開來看，其實程式需要 12 週。然後我沒寫測試，所以如果要包含測試的話，應該至少要再乘以二之類的吧 😅
設計階段的陷阱：狀態盤點、文案寫作
在這個週期開始之前，已經有先跑過一個小的 iteration，用一個月的時間，從目標族群、使用者旅程、資訊架構、框線圖、到網頁前端工程，做了一個只有主要操作路徑的 prototype。由於該 prototype 已經得到產品負責人的認可，所以這個週期的設計工作很可以預測，就是把 prototype 的邏輯延伸到整個 app。於是，我根據之前做 prototype 的速度、以及這個週期要做的頁面數量，來估算設計階段所需的時間。
之前的作品，不管是 Debator、Storyliner 或 OCF 官網，大多是以呈現使用者寫作的文句為主，只要動線跟排版規劃好，介面就差不多完成，因此一旦資訊架構確定，剩下的設計時間，看需要排版的頁面數量有多少就知道了。但公司產品要呈現的是各種物件的狀態，一個頁面中要展示多個參數的設定值，且隨著參數的設定值改變，頁面上的圖示和文字說明也會跟著變化。也就是說，頁面上的文案不再有現成內容可以擺放，全部都要自己寫。
撰寫文案對我來說是家常便飯，即使寫英文，頂多就花比較多時間查單字，因此一開始並沒有放在心上。但沒想到的是，要撰寫在多種不同物件之間用詞一致、語氣一致、句型一致、且在任何情境下讀起來都不會覺得怪怪的文句，竟然這麼費工！
首先，我要每個物件逐一盤點，把所有參數的可能的設定列出來，接著要決定一種寫作風格，開始寫每個參數的每種設定的文案，然後把文句擺到它可能出現的頁面上讀讀看，如果讀起來不順或感覺不好或在某個物件上看起來特別不合，需要調整風格，那又要全部重寫... 簡直寫作版的無間地獄 😱
總之，最後花在狀態盤點跟文案寫作的時間，跟花在其他介面設計的時間，大概是 1:1。對了，這裡的介面設計不含 visual（直接套現成的 css framework）也不含 RWD（現階段只有桌面版）。
程式階段的陷阱：例外處理、通用架構
之前的 SPA 作品中，GW2 Inventory 是直接讀 AreaNet 的 api 資料，Debator 是拿 HackMD 當編輯後台，Storyliner 是拿 google spreadsheet 當編輯後台。總之，前端都只 get 不 post，不需要實做編輯介面，因此排版排好、瀏覽功能做好，前端工程也就結束了。然而這是私人 toy project 特有的簡單，這個時代的正常 web app 通常還會有登入編輯的功能，也就是說，跟過去做的玩具相比，公司產品多出非常大量的 ajax 操作，也就要面對隨之而來的各式各樣的 error handling。
權限控管、編輯功能、例外處理，都是我過去不熟悉的，讓程式開發的複雜度增加，所需的架構也跟以往不同，一切都要重新思考。所幸產品裡面四個主要物件的行為都差不多，寫完第一個以後，複製起來稍微改一下，後面三個很快就可以做完了——我就是被這種想法害慘的 😭
寫四個不同功能的 app，跟寫一個有四種功能的 app，誰比較費工呢？我原本以為答案是一樣費工。不過，當我複製第一個物件、開始改寫成第二個，馬上發現結構面有不少不合身的地方，而當我為了調整結構而修改兩個物件都會用到的函式，每個修改都必須多複製貼上一次。到了第三個物件時，則是每個修改都必須多複製貼上兩次，然後到了第四個物件... (／‵Д′)／~ ╧╧
總之，我花了非常多時間在一次又一次的重構，把共用功能抽出來、把架構改得更通用更有彈性、重新命名函式以便符合他們的新定位... 中間室友一度看不下去，勸我以 deliver 為重，不要再花時間重構了。但強迫症患者看到不一致的寫法就異常焦躁、寢食難安，所以最後還是把主要的四個物件都橋成自己可以接受的樣子 www
時間管理的陷阱：空白支票、勞工權益
身為一個對自己的管理能力感覺良好的自戀症患者，排時程的時候，特別把程式開發的時間拉長為兩倍，每一週的實做後面都安排了一週的測試做為緩衝。正當我覺得萬無一失、可以悠哉做完的時候，強者我導師 ddio 大人聽完產品規格，再看看時程表，問了一個關鍵的問題：所以區塊四的時程在哪？所以區塊四的時程在哪？所以區塊四的時程在哪？（後面兩句是在我內心產生的回音...）
因為排時程的過程太草率，事前沒有好好地盤點、分析，因此整個產品前端裡面最難做的導覽精靈功能，就這樣被漏掉了，完全沒有排進去 XDrz
除此之外，由於我看著 google calendar 算天數的時候，完全沒有想到要打開國定假日的行事曆，所以這四個月間所有的國定假日，我都沒放到... 枉費我是勞基法掃描器作者、電資工會成員，公司給我 100% 的決策權，我卻替自己排了這麼沒良心的時程，實在是有夠兩光 😨
給下一次的我
- 排時程之前，先排一個禮拜來盤點產品規格。
- 如果總開發時程會超過兩個月，不要一口氣排完全部，先排設計階段的就好。等設計階段做完，再開始排程式階段的時程。
- 打開 google calendar，把國定假日的日曆開起來，放假一天的那幾週，產值折半計算。放假兩天的那幾週，都直接整週劃掉，因為扣掉開會日以後，該週只剩下兩天，光 context switch 就沒了，你不會有心情上班的。
- 每遇到一種 layout，就多算一份做架構的時間，你目前做架構的速度是大的一週、小的三天。
- 每遇到一個要共用架構的元件，就多算一份重構的時間，你目前重構的速度是大的三天、小的一天。
- 每完成一個功能區塊，就安插一週的休息緩衝時間。
- 把排好的時間全部乘以二，再交出去。
結語
這個 milestone 雖然執行得很慘烈，但同時也明顯感受到自己 level up 了，覺得非常紮實，所以做完以後還蠻開心的 XD 接下來除了繼續改良架構以外，還要整理開發環境、研究怎麼測試，一步一步從野生 toy project 等級脫胎，朝著 production quality 邁進。
感謝別人家的 CTO 還有我的前端導師 ddio 一路走來不厭其煩地接受召喚，希望有天可以變得跟他們一樣強大、像他們一樣有能力幫助別人（握拳
對了，這篇文章開頭的圖片，是參考 ddio 的 one man scrum 表格做的，然後有幾項重要的心得，是看巧克力的 這則留言 才想到的。前幾年瘋狂參與 g0v 的最大收穫，就是讓我有幸認識這些善良又強大的人吧 🥰
沒有留言:
張貼留言