l

2012年8月1日 星期三

設計、設計

August 01 09:43~11:46

DSC01356

 

這幾天雜事有點多,晚上又睡不好,寫部落格的fu突然不知道跑到哪裡去了,昨天擠了好久好不容易才掰出一篇《馬蓋先與敏捷精神》。自從7/2成立泰迪軟體以來,Teddy每天都乖乖的到公司上班(公司目前只有Teddy一人XD)。舉凡打掃、到國稅局買發票、跑銀行、申辦電話、網路、買設備、印名片,一堆有的沒的大、小事,雖然沒什麼困難度,但是辦起來也是挺花時間與精神的。前兩天為了設計名片,不得已還裝了試用版的illustrator。不過最後還是在學妹的幫忙之下,才把名片搞定。

今天利用颱風作為藉口,留在家裡整理一下思緒(不過現在台北居然出大太陽…XD)。今天來談一下設計是什麼。話說N年前Teddy剛開始學寫程式的時候,第一個作業是要寫程式計算從1加到10的答案。雖然在上課的時候老師已經有教過for迴圈的用法,也告訴學生這個作業可以用for迴圈來實作,但是初學程式設計的Teddy,一開始的時候完全不知道要如何下手。當年又不像現在那麼方便,只要拜一下Google大神答案就出來了。找了好幾本書,又在電腦前亂試了好一陣子,才把作業給寫出來。

有一天Teddy遇到社團(電腦學會)中很厲害的一位學長,Teddy就問他:

Teddy:當遇到一個問題的時候,到底要怎麼用程式寫出來呢?

學長:很簡單啊,人怎麼想,程式就怎麼寫

Teddy:人怎麼想,程式就怎麼寫喔 疑惑。(這也太抽象了一點吧!!)

***

當時Teddy並沒有從學長的「金玉良言」中得到任何啟發…Orz,那時候只知道多看一些書本上的例子,然後有時間多寫一點程式,慢慢地,這個將問題轉成程式的過程就變得比較順利。當時Teddy內心所想的是:

要如何從「programmer(程式員)」,進化成「designer(設計師)」。

後來學了「物件導向分析與設計(OOAD)」,慢慢了解到,喔,原來從「問題—>解法」的過程中,是有步驟與方法可依循的。

  1. 建立requirement model:把問題用use case寫出來。
  2. 建立analysis model:從use case裡面的名詞找出概念(concept),而動詞就變成這些概念的operation。然後建立起概念之間的關聯性(就是把有關係的概念用一條線連起來XD)
  3. 建立design model:design model其實跟analysis model有點雷同,但是design model裡面的概念就是最後可以直接轉換成程式語言裡面的class或是interface,所以design model是比較偏向solution domain的,而analysis model是用來表達problem domain。有些概念在problem domain並不存在,而只會出現在design model。像是套用design pattern、interface的設計,這些就應該只會出現在design model。
  4. 實作:理論上,有了design model,就可以做到「按圖施工,保證成功」,直接用程式語言把系統實做出來就OK了。事實上,三個字:不可能
  5. 測試:程式寫好之後要經過測試這一關,測試沒問題才可以釋出。

其他像是寫文件或是維護階段就跳過不談了。所以學完OOAD之後,Teddy學習到一種「把問題拆解成解決方案」的流程,以及搭配此流程所需使用的技巧。這些技巧包含了基本的物件導向觀念、UML不同類型diagram的用途、如何建立不同的model(requirement、analysis、design、implementation、testing)。但是,這樣子就可以變成一位設計師了嗎?為什麼遇到不同類型的問題(不同的application domain),光靠這套方法所設計出來的系統還是漏洞百出呢?

***

答案說穿了很簡單,就是經驗不足。那要怎樣培養經驗?除了真的有時間與機會去參與不同應用領域的系統開發,另外一種方法就是去學習pattern。舉凡design pattern、analysis pattern、enterprise application architecture pattern等等。

到了這個階段,應該可以大聲的說出:我是一位設計師了吧?!

路人甲:什麼?設計師?不對吧,你們不是工程師嗎?我們(使用者經驗設計)才是設計師啊。

從軟體開發人員的角度來看,或是更精確的一點來講,從敏捷方法的角度來說,programmer其實也是designer。也就是說,設計師這三個字,在軟體開發人員的腦袋中,預設值指的是「軟體設計師」。最近Teddy因緣際會接觸到「跨界開發」的議題,也就是要把所謂的「介面設計師」與「軟體設計師」這兩幫人馬搞再一起看看能不能激發出什麼新的東西出來。從「介面設計師」的角度來看,開發團隊只有兩種人:

  • 設計師:很有創意的那一群人,負責分析使用者的問題,想出一堆有創意的設計。
  • 工程師:其他負責把東西做出來的人都屬於這一類。

一開始Teddy聽到「設計師」這幾個字其實覺得有點「刺耳」。

Teddy內心獨白:設計師、設計師。我也是設計師啊!

不過這不是重點,重點是,因為這樣的機緣,讓Teddy再度思考「設計的本質」是什麼這個問題。在跟幾位「(介面)設計師」聊過之後,Teddy證實了一件事,那就是:無論是軟體界,或是設計界(介面設計或是使用者經驗設計),其實很多所謂的「設計思考與設計方法」都是從建築領域借用過來的。

介面設計師甲:這些學建築的人認為他們最厲害,其他設計領域的人都要跟他們學。

畢竟建築的歷史比起軟體和其他設計領域都要來的久,所以跟建築領域學習也沒什麼錯。

***

Teddy:請問一下,你們這些所謂的「設計師」,真的有設計軟體操作流程(task analysis)的能力嗎?

介面設計師乙:科、科(搖頭)忍者

介面設計師甲:其實許多「設計師」,與其說是設計軟體介面,但通常只是做一些配色、畫面layout設計而已,他們並不懂的分析操作流程。

Teddy:但這些工作應該算是這些「(介面)設計師」的責任,不是嗎?至少從「工程師」的角度來看,工程師會期待「設計師」可以設計出好用的操作流程,這樣才能提供良好的使用者經驗。

介面設計師甲:這也不能說全部都是「設計師」的責任,因為有些操作流程還是要考慮到實作的因素。所以我們才會思考要把「設計師與工程師」擺在一起,互相合作。

Teddy:可是這些所謂的「設計師」不都自視很高,他們會願意在軟體開發的流程(就是Scrum啦)之下,來與工程師一起密切合作嗎?

介面設計師甲:這個事情在台灣也沒什麼人做過啊(至少沒有公開做過XD),所以從實驗與推廣的角度來看還是值得一試。

***

為了思考設計與跨界合作的問題,Teddy把塵封已久的《Notes on the Synthesis of Form》以及某本買了從來沒看的design thinking的書翻出來看。讀這種書真的有點累,畢竟Teddy又不是念建築的,而類似的觀念在軟體領域探討的比較少,所以看不懂的地方只能亂猜XD。

本以為自己的任督二脈早已打通,沒想到人身上的任督二脈還挺多的XD。想說好不容易從學校畢業之後就不用思考這種人生的大道理,怎麼老是遇到一些很抽象的問題哩。哪天想通了再跟鄉民們報告。

***

友藏內心獨白:學軟體學到這樣會不會管太多啊?

沒有留言:

張貼留言