2012年8月19日 星期日

OLAccount教我的事情

最近,我有很深的感觸與困惑,而這一切要從2011年說起;2011年6月1日我終於購買了人生中第一隻智慧型手機,接著連續一段不短時間的開發測試,有些值得說點嘴的就變成了一篇篇標籤為Android的文章,最終做了四個比較有用的小雛型,跑步用的路徑紀錄,接ArcGIS的地圖查詢,野外調查的外業回報跟一值從雛型到現在每天都在用的記帳軟體,當時還特地發了一篇文章來慶祝使用該軟體記帳一個星期,而當時他的介面長這樣:

就在我很興奮的到處展示,朋友問我:
「要跑步所以寫路徑紀錄?要記帳就要自己寫記帳軟體嗎?」
我回:「你不覺得使用自己寫的程式,而且是持續使用很酷嗎?」

或許他也認為很酷,但要不要自己寫這又是另外一件事情。

就這樣,這個專案我很滿足的停止了,並且持續使用這個殘破不堪的介面記帳4個月左右,某一天在買早餐的時候,我跟老哥說:「我用這個記了四個月,你看我做的歷史紀錄查詢非常的好用」,老哥回:「阿你又不給我用用看」

所以在2012年年初,我開始做另外一個夢「讓別人使用自己親手打造的軟體」,如果就字面上的解釋,這樣的事情我大概已經做了四年半,其實也就是工作的這四年半;但做過專案的人都知道,你所面對的使用者在一開始決定他們的程式創造團隊後,幾乎就沒有其他的選擇,不管內容是好是壞,最終他們只能選擇使用與不使用,並不會有另外幾套供他比較,有多少專案走到最後業主與PM無奈的對寫程式的說:「這不是我們(他們)要的」,所以我期望的是達到對於軟體的真實需要,而不是無所選擇的妥協使用;所以在2012年年初我開始以自己、嘉嘉與老哥做為對象,以他們的需求為根本大幅度增加OLAccount的功能。

但不實際做其實沒有感受,真的動手才會發現小小一個帳本,所需要的交互內容其實並不單純,所以我被逼迫將目標縮小放在「直覺好用的'純記載支出'軟體」(雖然他在1.2版還是擴大了),就在2012年4月19日他變成了這樣:(說到動手做,最近聽到一個有趣的問題「如果PM沒辦法需求訪談該怎麼辦?」;我突然想到一個電競教練說的話,覺得非常適合回答這一個問題,「當選手程度還不到的時候,我會希望他不要想太多,就是練習一直練習,等到這些操作都內化成他的基本功以後;我希望他不要太多的練習,而是去思考每一場比賽的大局觀,當你很容易完成你想要做的動作,更多的思考將更快幫助你進步。需求訪談是什麼?是大局觀是規劃是成敗的第一步,踏錯可以改但難易程度就要看你背後連動的慣性有多大。如果在談話的人,都還只是練習生,那就很難從更根本去看問題。)

雖然我很興奮的纏著嘉嘉與我老哥,不斷地介紹許多設計上的巧思,每個操作的演進與我認為還需要增加的功能,但參考google play上琳瑯滿目的app後,這個非常工程師的外觀,不論是顏色、配置、整體感樣樣都不行,自知即使花費很多時間坐在電腦前,所能提升的也相當有限,而要有整體感這件事情更是需要不斷琢磨的,我需要的是一個「高手」,最後我找到一位不曾碰過網頁設計、不曾做過按鈕設計、更不曾與程式宅男合作過的"室內設計師",而第一次討論就非常的熱烈:

「你不懂啦,你程式搞這麼複雜誰要用呀?」
「你不懂女生啦,就是要可愛!死板版誰要用?」
「我那知道你哪邊可以變動?什麼列表?什麼是gridview?你可以說中文嗎?」
最終,「好啦,我很忙,有時間才能幫你用一下。」

2012年6月5日早上收到了一封來自TiffanyChang的信,附著我期待已久的圖片:


雖然整體配置改善很多,但因為程式中許多動態產生的部分,導致這個版面非常難完全重現:
「那個食旁邊的圖騰可能要拿掉」我說
「為什麼?」
「因為記帳項目可以自己定義,我們不可能提供這麼多種圖騰給使用者選」我看著圖一邊說


