發揮團隊戰力

發揮團隊戰力

2008/5/14 09:35

職場上，我們在做事等於是企業出錢收買我們的個人價值。日常工作中，大大小小工作事務繁多，有些只有我能做，有些其他人也能做。做事之前，先明確區分哪些非我做不可的，哪些可以請別人幫忙做的。要知道公司付我們某等級薪水，表示我們所做工作也應有該薪水等同的價值。不過事實並不如此，很多大企業容易出現這種領高等薪水做低等事情現象，要改善此問題，先來要求每個人寫工作日誌，日誌內容應詳盡記載實質工作內容，如上網訂機票，開會前準備器材設備等，這樣就可剖析不同角色的價值與其工作產出是否”等值”，從而找出改善之道。例如發現一個協理經常需要花不少時間在訂機票、車票等鎖事上，表示他應該需要一個助理幫忙，讓協理能專心在他最高價值的工作上。

資深工程師也是相同，以軟體業為例，資深工程師領的薪水與新進人員一定有一段差距，但往往這些人員還是不斷在做著新進人員就能完成的事情，例如程式上線、文件裝釘、系統測試、撰寫程式等。資深工程師應該集中在系統分析或系統設計等較高價值工作上，較Low end 工作理應由資淺人員完成，因為這類工作替代性高，隨時可找到人替補。

達成上述目的的要件，就是文件。只要需要別人幫忙的工作，都需要文件。沒有文件，公司派100個人幫你也沒用。過去求快，不寫文件，所有內容都在腦袋，自己從頭做到尾，以為不寫文件，速度比較快。孰知一段時日後，自己要維護自己寫的東西時，難上加難。不只要花大量時間去回想當初設計的構想，而且就算很趕，也只能自己猛加班完成，沒有文件是沒有人能幫得上忙的。此外，因公司無法為你找到代理人，所以就算你去渡假了，因為沒有任何文件，完全沒人能接手，也只好把你call回來，以公司角度或自身角度都是百害而無一利的。

        寫了文件，很多工作都可同步進行。你可以寫出3份文件後，開始做第4件事情，同時就可找到3個人幫你工作，一時間就有4條生產線(包括你)同時生產，這樣工作效率極高，而且最後所有的功勞都是歸你所有，這麼好康的事不是夢想，關鍵只在於à文件，所以，從今天起，想一想，有甚麼工作是別人能代勞的，把工作內容寫下來，變成制式文件。你的工作效率一定能大幅提昇哦。

2011 台灣使用者經驗高峰會 心得

2011 台灣使用者經驗高峰會 心得報告     

2011/09/19 

這次研討會分成2部分，上午由幾位重量及嘉賓，透過主講及對話訪談方式，分享了使用者經驗(UX)的重要性，在企業推行的注意事項、技能養成、文化對UX的影響等。下午以工作坊方式讓學員透過實作，更深入來解UX的設計是怎麼一回事，我參加了D組的「Mobile App在實作之前」，由講述如何從構思、發想擷取需求，到製作草圖、原型、實作整個流程run一遍，獲益不少。

總結來說，上午在短短3小時內，能分享到共5位嘉賓經驗、獨特的見解，是本次研討會收穫最大的地方，下午參加的工作坊，透過小組共同合作初步完成一個Mobile App的原型，體會到Sketch的重要性，以及對其他組員有多一點的交流認識，是另個額外收穫，整體來說，也許這次的主題是UX，有別於過去所參加的硬棒棒技術研討會，多了些人性考量，感到額外新鮮，收穫良多，相信經這一陣子的UX課程後，將帶來更多改善中冠人機介面的靈感。

上午首先由「數位時代」主編王志仁開場白，他先開宗明義介紹了甚來是UX，UX不是純粹的「人機介面設計」或「產品的外觀設計」，是用戶使用產品或服務從頭到尾的軟硬體經驗，涵蓋了「心理」、「技術」、「設計」、「行銷」的整體工程。他舉了新加坡申請簽證流程的例子。當初新加坡政府特別請IDEO設計公司改善整個流程的UX，降低櫃檯高度，改善以往盤問民眾態度，提高官員對申辦民眾的親和性，提升環境柔和度(沙發、音樂、色調)，大大提升民眾滿意度。

