強健、安全、穩定、可靠、效能卓越。
徹底實現過往的想像。
程式設計師,其實都不喜歡接手別人開發過的專案,寧可重寫相同的功能。
因為,在前廠商沒有留下註解或文件的情況下 ( 即使有留下,也未必是最新或正確的 ),與其想盡辦法弄清楚當初開發者的思路,不如自己重寫,可能還比較快。
雖然客戶不見得都有預算,再重新開發一次。
可是,絕對都有不滿意前廠商,想要更換的理由。
因此,耗費巨大心力,協助客戶改善原廠商所遺留下的問題之後。
我們總是想著,如何才能避免相同的情況再度發生。
就如同廣告標語一般:「為客戶建立可長可久的技術架構。」
人的行為分為「意識性的活動」和「下意識的活動」。
其中,大腦大部分的運作都是下意識的,是隱性的、快速的、自動的,能控制擅長的行為。
只有高層次、反思性的過程,才是意識性的判斷。
就有如冰山的一角,你只能意識到一小部分的生活體驗。
可是,我們發現大部分的公司在設計人機介面時,都很希望能喚起人們的主動意識。
大量的提示文字、大量的提醒訊息、華麗閃爍的動畫、多重步驟的操作「功能很簡單,這幾個項目都是固定的,以後絕不會改...」 每次開發時,多少都會聽到一兩次。
沒經驗的程式,會將這些「客戶保證」的固定項目,寫死在 code 中。
因此上線之後,若發生意料之外的狀況,光是修改這些固定項目,就足夠令人煩躁的了...
其實,這是一種莫非定律:
「如果你真心喜歡做一件事,請把它當作工作,朝夕相伴。」
越簡單、越小的專案,越可能不小心成功,延伸成大專案。
越是擔保不會變更的項目,越可能不小心出現例外。
與其發生例外時,跟客戶拿會議記錄嘔氣...
還不如聽我建議,在一開始就採取較為彈性的策略:
各種「號稱不會修改的項目」,仍舊紀錄於資料庫欄位中。
各種「保證不會再新增的品項」,仍舊保留新增欄位,並以關聯表的形式,提高後續增修的可能性。
這並不代表需要額外撰寫相對應的修改程式,只是在建立資料表時,保留更多彈性。
一旦發生不可預期的例外時,只要修改欄位值,即可完成更新。
想要後續增補程式,用以擴大功能,也能簡單實現。
因此,真正有遠見的程式設計師深知:
「現在一點小小的投資,可能讓未來所有人都皆大歡喜。」... 都在不斷暗示使用者:「不注意到我,別想繼續進行下去...」
所以,我們在接受客戶的 UX 優化案中,最常聽到客戶對不良介面的抱怨就是:「聽提案時感覺很好,不過實際使用後,才發現格外地耗時、耗神。」
為專注的人服務並不難,但人們不可能永遠精神飽滿。
因此,我們為心不在焉的人設計,創造若有似無的使用者體驗。
以樂高積木為例,只要以積木上圓形凸起的尺寸為依據,即使各家廠商分別製作各種不同的積木組件,
就算新積木的形狀、大小、顏色各異,它一定能跟原來的樂高積木組合在一起。
所以,我們為客戶開發系統時,通常會優先設計 API,作為前後端程式串接的基準。
在內部開發階段時,不同的程式設計師都有相同的開發基準,就可以各自開發不同的單元,分工合作,提升效率。
與其他公司偕同開發時,我們也會將 API 預先完成,並提供完整的介接規格,確保雙方的合作默契。
同時,我們會提供一份 API 規格給客戶。如果未來承辦人更換了,或是我們沒有標得後續延伸案,接續的廠商 也能盡量在不改寫核心程式與資料庫的情況下,透過 API 製作新的功能。
如此公開透明的方式,讓客戶不會被既有廠商綁定,可自由選擇開發商,反而提高了信任感。
因此,確保了一個可長可久的技術架構,即使歷經多次的擴增,更替了多家系統開發商,最終仍能保持穩定的結構,不至於疊床架屋、難以駕馭。
「待人以誠,治事以敬。」
其實經過多次開發經驗可知,每次客戶提出規格變更時,一定有其理由,也有其難解之處。
此時,細聽客戶所遭遇的困擾格外重要,並且以技術專業給予最適當的建議;其實八成以上的客戶都會接受專業建議,使之合理化。
所以,即使經過多次調整,跟客戶之間的信任感,總是不變的。
同時,也須深知客戶「不可能雞蛋全放在同一個籃子」的道理,與其他開發商相互支應,各自於負責的系統分工合作,而非相互推諉,才是正道。
一個成功的平台開發案,往往需要經歷數年的經營,才會屢創佳績。
因此,堅持服務精神,不只為了客戶的成效,也營造未來數年良善的工作環境。
絕對是成熟企業的雙贏策略。