就降,經過8封信與一個晚上的gtalk我們決定放棄這一個版本,而產生了OLAccount的真正初版:

看到這張圖的當下,我心中帶著微微地興奮,嘴巴不自覺的吐出「好樣的」,因為我知道我們將可以合作推出帶點品質的作品。

在整個討論過程中,我們在介面上注重的是"整體性",而我負責程式中的"連接性",我們重視每一個頁面是否帶著初稿中的設計感,「我覺得因為是便條紙,所以列表的格線應該要用某種筆觸」,所以我們有了蠟筆的分格線:


「我昨天去夜市買晚餐,好像記帳的時候有計算機功能比較好耶」,所以我們有了仿計算機面板:


「統計圖表我希望有張貼公佈欄的感覺」,所以我們有了黑板:


「我做了一系列的收入功能,可能還需要一個帳本鎖,但是如果解鎖才能記帳,就會讓人感到煩躁,所以需要有兩個鈕,一個是解鎖,一個是記帳」所以我們有了帳本鎖:


經過147封mail的來回討論,我們終於在6月22日上架,並且在7月6日更新1.1版,8月13日更新到1.2版,請嘉嘉、大胖跟謎樣的人物翻譯了多國語系的英文與日文(1.2同步更新),雖然上架1個半月並沒有顯著的成績(下載5500、實際存留2500、每日程式實際被開啟約3600次),但若要對這個經驗下一個註腳,我會說「美妙」。

我從來沒有想過曾經期望那充滿合作與討論的作業模式,竟然是在這個過程中體驗與獲得,可以感受到那些討論與文字是帶著Do our best的信念,是從心中想要把這件事情做好的感覺,三不五時查詢下載量、查看評價,討論每一個意見成真的可能性,一起對於得到一星感到失落,這些都不是過去四年多,任何一個人評論我寫出的程式時所感受到的。

除了我老哥與朋友們的意見外,7月12日我第一次正式接到來自陌生人的意見,我仔細地反覆閱讀這封信,想著每一個意見增加於目前程式架構的可能性,我不希望功能是硬加上去的,我希望每一個增加或改進都能符合程式基底的架構並且擁有相對應的配套功能,而不是單純完成程式的修改;在有限的時間內必須專注在能使OLAccount更好用的功能上,這也是我第一次體驗到完全依照自己專業與經驗的判斷,決定出每一個版本適合的變動,不是單純把某一張紙或EXCEL的列表完成,而是每一項都有他的道理與原因。

在回信中,我用了自己很喜歡的遊戲公司blizzard在藍帖中常用的語氣:
「這是一個好主意,沒有意外了話,你將在1.2版看到他的變動。」
「購買處與型號比較難廣泛套用在各種花錢項目上,我們建議類似的內容記載在備註中(記得嗎?備註越詳細,查詢功能將越強大)」

雖然我不知道現在1.2版上了,他是否還在使用,但我衷心期望他知道他的意見真的在1.2版增加了。

--------------------------------------------------------

就在OLAccount一邊進行,工作上要做的事情還是沒有間斷,同一時間處理的是某政府單位的iOS App,內容是資訊整合平台,得知要做這個專案時,其實內心覺得蠻開心的,因為我認為這是一個值得包裝,值得花時間設計,一定程度的包裝與設計將會讓這一個專案成果有除了收款以外,更無形的力量;另外,他應該會是一個有用的系統。

但整件事情並不像想像中那般有趣,實際專注在這件事情上面的只有一個人,只有一個人在心中認為這應該是一個'作品',而不光是收錢的理由,一如其他專案「過就好、低標準、結案至上」的氛圍,實在讓人很難提起勁,別說討論的激盪,甚至想要獲得有好好思考的話語都是笑話。

就在連續專案都是類似這種無所謂的態度後,我決定做一件已經不想再做的事情,即便認為再怎麼樣說也只會被看成一個不滿現狀的無聊抱怨,我還是在逮到機會的情況下跟兩位大人'溝通'了一下,雖然談論細節不盡相同,但問題主軸有兩個「我這類的工程師在專案與部門的定位是什麼?」、「我們是否有以團隊的模式一年一年進步,推出越來越像商用的作品?」。

