「流程管理系統」

昨天跟一位中學的師兄在電話上談論IT的技術。師兄以前是從事會計，對IT也很有興趣。由於對工作的環境不滿意，放棄了高薪的會計工作，轉了入一間知名的會計軟件公司。由於他對上市公司的合拼帳的運作很熟悉，負責設計新的會計系統。

在電話裡跟他談了很多不同的電腦技術。其中一樣比較新鮮的就是設計「流程管理」軟件，我的師兄說他的公司已經開發了一套「流程管理」Workflow的軟件，由於規模比較大，難於應用在小規模的計劃內。那套「流程管理」的軟件是從收購其他公司而得回來，未能融合在其他產品之上。他的公司曾經花了很多時間和資源去從新開發另一套「流程管理」的系統，但結果不理想，內部人士的評語是設計了另一套解讀c#的c#。這個奇怪的評語，指的就是，用一套類似c#的語言來表達整個流程，包括表達圖片及表真正的流程及其相關的邏輯。

令我想起了我公司那套專為「中介付款系統」背後的「流程管理系統」。設計者是其中的一位同事，是兩年多年的產物。主要的原理是利用邏輯而產生出SQL語言，然後將SQL執行的結果，轉換成流程。

我師兄的老闆是C#高手，而我的同事是SQL高手。他們在設計時難免會以自己最熟悉的技術出發。本來，這種思維模式是理所當然的。可是，c#或SQL太不像圖象，用他們來做圖象介面，不太合適。C#不能直接翻譯，所以用來表達「流程」的邏輯，吃力不討好，SQL處理邏輯不太靈活。這兩種電腦語言，用在「流程管理」上是「相去甚遠」。就算設計者是「神」級也要花巨大的氣力才可以勉強成事。

所以，每當我們要去解決自己熟悉的領域之外的問題時，要細心想想，自己所習慣的模式是否「相去甚遠」呢？

回到原先的問題，本人覺得，古老的「流程圖」還是最合適表達「流程」。則DOM是種很好的描述畫面的中介語言。最後，JSON是一種很好的溝通及直譯的電腦語言。所以，我們可以採用「流程圖」->「DOM」->「JSON」的方式來將「流程」轉化為「JSON」。「JSON」可以被儲存、提取及轉化為真的「流程」及其邏輯。

當然，我們亦可以考慮用XML取代JSON的角式，也可以用UML代替「流程圖」。設計理念是差不多的。

Read Full Post »

「協作管理」初談

協作管理，意思是管理多位作者同時創作的管理方法。「協作」這詞語最早被用在「谷歌」的「協作系統」中，可是「協作系統」的英文名「Google Site」卻沒有協作的意思。「谷歌」的「協作系統」是一個網頁系統。這個系統的優點是容許多位作者同一段時間去更改網頁內容。當兩位作者同一時間開啟同一份文件而又在差不多的時候進行更新，第一位更新者可以順利更新，新二位更新者會收到訊息，該頁已被其他人更新。這種型式，就是最常見的協作手法之一。

協作管理的最大的功用就是提供版本管理的服務。我們利用栛作系統，就可以追蹤每個版本之間的分別，以及由誰去負責某個版本等等。Open source型式開發的計劃，多數採用協作管理，這樣，不同的地域、時間的人，可以根據自己的生活的規律來參與Open source的開發，大家討可以利用「協作系統」來招募參與者、分配不同的角式、引發討論、分析問題、制訂目標、更新內容、版本管理、擬訂合約細節、編寫說明、進行翻譯、追蹤及跟進問題、甚至用作測試等等。

自從協作管理在互聯網上誕生後，大大小小不同的跨國性的計劃就不斷地展開。而不同型式的「協作管理系統」也不斷地誕生。最早期的有Concurrent Version Control, Subversion, Microsoft Visual Source Safe,..等等。以至到近期的github, Google Code, Google Wave, SourceForge, CodePlex, Google Site, OfficeLive, Google Documents, wordpress,…等等，不再局限在程式編寫，亦包括文件、網頁、繪圖、Blog等等的協作計劃。

協作管理將會是未來的「團隊管理」的大趨勢。

Read Full Post »

制訂開發軟體設計方針

管理開發團隊並不是一件容易的事。管理的方法有很多不同的種類，按照著不同的情況及需要來採納不同的管理方法。一般來說，制訂設計方針是一個其中的一個非常有效及重要的管理方法。

系統開發是一件很複雜及艱巨的事，在開發之前，就要考慮很多不同的因數，例如：不同的事故下系統的運作方式、系統備份、重新啟動、後備或替代系統、除錯模式、監察模式、工作分流、等等。

在開發每一個環節都需要考慮各種變數，對團隊來說是一個很大的負擔。團隊管理者可以透過訂立設計方針，來針對不同的情況所需要作出的反應。開發團隊的成員，只要跟從已經訂立的設計方針來設計系統，就可以集中在純設計方面。

訂立設計方針，需要對整個系統以及每一個參與或使用者都要有深入的認識。所以，在訂立設計方針的過程，很依賴管理者的經驗。可是，設計方針後，團隊面對最大的問題卻是在執行方針裡面。要團隊每一個人都樂於執行設計方針，是很艱巨的。

