August 01 09:43~11:46
這幾天雜事有點多，晚上又睡不好，寫部落格的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）」，慢慢了解到，喔，原來從「問題—>解法」的過程中，是有步驟與方法可依循的。
- 建立requirement model：把問題用use case寫出來。
- 建立analysis model：從use case裡面的名詞找出概念（concept），而動詞就變成這些概念的operation。然後建立起概念之間的關聯性（就是把有關係的概念用一條線連起來XD）
- 建立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。
- 實作：理論上，有了design model，就可以做到「按圖施工，保證成功」，直接用程式語言把系統實做出來就OK了。事實上，三個字：不可能。
- 測試：程式寫好之後要經過測試這一關，測試沒問題才可以釋出。
其他像是寫文件或是維護階段就跳過不談了。所以學完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。想說好不容易從學校畢業之後就不用思考這種人生的大道理，怎麼老是遇到一些很抽象的問題哩。哪天想通了再跟鄉民們報告。
***
友藏內心獨白：學軟體學到這樣會不會管太多啊？
沒有留言:
張貼留言