答案其實在還沒有'溝通'前,我就已經知道了,但這件事情就跟以前我跟同事講的一句話一樣,「我們對於部門內分享氣氛薄弱停滯不前覺得失望,雖然我每次辦完知識社群都覺得很失落,但這不應該成為'自己'不做的理由」,所以即便我認為不會獲得什麼改變,我還是去說了這些廢話。(說到這,令人熱血沸騰的是,這一年在更多熱血新人加入下,討論與分享氣氛加溫,工作中也有更多'實質'的討論)

答案其實也就是我們自己感受到的:
對部門:「標案公司最重要的是標手,拿到案子與結案是一切的根本也是全部,你想要在過程中嘗試什麼都可以,那是你個人的選擇,但要的是結案。」
對專案:「PM認為你該涵蓋什麼就涵蓋什麼,你應該完成在這個專案沒人負責的地方,並且對這些東西負責」
關於進步:「一樣,這是你個人選擇,有人拿出更新的東西對我來說是驚喜。」

所以總結的說就是一個很現實的問題,也是一個公司的根本,獲利當然是最重要的,每一個專案對於公司或部門的實力累積其實不是這麼重要,我們並不著重在哪一個專案,若有新的斬獲我們稱之為驚喜;沒人做的部份請自己拿起來做,因為我們討厭不幫助別人的人,而前進這件事情不要要求別人但請你自行努力,你自己創造你的模式。

過程中提到品質提升可以藉由外包這件事情,大家對於外包都寄與相當大的期待,但我更想知道如何從外包上學習事情,是否藉由外包而使得部門也踏入了那一個區域,幾個案子後是否就可以經由部門內部的力量模仿出具備類似品質的內容,進而做出原創或改進後的作品?

--------------------------------------------------------

製作OLAccount時,除了上述的'溝通'外,我獲得了一個完整的系統開發工作,何以說完整?因為他包含WebGIS、MIS表單操作,便民專區、後台管理與一個查報的App,從需求、資料庫設計、程式架構等,全部的全部都可以任我操作,而且我會有一個很棒的討論對象與經過查核的基本資料,而從正式開始做的那天,我大概有四個月的時間可以做出雛型,這是一個大好機會,我想利用這個專案做些包裝與設計。

我並不是一個好的版面設計者,所以我花很多時間思考我想要的內容與需要呈現的東西,我畫了陽春的設計稿,試圖在部門內獲得這方面的幫助,但這件事情比我想像中要困難很多倍,我沒辦法很順暢的將那些意念實體化,這件事情竟然進行的比OLAccount的設計過程還要曲折;

我說:「如果要有很順暢的溝通,那麼我們必須要有微幅涵蓋對方所知道的領域,最快的方法就是透過一次一次討論讓對方學習彼此領域的基礎知識,這不就跟需求訪談一樣?」

我之所以會講出這句話,原因就是這件事情沒有成真,這就像在兩棟大樓間互丟東西,拿不到想要的東西。

某天,我跟嘉嘉說:「這件事情就跟決定要做帳本程式一樣,不做就沒經驗,做了就有新的體驗,當你真的實際花時間下去你就勢必獲得一些東西,而沒有別人協助或別人不做都不能成為自己不做的理由,這就跟知識社群一樣。」

所以,我決定讓這個專案徹底的'完整',我開啟photoshop,問同事問google如何去背、如何做漸層、如何做出清晰的字,甚至畫炊煙、畫icon、畫系統上需要的圖;要求很簡單就是一個乾淨、有整體感、有延伸效果的版面;原本我對自己動手做的時程是一個星期,但我後來發現這是一個必須不斷處理細節的工作,所以既然要做我就必須壓縮程式開發的時間,花更多時間在一兩個px間的調整,參考更多網站的概念與搭配,目前我獲得了一個自認為不錯的前台與後台版面,過程中甚至會對著版面微笑,也逢人就介紹這個親手打造的網站介面,就像當時介紹OLAccount的雛型一樣。