接著由 UiGathering發起人介紹他們的組織、任務與定位，早在2005年，發起人意識到UX在台灣未被重視，希望召集其他志同道合的伙伴，透過定期小組討論會方式，逐步推廣UX的發展，隨著近年UX的日漸受到重視，活動規模日漸龐大，甚至到這次的高峰會共2百多人參加，並且早在1個月前就爆滿，就是他們始料未及的，日後他們將有更多的研討活動，北中南都有。

心得:最近被重視，應是被apple帶起的觸控式手機有關，而App Store的成功，更讓各大廠見識到軟體的威力。從台灣、國外幾間大廠最近頻頻棄硬向軟的走勢來看，可預見這股UX風潮將持續盛行。

第一場演講

從代工到全球消費品牌:經驗設計如何改變HTC

-          Drew Bamford HTC使用者經驗協理

主講者在2006加入hTC，從當時的hTC TouchFlo3D，到Android的hTC Sense他都有參與，他介紹了各時期產品的UX演進，目前主打媒體(音樂、影片)、社群及雲端應用。例如: hTC Watch(線上影片)、hTC onLive(雲端存取服務)。下一步則是Social+Media，類似Apple的Ping功能，可跟好友分享、評比音樂，分享使用經驗。

最後他分享了UX這份工作不是平好差事，除了有好的idea之外，還要說服長官、其他部門，與他們取得共識才得以順利進行，畢竟一個idea從發想到最後變成真正產品，中間要涉及其他因素，包括:市場行銷、製造、工程…等，他分享了當初2006年他提出touch的設計構想後，其他部門認為不好實作，技術難度高，普遍都不支持，最後周永明認為hTC不做容易的事，該接受挑戰而支持了這個方案。

第二場演講

打造優良使用者體驗:Google 如何專注在使用者導向的創新

-          唐絢Google亞太區使用者經驗經理

在Google, UX及技術是分開2個部門，但不是我做完換你做，是不斷的overlap，不斷調整。

在了解使用者需求部分，她建議應走出辦公室，實地到現場觀察、傾聽，往往會有不錯的靈感。在初期分別來自UX團隊、工程師、產品經理都會有四面八方的點子，這時千萬不要當下抹殺任何點子，初期雖不成熟，但往往能演化出成功的產品。相反若是覺得不錯的點子，也不要立刻埋頭coding，也許沉澱過一兩天後就會發現有很多要修正。

除了要有好點子，還須要有sketch能力，一有點子，馬上用最快速度 sketch下來，哪怕身邊只有餐巾紙。

心得:這點我是蠻認同的。現在普遍都用電腦做事，但很多發想其實需要sketch，sketch好或不好不重要，重要的事能表達出當下的想法就夠了。

Experimentation

在Google，research非常受重視，分定性及定量分析，定量可以窺探事實，但無法得知原因，定性可讓我們知道數字背後的原因。

他們曾經針對亞太區搜尋結果列表的字型、大小、間距做微調，來量測使用者的不同行為，得出蠻多意外的結果，這是科學分析很重要的貢獻。

另一個例子，工程師在開發Google Maps的手機應用時，跟著用戶在行進中的電車裡，觀察用戶如何操作，這樣才能體會出真正的 User Needs。

心得:以前使用瀏覽器時，都有習慣複製一段網址，貼到網址列，按Enter或「前往」鈕，自從有一天發現Chrome多了一個「貼上並前往」的功能，就覺得很貼心，這功能也許沉在心裡已久，但我們無法說出該用甚麼方式解決，而UX團隊就有辦法透過觀察及傾聽，發現我們的潛在需要，他們再將之化為需求、功能。

內部測試

Google的所有產品在release到市場之前，都會先內部全面使用測試，以及早發現bug，蒐集feedback，避免不必要的錯誤擴散到廣大用戶身上。

而內部試用時就大膽亂用，以最高規格來測試。

Collaboration

Google的UX Team跟工程師緊密結合，UX Member大都有技術背景，有了好的構想後大都有能力自行實作prototype，這點能夠降低技術團隊及UX團隊不少的溝通gap。

Google Philosophy

1．焦點放在重點。

一次只做一件事，且要做到最好，這樣用戶才能一看就知道怎麼用。

2．Fast is better thans slow

用戶體驗受很多階層、文化背景、角色影響，但有一個共同點，就是速度。速度不佳直接影響用戶體驗。

3．優化一定要有原因，不要隨性。

一個應用上線後，工程師總會看哪不順眼就修一修，覺得再做個x功能就更炫。一定要避免，任何優化都該有合理的理由，對用戶體驗有具體改善。

