Feeds:
Posts
Comments

Archive for the ‘IT Management’ Category

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

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

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

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

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

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

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

Advertisements

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 »

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

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

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

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

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

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

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

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

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

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

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

Read Full Post »