在製作的過程中,我認為這一個經驗某方面來說比寫程式更加有趣,因為他是一件幫你把作品穿上衣服的重要工作,穿的好氣勢跟品質截然不同,那為什麼我們不做呢?

到頭來這其實跟結案至上的根本價值有關,我們對於自己做出來的東西沒有認同感,有認同感的人不一定具備包裝的能力,也只能默默覺得東西就僅止於此,而這個氣氛的蔓延導致最終的結果。

--------------------------------------------------------

就在這兩個月,我上架生平第一個程式到Google Play上面,體驗了想呵護作品的感覺;對兩個大人廢話了一堆,想了自己的無奈與他們的無奈;不可思議做了自己的網站美編,享受主宰網站風格的奇妙感受;而這一切都源自於當時對於OLAccount的熱情與期待。

3Q~~~~當時執著的我。

2012年8月16日 星期四

OLAccount 1.2版更新

經過1.1版一些小規模的功能精進:

1.1版
* 新功能-你現在可以在設定中調整主項目與子項目的順序了。
* 新功能-在匯出匯入中可對某時間範圍內的資料進行封存。
* 調整-我們將匯出、自動備份功能儲存位置由SD Card根目錄改為OLAccount資料夾。
* 調整-匯入資料時將自動略過重複資料。(你將不用害怕重新匯入相同的資料)
* 改進-即使已經記載大量資料,自動備份也不會再有延遲的感覺。



1.2版終於在8月13日催生出來,1.2版不僅是將多人使用上的小意見彙整,更大規模的增加了原本OLAccount缺乏的收入管理,且因應收入管理的增加也配套的增加帳本鎖的功能。

版本:1.2
*新功能-你現在可以在收入管理內記錄你的收入,並查看各時間的餘額。
*新功能-你可以在設定中開啟帳本鎖,保護珍貴的記帳資料。
*新功能-我們也增加了收入項目新增、刪除、排序等功能。
*新功能-你現在可以在匯入匯出功能中寄送備份檔到指定的Mail。
*改進-首頁及歷史資料的種類統計將會依照金額排序。
*修正-現在匯入Excel編修過之檔案,不會發生錯誤了。(但仍要注意檔案應為UTF-8編碼)

1.2版在設定中配合收入管理與帳本鎖增加了收入項目的增加、刪除與排序,帳本鎖的開啟與密碼變更。

開啟帳本鎖後,打開OLAccount將不會直接進到原本的首頁,取而代之的是簡潔的帳本鎖介面,為了避免帳本鎖扼殺了原本相當方便的記帳流程,帳本鎖首頁除了可以輸入密碼以進入首頁外,也提供了直接可以記帳的按鈕,並且簡單的提醒今天記帳的筆數。
帳本鎖的增加過程中,思考了很久密碼遺忘的解決方案,最後採用簡易的提示功能,點擊忘記按鈕OLAccount將會提醒密碼的前後,以幫助密碼的回憶。
接著就是本次改版的大重點,許多人提出的收入管理,收入這塊也思考了很多整合的方案,但考慮到有些人僅著重支出記載的部分,所以最後還是採用收入與支出瀏覽介面分離的方式,但還是在中間考慮了收入與支出交互查詢的部分,大家除了可以從收入列表看到收入,還同時可以注意支出與結餘的統計,並且利用旁邊的錢字按鈕快速切換到支出列表。
第三個重大變更是在匯入匯出方面,增加了email寄送的功能,更快速的將記帳紀錄備份至任何一個電子郵件中,並重新確認了經由EXCEL編修可能會產生的日期問題。但目前仍有一個尚存的問題是:經由excel修改後的備份檔案,其編碼格式會遭excel強制變更,必須利用記事本等文字編輯器將其另存回UTF-8編碼,才可確保不會有亂碼的產生。
最後一個是記帳便捷的提升,以往若要記載昨天或前幾天的花費,必須要到首頁點選記帳後調整日期才能存入,但在使用上往往是觀看歷史紀錄或日曆時發現有漏記,最後決定在歷史紀錄移到'日'時,右上角增加記帳按鈕,讓整個補記帳的流程更為順暢。


最後,仍舊感謝您的使用與支持。