如何靈活應變突如其來打亂流程的意外,大概就是專案管理中最需要面對的課題吧。

2017.05.16

一陣子沒寫部落格了,前些日子在協助所上開發年會網頁,第一次接案是有點怕怕的,除了要面對時間壓力外,也怕遇到自己能力範圍外的技術性問題。

一個月下來,雖然成果還有很大的改進空間,但整體來說是很有收穫的。這篇就簡單紀錄在這個專案過程中,各階段所遇到的問題及心得。希望之後能力更強點,能再做點更不一樣的東西。

專案流程

參考自網路上的一些資源,我將專案流程大致分為三個階段,分別是「前置」、「執行」和「維護」,而各階段都會再有一些小專案,讓專案能夠完整且順暢地進行。

然而,雖然字面上三階段是個線性的過程,但考量「資源」、「人力」、「時間」和「需求」等因素,專案流程大多是跳躍式,甚至是前後往返地在進行。如何靈活應變突如其來打亂流程的意外(?),我想大概就是專案管理中最常要面對的課題吧。

前置階段

需求確認:User Story / Reference

  • 需求會議:瞭解業主背景、需求、期望、預算、時程和權限範圍
  • 使用者調查:調查相關使用者的需求和使用情境
  • 蒐集參考範例:依據需求和調查,蒐集相關範例以供示意
  • 撰寫需求文件:明確定義產品需求、客群和定位
  • 確認合作意願:確認雙方之合作意願和條件

執行階段

設計規格:Functional Map / Wireframe / UI Kit

  • 產品規格圖:確認網頁整體內容清單,包括資訊和功能
  • 操作流程圖:依據產品規格,確認網頁架構和操作流程
  • 純內容線框稿:確認網頁主題、網頁類型、版面配置、操作流程、跳轉示意和互動操作
  • 開發用線框稿:確認網頁主視覺、視覺配色、狀態配色、字體字級、開發尺寸

前端開發:HTML(Jade)/ CSS(Sass) / JavaScript / Git

  • 網域主機:確認網域和主機,並將 DNS 指向主機 IP
  • 開發準備:確認開發語言、工具和套件
  • 版本控制:透過 Git 進行版本控制
  • QA 測試:測試網頁在各系統、各瀏覽器及各裝置之操作狀況

維護階段

  • 網頁維護:持續更新及優化網站內容,並修復網頁上出現的臭蟲
  • 網頁追蹤:透過 Google Analytics 觀察網站流量、來源和跳出率等數據

前置階段

雖然一心希望專案能一路順暢進行,但不管是業主需求無常,還是自身的遺漏和疏失,專案需求變動的狀況真的在所難免。舉例來說,有可能前兩個禮拜確定好的需求,在下一次會議中全部被業主自己推翻,又或者是業主根本不清楚自己的需求,所以需求一直都無法定案。

因此,找出會議中的決策者並引導對方支持你的提案,就變得非常重要。我自己習慣的做法是,先觀察會議成員的層級關係和話語權大小,並將問題拋給主要決策者得知其需求偏好,提案時不斷強調來自決策者之想法,便可加速其他人對專案需求的認可。

而雖然常常抱怨業主很雷,但專案管理者本身的疏漏和消極溝通,有時候也是導致需求變動的主因。以這次專案的經驗來說,事前我並沒有積極溝通需求變動會導致的開發成本,也錯估了業主對於網頁的可接受程度,以至於來來回回浪費了不少時間和精力在溝通需求上面。

執行階段

完成前置的作業後,接著來到最令我頭痛的設計階段。UI 與平面設計有很大的不同,除了介面外觀要兼具一致性和美感外,底層 UX 所講究的使用者操作體驗又是另一個大課題。

第一次嘗試設計 UI 的結果有點慘烈,除了時間上的壓力外,更煩惱的是接觸一個完全陌生的領域。雖然可能不是很正確,但還是紀錄一下當初設計的過程,看看哪裡還可以再多做改善。

依據前面確定的需求和參考範例,我詳列了網站所需的資訊和功能,並以一頁式網站的呈現方式來繪製純內容的 Wireframe 以供示意。雖然花了一些時間說服網頁呈現方式的轉變,但整體來說都還算順利。

畫完 Wireframe 後,我依據網路上的內容依樣畫葫蘆,做了一份簡單的 UI Kit,希望可以讓之後繪製介面的時候更加快速並具有一致性。最後,我繪製了一份 RWD 四種尺寸的設計圖,透過 Zeplin 將 Sketch 檔轉成附有開發尺寸的設計檔方便開發。

雖然上述過程感覺好像蠻順利的,但事實上我沒有把 UI 畫完就開始開發了。除了怕開發來不及外,最主要的原因是因為在 UI 設計上卡關很久,想說可以邊開發邊調整排版上的規劃。殊不知事情不是憨人想的那麼簡單,邊開發邊想設計的結果就是一場悲劇。

原本想說一頁式的網站,應該可以純手刻不需要仰賴框架,加上 node 的開發環境也還搞不太懂,所以就先用 Prepros 編譯 Pug 和 Sass 進行開發。一開始是蠻順利的,但邊寫程式邊嘗試各種排版的後果,就是把程式碼給寫亂了,雖然都還是看得懂也知道如何修改,但我知道如果需求一變動就完蛋了。

才剛這麼想沒幾天,需求馬上就變動了,可以說是壓垮爛程式的最後一根稻草。被告知必須完全符合年會文宣品的主視覺(左圖),所以原先設計的 UI 要砍掉重練,並新增新的欄位、內容和導覽列項目。

雖然當下是有些無奈,但想想我的確應該要能先預想到需求變動的幅度,並在開發前就選擇最合適的開發方式。

痛定思痛,為防範後續可能多多少少的變動風險,侯來決定用 bootstrap 重新開發。雖然花了一點時間瞭解文件,但不得不說運用框架開發的速度真的快非常多,大概只花一天多一點的時間就重刻了一個新版本的網頁。(雖然我還是不喜歡腦就是了)

維護階段

網站正式上線前後,我先開了 Issue 清單讓內部持續測試在各系統、各瀏覽器及各裝置之操作狀況,並將 GA 碼埋入網頁持續追蹤瀏覽情形,看是否有過高的跳出率或其他異常的瀏覽狀況。

整體心得

雖然最後成果沒有特別滿意,而且需求變動真的很容易短暫失去熱忱,但還是蠻高興有這樣專案練習的機會。除了會更加理解自己哪裡不足外,也訓練自己更知道如何去找到解決方法,並更有耐心和技巧性地去說服別人。

希望之後強一點,自已能再做一點更不一樣的東西。