公司開業時,最初是開發專流動出版系統和研發手機App為主,但誤打誤撞之下,慢慢變成了提供寫App服務和UX/UI設計的Vendor,算是無心插柳,亦是始料不及。App服務和UX/UI設計的Vendor,算是無心插柳,亦是始料不及。

早幾年因為智能手機帶動的創業浪潮,開發了不少Startup的App,期間收到不少查詢,說「個App做到一半/差唔多做完,而家想換vendor」。

作為vendor,很自然會站在vendor的角度,嘗試了解「想換vendor」的原因,追問之下,十居其九都不外乎以下三點:

關於第一點,如果項目已經進入UAT(User Acceptance Test)階段,但一直有bug未能收貨,或會構成換vendor的理由,但如果未達到UAT階段又想試一下效果,就要有心理準備這些版本未必適合做測試。

但如果vendor提供的是UAT版本,就要認真測試,有bug的話一定要確保成功修復才簽收。最壞的情況是有些問題不能修復,那就無奈地真的要轉vendor了。

第二點和第三點,其實有方法可以避免。最初我們開始接project寫App,經常面對一個問題,就是客戶在未確定詳細功能,或每個功能都只有簡單幾句文字解釋的情況下,就要求vendor進行開發。而在開發途中,客戶要求不斷更改或變動,有些部份程式已經寫好了,卻要砍掉重鍊,重新再寫,改動了其他部份,完成後客戶又想改回原來的方法。

用這種方法開發,時間和成本未免都會增加,追加預算亦情有可原。但最大影響的,就是程式經過多次未有計劃的改動,有如架床疊屋,開發時為了趕回進度而抄捷徑,令程式難以維護,這就是所謂「技術債」(Technical Debt)。

我們針對以上問題,設計了一套管理方法,無論是全新開發還是接手其他vendor的項目,都能順利如期完成,而且將改動次數減到最低。

第一步我們會和客戶溝通,同意先進行App的設計,待確定了設計後才開始編寫程式。一般人會以為這樣會拖慢進度,因為不是開發團隊不是第一天就開始寫程式。但如果了解「技術債」這個概念,就會知道開發進度最大的障礙就是未有計劃的改動,「先設計再編程」必定快過邊寫邊改。

第二步,和客戶討論App的設計時,我們必定會有設計團隊和開發團隊的成員參與,在未進行開發前提供專業意見,在成本、時間、用戶體驗、長遠維護各方面取得平衡,令開發更順利。

曾經見過一些需要「轉vendor」的個案,是因為只有不參與開發的銷售員、項目經理,或業務分析員等人與客戶做前期討論,然後就把App的功能列表和介面初稿交給開發團隊。因為開發人員從未參與討論,所以經常會有程序員才會發現的漏洞,或未有定案的邏輯,有時會影響整個App的設計架構,以至某些部份要推倒重來,影響進度。

第三步,如果客戶有需要,我們會負責進行User Research(用戶研究)和Design Thinking Workshop(設計思維工作坊),用這套設計方法釐定App的設計方向,為用戶帶來最大價值。

我們根據多年開發經驗所訂製的Design Thinking Workshop,專為App開發而設,只部留最有用和最有關的部份,亦融合了Google Design Sprint的方法,留待有機會再詳細介紹。

Back to Blog

arrowarrow