4．Focus on user and all will follow。

5．不要直接追求利潤，不必花太多心力promote，只要用戶說好，才是真的好。

專家高峰會

由主持人現場向各來賓提問，總結重點如下:

1．企業老闆仍以製造業思維來做UX，仍缺人性面層次的考量，應從更多軟體面配合，如辦公室配置、組織分工制度等。

2．有了好的idea，更要好的溝通力、說服力，才能cowork，才能說服老闆爭取資源。

3．要有英語能力，才能國際合作，了解別人。

4．要把UX做好，不只要有great idea，也要有基本技術能力，才能將idea化成prototype，有了prototype，一切就具體了，才能跟其他stakeholder無縫溝通，合作無間。

5．學校教的大都是專業科目，缺乏領導、溝通能力的培訓，但這些都是企業內跨部門合作的重要能力，在大家有共同目標、向心力後，合作才會順暢，才能成就大專案。

6．UX的工作不是只有畫美美的圖，更要具備向上、橫向、向外的溝通軟實力，除了本身的專業技術能力外，也要多吸收其他領域的知識。

7．台灣基礎訓練在良好制度下有不錯成果，但因太正規，導致無法在非正規條件、不合理的資源下做事。要突然間能交出東西，必須是平常已不斷累積，心中隨時有資源，才能處變不驚，所以基礎紮實的訓練非常重要。

心得:這場雖是UX討論，但從上午的研討內容，不只學到UX東西，更學到蠻多職場裡協同合作注意事項，以前都是從書本上了解，感受不深，由來賓現身說法確有不同體會。尤其像Google這類公司，一般外人不易了解到這麼細微的協同運作與分工，雖然不一定能直接套用，但已有很不錯的參考價值了。

下午工作坊主題為「Mobile App在開始實作之前」。

一般較沒經驗的手機應用程式設計者，有了一個點子後，沒想太多很快就寫程式了，然後就邊寫邊改，改到最後若發現整個主軸偏掉、很多缺點時，但因捨不得丟掉寫得很辛苦的程式而屈就，這都不是很好。

所以在手機應用開始之前，應該是從使用者的使用經驗著手。要了解使用者經驗，有幾個了解使用者的方向可依循:

1．使用者的身份是誰

2．甚麼地點使用

3．當下遇到甚麼問題

4．當下感覺

5．當下的想法

6．當下在說甚麼

7．當下看到甚麼

8．當下在做甚麼

我們小組就針對以上8種因素隨意組合，最後想出了一個Mobile App，名字為「Oh! Shit!」。

這個App希望解決便秘者困擾，重新回復腸道青春，尋回失落已久的暢通感。

在逐漸邁入高年化社會的今天，廠商相繼推出許多健康管理方面的軟體，有飲食的、減重的、血壓、血糖的…等，而盤踞癌症榜首多年的大腸癌也日漸受重視，而便便更是透視腸道健康訊息的最佳管道，管好便便，遠離大腸癌是這個App的最重要目的。

App分4大類功能:

一)    便便日誌 – 記下每次便便的日期及花費時間，以行事曆方式呈現。

二)    拍照 – 拍下便便，由雲端服務比對分析便便的大小、形狀與顏色，結合便便日誌資料、給出健康分析結果。

三)    社群 – 成立「便秘一族」社群，可分享便便照給社群好友。族群好友也可分享他們解決便秘問題的心得及記錄。

四)    音樂- 便便有時會有不小的「落水聲」，小鳥、小橋流水聲、輕音樂可避免這類尷尬。

整個App從一開始發想、亂扯、到最後慢慢收斂，有畫面sketch，操作流程圖不過是3小時的事情，雖然是很粗糙，不過寫程式之前該做的事情我們都有體驗到，也學會跳脫純工程思維的框框，設計出來的應用才會符合人性。

這個App雖然有點Kuso，不過我相信對有便秘困擾的人應該是個好幫手，這個idea的發起人就坦承他本身就有這困擾，說不定這App意外爆紅，還上新聞哩~

手機應用是最近2、3年的事，許多手機開發者原有的工作技能是網頁介面的設計，手機螢幕尺寸、觸控操作都與傳統桌面應用有著許多不同。觸控手機的操作工具是手指，按鈕不能太小，間距不能太小。手機可以有許多手勢操作，桌面應用沒有。手機也有許多sensor，有陀螺儀、加速計、GPS、相機、振動等功能，設計手機應用時記得擅加利用。