我的經驗是，引導團隊從已發生的問題上，去思考設計方針的問題。引導他們去提出不同的方案，協助他們去分析每個方案的優劣。每一位團隊的成員，就會很清楚「設計方針」是幫他們去解決現有的問題。況且，提案也是從他們的角度去提出，他們就會很樂意的去執行大家所制訂的「設計方針」。

一個有良好的「設計方針」及擁有執行「設計方針」能力的團隊，效率就會提高。

Read Full Post »

「同理心」與程式設計

我覺得電腦程式設計者有很多重要的素質，其中一個比較重要的就是「同理心」。

在論述「同理心」跟設計電腦程式之間的關係之前，先讓我講講在我的眼中，何為好的電腦程式設計。

我日常的工作包括維護及更新一個每天有九千多個訪客的交易網站。工作種類很多，按事件的輕重而決定先後次序。

1，當然是維繫網站的正常運作。影響到網站的運作，通常有三種原因。最常見的是設計的失誤，加上質檢不足夠，令到網頁本身有潛在的問題。第二種原因是突發的硬件問題。第三種原因，是受到駭客攻擊。

2，第二高的任務，就是推出能賺錢的新功能。

3，次要一點的任務，就是跟宣傳及推廣有關的任務。包括更新網站廣告、提交針對搜尋器的網頁到網站。

4，設計及更新為客戶而設的現有功能。

5，設計及推出公司內部使用的功能。

6，更新公司現有的內部功能。

7，為推行新的設計方針而引起的更新。

工作以設計為主，設計任何一部份都要有全盤的考慮。在公司裡頭能全盤考慮的人不多。所以，在任何設計之上，要預先制定設計的方針。

這些設計方針，包括：如何在硬件問題下運作、防避駭客的措施、減少重覆設計的措施、設定團隊的協作模式、畫面及用字的統一性、運算速度的考量等等。

我的其中一個工作就是制定及更改設計方針。

在這些方針之下，團隊的每一位成員都有很大的空間去設計。並不是每一個設計都合適最終使用者參與。

所以設計者能否從使用者的角度思考，決定軟件的質素。使用者又分很多類型，以報表軟件為例，有資料輸入員、列印報表的操作員、閱讀報告的管理人員、安裝軟件的技術員、有支援系統的技術員、有更新程式的程式員。每個使用者有不同的教育程度及專業知識，能掌握每種人的認知及反應，才能好好的設計軟件。

「同理心」越高越能代入使用者的心境，設計才會稱心。當然，這些都是建基於良好的設計方針之下。然而，「同理心」卻是設計的基礎功。而且，在制定方針的過程也涉及到很多思考，而這些思考需要有比較強的「同理心」。

「同理心」跟「從用戶角度」的分別在於「從用戶角度」出發時，我們希望能了解用戶所需，當我們從「同理心」出發，我們希望將用戶的難處，感同身受，從而希望從設計上將用戶要面對的難處，減至最低。

因此，我希望我的開發團隊能「從用戶角度」昇華至「同理心」的層次。

Read Full Post »

Javascript 問題引發團隊成長的反思

前一天，有一個入職差不多半年的Programmer走過來問我。

他剛剛做了一個只有標題、公司標誌、功能選單、底部註釋的網頁。這個網頁是他從其他網頁中將內容抽起而成的。他不明白為何他做測試時，瀏覽器會彈出Stack Overflow的警告。其他同事寫的網頁，沒有發生問題，為何他的會發生問題呢?

於是，我將他設計的網頁打開一看。發覺引致瀏覽器會彈出Stack Overflow的警告的原因，是網頁中的有一些Javascript發生了問題。於是教他從Javascript角度跟進。

過了一段時間，他還未找到解決方法，又再回來求救。於是，我幫他做一個更詳細的分析，發覺主要的原因，是有一段Javascript運行了多過一次。這段Javascript運行一次，網頁不會出現問題，如果運行了兩次或以上，網頁就會發生問題。然後，我就著他繼續跟進。

又過了一段時間，他又過來，匯報了結果。原因是他錯誤地使用一個其他同事開發的Asp物件。當他使用該物件時，做少了一個步驟。缺少了這一個步驟，該物件不能斷定自己有沒有重覆執行，所以，每次遇到這個物件，它都會將網頁加入一段Javascript的程式。由於這個Programmer年資比較少，對我們訂立好的設計認識不深，所以犯下了這個毛病。

聽到了他的解釋。我就問他，最終用甚麼方法解決？

他說他跟足訂立好的步驟就可以解決了。

我說，你的思考方式不正確啊！JavaScript 的問題，應該用Javascript 解決。Programmer的價值在於發現以及去解決問題。

他說那個ASP物件用了這麼久，不應該有問題。

我說，程式的好壞不在於運行多久。JavaScript 不應該設計成只許運行一次，這是考慮得不夠周詳的問題。最簡單就是加入防止重覆執行的機制，或根本性地作出改動。ASP的問題，用ASP 解決，JavaScript 的問題用Javascript 解決。每一層次都各自解決問題，才會減少漏洞。

能減少漏洞的人，身價才高。我常常跟新入職的同事對話，了解他們的想法及思考的模式。我希望透過交流，從而提昇雙方的思考層次。這樣，整個團隊的能力也能漸漸的提昇。

Read Full Post »