「單元測試理論與技術」上課心得

課程定位

在軟體開發過程中，從需求分析à設計à實作每個階段都有對應的測試工作，「需求分析」對應「驗收測試」(UAT)，「設計」對應「整合測試」(SIT)，「實作」對應「單元測試」，此即所謂的V-Model，而本課程著重在「單元測試」一塊，其它部分則安排在資策會的另一堂18小時的「測試技術理論」課程(98/12/13)中介紹。

課程簡述

講師是來自台北科大資工系的郭忠義老師，課程內容分「測試流程及工具」、「白箱測試」、「黑箱測試」、「物件導向測試」4個單元。早上介紹了「測試流程及工具」，測試流程為V Model，工具為JUnit，由於V Model與軟體工程息息相關，有了CMMI基礎下頗能理解背後的原理，而由於上課現場還有其他Java初學者(準備轉業)，因此講師也花了些時間介紹「軟體資訊業」的生態。

由於還有「白箱測試」、「黑箱測試」、「物件導向測試」3個單元要講，下午講師開始在趕進度了，其中一些講的不夠清楚或還來不及理解的也因為時間關係，最後也只能傖促教完，這些課程中較不理想之處。

白箱測試

白箱測試是等程式撰寫完畢後，依據程式撰寫結果推導出測試案例。主要分以下幾種覆蓋度:
1) Statements Coverage
2) Branches Coverage

3) Condition Coverage

4) Multiple-condition Coverage

5) All-Paths Coverage

依據對程式碼要求的嚴謹度來決定採用那種覆蓋度，覆蓋度越高，成本越高，一般只要做到Statements Coverage就夠了。所有測試案例是透過分析code得出，譬如用了一個 if…else，要做到 statements coverage，必須設計2個測試案例，一個跑 if 一個跑else，可以想像，code要是寫得很亂，用了巢狀再巢狀的if…，白箱測試一定會很苦!

由於白箱測試成本極高，一般只會用在跟生命有相關的飛航系統、核電廠…等，或跟安全交易有關的金融交易系統，對著重於企業需求面的ERP，使用「需求導向」的黑箱測試就已很足夠了。

黑箱測試

黑箱測試是將系統視為黑箱，只管input,output，完全「需求導向」，有以下技術:

1)    等價劃分

2)    邊界值分析

3)    基於決策表分析

「等價劃分」是依據商業邏輯中指定的範圍，設計出「合法」及「非法」的測試案例。例如允許輸入值x，其允許輸入範圍是 4，依等價劃分原則，我們需設計3組測試案例，即 3,5,12，2個非法1個合法數值。

等價劃分其實對稍有經驗的SA來說是很常用的測試方法，自己以前做過的「加班津貼」計算方式即屬此類，加班前2小時津貼費率為時薪的1.33倍，2小時以後的則為1.5倍，這樣「等價劃分」的「合法測試範圍」應為1小時、3小時，及非法的 -1小時。

	加班津貼費率範圍

 

                                               

「邊界值分析」需與「等價劃分」搭配，以同樣例子 4，其邊界為 4，10，因此測試數據必須是邊界值附近，即 3,4,5及9,10,11，套用上述的加班津貼費率例子，邊界值則為0.5小時，1.5小時，2.5小時。以這些原則得出測試案例的輸入資料後，再依需求算出「期望值」，這樣一對的「輸入值」及「期望值」就是測試案例了。

「基於決策表分析」

決策表分析是將所有的因果關係列出，針對所有的可能性都設計測試案例。例如

正式員工記小過扣年薪4%，記大過扣年薪8%; 約聘員工記小過扣月薪6%，記大過扣月薪10%。像這樣的需求，總共可列出16種排列組合，其中有意義的只有4種組合，因此完整的測試案例需提供12種非法資料及4種合法測試資料，看來這麼簡單的邏輯要做到完整的測試，真的很耗人力，若套用到真正的ERP系統真不敢想像。

物件導向測試

物件導向測試是針對以OO分析設計來打造的測試方法，比較接近UML的思路，若已熟悉OO分析設計就很容易接受這種測試方法，主要包含:

1)    狀態機導向測試

2)    情節導向測試 (即以use case為基底)

3)    繼承

4)    多型

狀態機是針對UML的狀態圖中的所有「狀態移轉」、「移轉限制」所設計的案例。

目前我們已有設計一套專門處理「狀態機」的公用元件，AP只須套用此元件即可，對應的測試案例應可減少。

情節導向則是針對use case的所有基本路徑、替代路徑賦予實質數據設計測試案例，是以user立場看待系統的測試方法，為目前design team主要的測試案例設計方法。個人是傾向這方法，只有一切以user立場思考時，才可能「做得最少，獲得最多」。

繼承、多型的測試則較像「uml 的白箱測試」，將uml圖攤開後，透過分析裡面的結構找出測試案例，與白箱測試有相同的困惱，即「成本太高、受限於系統設計技巧」，因此在ERP的領域裡個人較不建議使用。

總結

課程雖然有包括理論與實務部分，但也許講師來自學校，對實務之應用情境、經驗都較缺乏，無法具體介紹理論如何套用到實務。另外課程花不少時間介紹JUnit之使用，對已很熟悉的我們來說是有點入門了些。

真正有收穫之處應屬「正統的測試理論」部分，這部分提供測試案設計原則，讓我們對「測試案例的完整性」有個驗證準則，對QA SDS的單元測試案例時幫助蠻大的。

上完課後讓職有個感想，要完整的測試一個系統所有案例似乎是不可能的，雖說全部都測能保證最好的品質，但其所花費成本亦相當高，我們必須有能力衡量該做到甚麼程度，才有最好的投報率。所以回歸到最原點還是需求，只有具備堅實的業務知識，才知道「那些地方是系統要害」，只有這樣才能事半功倍。

說話的方式

 說話的方式

2008/3/14 06:17

說話態度需要謙卑，就算認為這件事情有強力理由支撐自己，表達是也要用「是不是xxx 可能會更好」，「我的意見是…不知道對不對?」，「原來設計意圖很好，但是否這樣可以更好…?」結束時，加上「這是個人小小意見，給大家參考」。

這樣聽起來，對原來設計者的攻擊性就大幅降低，也較能願意接納我們的想法。我們自己也常有這種經驗，吵架時，明明自己也覺得對方是對的，但是當下情緒實在不願意低頭接納，最多只是事後覺得對方是對的，在對方心裡還是覺得我還是不認錯。

這樣的溝通方式大打折扣，如果用前面的建議方式講話，溝通效果一定比你強勢指責式的提出意見來得好。提出意見時，對方若覺得你是「謙卑」的提出，大多願意能接受，我們提出意見的動機不就希望能讓對方接納我們想法，或者可一起討論嗎? 聲勢奪人的架式一開始只會讓人對你產生抗拒，後面你講話內容都會打折扣。所以要學習謙卑、謙卑、謙卑。

上司眼中的好下屬

上司眼中的好下屬

2008/3/19 06:20

上司希望交辦的工作，下屬能準時完成，若因工作量太多，臨時需處理事情太多而導致任務需延期，也必須事先告知，這樣主管心裡才能有譜，才知道資源該如何安排，或與客戶協商調整時程。否則矇著頭自己一直加班，甚至因為加太晚導致隔天爬不起來上班，更糟的是最後還是來不及完成任務時，主管不但不會體恤你加班的辛勞，甚至心裡還會抱怨這個員工怎麼每次都無法如期完成任務，偶如還會睡過頭不來上班，這樣我如何託負重要任務給他呢?

這裡指的穩定性，是要讓主管能夠「掌握你」! 主管就像打即時戰略遊戲的player，他需要知道他有多少兵，每種兵的特質，才能做出正確的佈署。如果其中一個部隊遭到敵方突擊，或遇到地雷之類的突來威脅，指揮官更應即時知道這些狀況，臨時調派人力支援或改變戰略，都需要屬下第一時間反應問題。遇到問題自己悶不吭聲矇著頭吸收，真的是一件吃力不討好的工作。

測試資料的設計

測試資料的設計

2008/5/10 08:15

測試資料的用途，在於為測試過程定義一明線的規範，希望達到”穩定”的效果。開發系統過程中，我們都希望一切都能在自己的掌控範圍中，包括時程，工時，成本，資源。軟體開發最困難、也最可怕之處在於隨時爆發一些事前無法預測的事情，臨時大幅度需求變更，導致整個系統架構重新設計，人力等資源需要額外投入，這些都是專案中很大的風險，發生時間點的早晚與他的傷害程度是呈反比，越早發現，傷害越輕，反之亦然。

專案在初期估算成本時，不像建築業，建築在期初估價時，可用預期的樓地板面積換算成建築用料得出建材成本，加上浮動不致大劇烈的人力成本，工期一般不會差太多，除非期初的地質探勘沒有找到地質的嚴重問題，等到開發時才突然引爆出來，就像高捷開發鹽呈區的地層下陷事件一樣。雖然在開發過程有這些風險，但專案的結案標準非常明確，建物落成之日就是驗收日，軟體專案可沒這麼幸運了。

因此軟體工程的大部份努力其實都在做風險控管，定義明確的測試資料可有效界定測試通過的標準，事實上在自己實地測試時，也都必須輸入這些測試資料，現在只是換成事前把這些資料事前定義清楚，有了明確的測試資料後，日後就可利用這些資料做到測試自動化。

系統設計心得

系統設計心得

2008/7/05 15:08

系統開發過程中，有了需求文件(SRS)後，接著開始進行系統設計，系統設計是一個過程，系統設計文件(SDS)是這個過程的結果，我們的重點是在「過程」而不是「結果」，白話一點是不要為了做設計文件而設計。

其實系統設計整個過程，就像是在揑黏土，假如想揑一個娃娃，我們會先把整個輪廓揑出，再來是頭形、身體形狀、再來四肢，有了大概的外形後，我們才會慢慢把臉形、手掌、腳掌，到最後的五官、衣服等細微地方。

在大自然界的不同演化進行都找到類似的痕跡，動物胎兒成長歷程也是先有心臟、腦部、骨架、內臟、四肢到最後的五官、皮膚、毛髮等，因此在這些演化歷程中，我們似乎找到一點點系統設計方法的線索。

跳脫軟體設計領域，回頭看一下其它領域的設計方法，無一不是先從規劃著手，再到整個主架構、骨架、抽象性的需求說明，到最後才是真正細部的設計。不過，綜觀我們現在的軟體設計方式，大部份人員是拿到需求文件後，就開始針對每一個需求直接coding下去，一直做到底，100%完成了一個需求後，再接著做下一個需求，可說是「非常垂直」的作業模式，如下圖。

上面的作業模式有何問題呢? 第一、寫「需求1」的code，因未考慮「需求2」、「需求3」，所以想出的方案一定是為「需求1」量身訂做，等到再做「需求2」、「需求3」時，發現有些東西在「需求1」的code可用，但又需要改一點點，懶得reuse的人會直接從「需求1」的code複製過來，想 reuse 的人就得回頭改「需求1」的code，當然，「需求3」、「需求4」、「需求…」都可能會遇到相同問題，也導致整個系統整合度非常低。

這種狀況套到揑黏土娃娃的例子，就像一開始就把頭形、五官、頭髮整個做出來了，才開始做身體、四肢，依這個步驟做出來的很大機會是不協調的。依照合理的發展模式，應該是「水平發展」，每個需求都粗略 review、思考過後，再往細部思考，作業方式如下圖。

因此，依照目前的作業模式，雖然已有部份人員會開SDS給外包人員編程，但一個需求一個需求開 spec，而且一開就開到很細部的設計，似乎仍欠缺整體規劃面的廣度。

假如我們在SDS產品之前，先經過「架構規劃書」、「初部設計書」的洗鍊，系統的整合度相對提高，甚至在系統間的介面整合細節也可以在這個階段先討論，更能提早發現問題。

「初部設計書」是可以用較為抽象性的說明，撰寫時需要「改來改去」的，而且必須很容易就能修改。目前SDS直接寫到很細部，寫到後面發現前面有些想改時，通常就懶得改了，因為好不容易將文件寫得整整齊齊，誰會願意為了更好的設計然後又把前面的翻掉重寫?

事實上，設計的過程本來就會這樣，人家的「服裝設計」、「建築設計」都是畫了一張又一張的設計草圖，摒棄掉了無數的idea，最後又重新拾回，有新的 idea 時還需相互討論，激發創意，這些歷程，就是「設計」。

   

 顯然我們目前製作SDS的方式是沒有經歷這段過程，SRS產出後就一股腦的為了交差，依照Template做出SDS，對解決方案的篩選、構築沒有經過深度思考，當然設計完客戶若稍加異動，系統設計不良的後遺症更原形畢露，這時候，只能怪「客戶亂異動需求」囉。