Showing posts with label chinese. Show all posts
Showing posts with label chinese. Show all posts

Monday, November 16, 2015

學寫網頁比你想像的困難

前言

算一算大概是第十個身邊朋友告訴我想學習網頁,但仍沒有成功自己寫出什麼。這件事情進入一個需要靜下來思考怎麼回事的狀況,而我下了一個從我自身經驗上得到的結論:「大家把寫網頁想的太簡單了」。

學寫網頁的現況

很多人都會有學習寫網頁的這個想法,與想法後續的實現是如何的呢?

想寫網頁的原因

網頁是現代人每天都在用東西,甚至超過一天超過數個小時,而偶爾我們會點到一些設計非常動人的網頁、看到朋友分享自己弄的網頁、又或是看到某機構或教材宣傳著學寫網頁有多容易,上述這些時候都可能讓一個人開始想學網頁。

開始想方法

接著可能出現以下幾種方式
  1. 網路上找資料
  2. 書店買書
  3. 找課來上
  4. 問會寫網頁的朋友
這時,若有不錯的寫程式背景的人,或本來就善於學習各種新知識的人,任何方法都能帶領著他最終寫出一些成品。然而,對於這塊陌生的人,其中「網路上找資料」其實是把事情搞的很複雜的開始,因為有太多相關資料,如Google回覆我的第一個連結是Mobile01的討論串,雖說資訊豐富,但反而像是資料爆炸的受害者。

然後,卡住

一樣,那些自學能力超強的人可能這時已經寫出幾個成品。而有心卻不得其門而入的人,可能還在選擇要看哪本書、要用哪個工具、在研究朋友講的到底是什麼意思。時間漸漸過去之後,「最近比較忙」、「我有看一點前面的東西,後來沒時間」之類的話就跑出來了,同時也代表學網頁這件事情並沒有像想像那樣。

我經歷的情況

2011年夏天,在Stanford我修了"Client-Side Internet Technologies"這一門課,也是我開始寫網頁的起點,兩個月的時間,從基本的版面設計、客戶端程式設計到遠端資料呼叫等都學得頗扎實。2015年春天,在CMU我修了Web Application跟Advanced Web Design兩門與網頁相關的課,做出來的成品有Bug KillerTmate。至今我架設過的網頁應當超過30個。

於是,很多朋友會跟我說他們想學網頁,因為網頁在多數人的認知中是比較簡單的,我也盡我所能的提供我能幫助的地方,包含:

上Google或Product Hunt找好的網頁教學平台分享

若想自己寫Code的人,我則會分享W3CSchool的連結配合上Bootstrap的範例;而不想的人我則分享WordPress或甚至Blogger跟Tumblr。在我自己的經驗上,除非有特殊的版面或功能要求,不然既有的工具如WordPress等是最好的選擇。

自己寫學習綱要,包含學習內容、相關連結、範例等

對,我針對朋友願意花的時間,會列出一些步驟,如認識第一週HTML的標籤、第二週瞭解DOM架構等。然而我發現,若是有心的人其實不需要這樣的幫助,而這樣的幫助對於興趣不夠大但覺得網頁是簡單的人,也是沒有幫助的,因為最終仍是很難一步步走完。

在社團教寫網頁

2015年夏天,我在高中社團教學弟妹寫網頁,當時的教材在這個連結裡,因為是連續五天的Workshop,原本的Syllabus裡想要介紹到後端Node.js,然而實際上就只有教了HTML/CSS + JS,其中細節也被我略過很多。可見我也低估了學習網頁的難度。

困難點

說了這麼多,所以困難點到底是什麼?我覺得是以下幾點:

低估寫一個網頁需要的能力

「寫網頁很簡單啦,按一按就好」這句話不知道是否各位也常常聽到,我認為半對半錯。透過既有工具,確實按幾下就是一個網頁,而我會定義這是第一級的層次,其實就如同部落格,或你現在在閱讀的這個網頁。第二層次則是可以套用既有模板而做變化的人,如使用Bootstrap或Semantic UI等。第三層是可以全部自行設計的人。而針對需求會採用或混搭不同層次的做法。

如第一層次的東西來說,到WordPress.com上建立一個網頁、選自己喜歡的模板並不難。但是要開始套用套件,或是想要有修改設計時變是卡關的開始。

低估寫一個網頁需要的成本

要做一個有個人設計的網頁並運行他其實是有成本的,然而在很多數的人認知中似乎自動忽略這件事情。假設是一個靜態網頁,可用Github Pages,但是使用者需要如何使用Git,變回到「低估寫一個網頁需要的能力」的問題;如若是用學校空間、透過FTP上傳,那表示是學校在付營運成本;又或是線上各種架站服務,免費的其實都有各種問題與限制,使用者想像中想要架設的網站往往不是免費的。總而言之,要維持一個網頁持續運作是需要花錢的。

高估自己的動力

「想學一個東西」與「必須把一個東西學好」之間的分別對於包含我在內的很多人都常常會遇到分辨上的困難,如同前文描述的,開始學寫網頁時候,會有過量的資料出現在面前,不知道怎麼取捨。同時,也不知道自己要做的東西確實是長哪樣的,出現有點雞生蛋、蛋生雞的問題。

所以,我很常建議想學網頁的朋友先畫一張草圖(其實就類似正規的網頁開發流程中的Mockup圖),然後刪減上面的東西後,我幫忙選可以使用的工具。然後再一起評估需要花的時間後訂下學習過程中的milestone。

結語

從最早觀察到這個問題至現在,我持續想要解決或改善這個問題,然後讓大家最終都可以如願以償的學習到想學的技能,同時我更相信越多人的加入,可以讓網頁開發這件事情變得更豐富有趣。

最重要的部分是,上述的困難點都源自於學習者的「高估」或「低估」,於是藉由這個文章讓人更認識到一些現實層面會遇到的困難,同時我相信這也是解決問題的開端。此外整篇文章主要針對想學網站但不得其門而入的人,若本就是善於學習這種技能的人也許就不適用了。

對了,曾經我聽過一句話,要完成一件事情:我們需要一個計劃(Plan),還有永遠不夠用的時間限制(Not Enough Time),共勉。

Tuesday, May 12, 2015

[CMU V.S. 交大] - 學期末修課心得

Network Security 期末海報展覽

前言

落筆的此刻是學期結束的隔天,與撰寫前兩篇心得(學期初學期中)的動機是一樣的,希望把交換過程間的所見所聞與更多人分享。而不同之處是我已經在這兒待頗久,融入並適應之後很多想法可能較無法很客觀地從第三人角度撰寫。

學期初多半的精力我用在適應環境,然而學期中之後,因為幾乎每一堂課的主軸都變成Project,我在學習上的重點變成怎麼與人互動、和大家怎麼一起把東西做好,而不同文化的優秀學生合作經驗成為最寶貴的收穫。

以下針對我所修的四門課,在期末這段時間值得分享的地方,接著是我跟過往在交大學習經驗上的反思。

修課

Principles of Software Construction: Objects, Design, and Concurrency

這堂課仍一直是以作業考試為主的,課程目標是讓我們從較高角度但兼具實作的方式學習各種中大型程式的設計與需要用到的技巧,以下是學期後半段的作業以及簡介:

  • Scrabble:撰寫一個Scrabble遊戲(二維拼字遊戲),需要有介面並有好的設計以面對之後的擴充功能。其中有運用到多種Design Pattern,寫程式之前需先繪製程式設計圖跟助教討論
  • Socail Network Analytics: 這份是需組隊的作業,我與一個印度同學合作,需撰寫出一個可以針對各種Social Network裡的數據分析並製圖的程式。困難之處在於作業要求的是一個Framework,需要讓使用者可以自由加上不同Plugin的架構(例如,Facebook Plugin、Github Plugin),於是程式彈性是很高的,支援各種用途。這份作業分成三大部分,第一部分是把設計圖提出在助教課上報告;第二部分則是撰寫程式,包含Framework與數個Plugin;最後一部分是寫Plugin裝在其他組的Framework上頭
  • MapReduce:這是一個分散式系統中運算資料的方式,而作業需寫出數個Server跟Client同時跑以模擬一份運算怎麼在多台機器上頭分工後完成
整體而言,這堂課教導學生從原本寫單份的小型程式到架構較複雜的中大型程式。

Web Application Development

學期中我們作業是完成一個社交網站,其中功能包含註冊、Email確認信、登入、留言、上傳相片與即時更新等,最後再把網頁放到雲端服務上,我的做起來像是這樣

接下來的時間我們都分組完成一份Project,過程中有很多的次的進度報告,是在一個小會議室中跟助教還有一些其他同學報告、聽取建議。我們做的是Bug Killer,概念如StackOverflow讓人可以發問Bug與回答Bug,不同之處在於我們加上點數的功能,於是使用者發問Bug需要付出點數、回答問題則可以得到點數,且點數是可以用實際金錢買的,最終的作品放在這裡

其他同學有人做類似SoundCloud線上音樂平台、同時包含商家與客人端的點餐系統以及旅行路程規劃等網站。

Network Security

每堂課上課前的論文閱讀仍持續至期末考前,而Project部分我們每週見面討論,分頭做實驗,最後再撰寫一份論文並有海報的期末報告。我們做的是分析網路上販賣假YouTube瀏覽量的方式,透過實際購買假瀏覽量,我們能分析流量的特徵,並嘗試寫自己的程式去產生瀏覽量。論文放在這裡

期末的海報報告頗有趣的,在一個室內空間中有免費點心食物,然後感興趣的人會進來聽各組的作品,最後透過投票選出最佳的組別。有組別做新式的防火牆並在學校工作站上測試、有組做網線網路未註冊使用者偵測系統並錄製了影片展示等,大家都很愉快並認識彼此的作品、互相學習。

Advanced Web Design

這堂課總共有四份作業,最後另外有一個分組Project,且有一個共同展示成品的時間。我們做的作品叫做Tmate,靈感來自於我們發現設計師與工程師這兩個族群通常有各自的社交圈,彼此之間的交集並不多,然而以一個完整作品的角度而言,這兩個社交圈若能彼此認識是很好的,於是Tmate讓設計師與工程師可以登記自己的頁面、彼此認識,並可以依照專長搜尋。成品在這裡,是同時支援各種螢幕大小的。

Tmate網站支援多種螢幕大小

反思

交大修課的期末Project規模與完整度較小:發現在CMU同學們投入在期末Project的精力頗大,每個所做出來的東西完整度或規模,都是我先前在交大不曾做過的,而我這兒遇到的人大家都努力堅持到最後、不斷的修正問題直到最後一刻。

交大在專業工具上的使用上較少:如網頁設計的課,與設計師隊友使用Git同步程式碼省下大量的時間跟開發問題;Network Security的Project中我們使用LaTeX寫最終的報告,在架構與可讀性上增加許多。

不只是修課

有趣的是,在CMU這段時間裡,我學到最有用的知識其實並不是來自課堂,主要以下幾項值得分享:
  • VIM/zsh:從高一用VIM到現在我始終很難找到同好,甚至推銷總是失敗;然而在這兒我參加CMU電腦社團的講座,講者分享他的VIM用方式,以及很多我不曾知道的使用方法跟Plugin,讓我的往後打程式的效率又更進一步(這裡有他當時的筆記)
  • LaTeX:一樣是我以前接觸過但不曾學起來的東西之一,在先前的環境裡並沒有遇到其他人在使用LaTeX,而在CMU一位好朋友很喜歡LaTeX,跟她學了很多,現在我也能自己寫不少LaTeX的文件了!
  • Git:又是一樣的,過去我自己會使用版本管理系統,但是同學們之間並不使用,所以在這兒讓我有機會可以體驗Git在多人同時開發時候是如何的、又有什麼問題需要注意的

結語

網頁設計的Project我們在展示的前一天在圖書館通宵趕工,隔週週末我們一起去動物園玩;Network Security的Project我們合作間不時會吵架,但最終得了第二名,隊友們感情很好我們更曾一起去華盛頓玩;Principles of Software Construction分組作業的印度隊友則跟我一樣喜歡貼貼紙在電腦上,於是我們互送了很多貼紙;而Web Application的隊友則是我這段時間最好最好的朋友,我們總是一起唸書。

於是乎,在不同學校交換的過程中,最重要的是遇見什麼人,而大家彼此之間的態度又是如何。所學的知識固然珍貴,但會讓我難忘而永存的是這裡遇到的每一個人,以及我們如何互相對待彼此。誠心待人、遇到問題直問、專注並投入在自己的學習上是這回交換日子裡我學習到的態度,讓自己保有這樣的態度是不需要跑到地球另一端、也不需要花錢的。

* 關於交換過程更多的生活點滴:http://cmu.heron.me/

Heron at CMU

Sunday, February 22, 2015

[CMU v.s. 交大] - 學期中修課心得

晚上在學校自習

前言

在Carnegie Mellon University交換的日子已經邁入期中,我所修的其中一門課考完了期中考,其餘的則有Project在進行中。與學期初修課心得的想法的是一樣:希望把我所見所聞跟更多人分享。

在CMU要同時兼顧課業、社交活動與睡覺實在很困難,而我近日的時間安排則是:
  • 早上:寫作業、準備當日上課需要的閱讀
  • 下午:上課或討論Project
  • 晚上:參與活動或與同學討論作業
  • 深夜:繼續寫作業
每日睡五至六小時,但對於生活中遇到的每件事情都讓我很興奮,特別是在這裡新認識的每一個人;而,這篇文章我會將重點放在修課部分,以及我們可以學習的地方。

修課

這學期我總共修了四門課,分別是Principles of Software Construction: Objects, Design, and Concurrency、Web Application Development、Network Security與Advanced Web Design,以下我簡短介紹這幾門課的內容與特別的地方,而在「反思」的部分則描述與交大相呼應、可學習的地方。

Principles of Software Construction: Objects, Design, and Concurrency

這是CS二年級的課,但我在課程中認識的人大部份都已經是研究生了。內容以比較高角度的方式看寫程式的架構與設計,講述抽象的程式設計概念(Design Pattern)並學習畫UML圖(例如程式流程圖、物件關係圖等)。
這堂課每週都有作業,也是我起先花最多時間寫作業的一門課,使用Java:
  • 第一週作業:用BFS找出朋友關係圖中,兩個朋友的距離
  • 第二週作業:用Dijkstra's Algorithm找最短路徑
    • 使用匹茲堡真實的公車路線資料,規劃使用者如何從A站搭車到B站(如同Google Map的路線規劃)
    • 需要寫Java的UnitTest達到100% line coverage(就是每一行自己寫的程式碼都要寫出對應的測試程式)
    • 通過CheckStyle(即Java程式碼中的排版需要符合規定,並且有標準完整的註解)
  • 第三週作業:模擬匹茲堡城市中的公車與搭車情況
    • 練習中型規模的程式如何設計,作業中車子、車站與乘客之間有多種相互關係
    • 模擬各種細節情況,如:10%的人若是搭輪椅延後上下車時間,影響全部公車是否準時到達的比例是多少
    • 使用多種課程學到的設計概念
第二週作業我寫起來有5000行的程式碼,第三週不加測試碼的話則有7000行,是挺辛苦的一門課。下課時間德國教授被一大群的中國學生圍成一圈詢問作業的問題,過了快一小時都不能離開。然而,上週的期中考之後情況好許多,我也漸漸習慣這裡的作業方式了。

反思
這一門課是Software Engineering的前期入門課,也算是很多人修的二年級課,但交大其實並沒有對應的課程。
  • 交大程式教學重視語法跟完成度,但幾乎不管設計想法:我記得在交大第一堂C語言的課在教不同資料型態的語法;而在Stanford學習第一堂CS課程時候,教授刻意在前期都不講語法,而透過包裝好的教材(Stanford Karel)學習從較抽象的角度開始思考程式。同時,在交大多數助教並不會看每位同學的程式碼,但在CMU連變數名稱取不夠好都會被寫盡評分的回覆裡。
  • 交大程式課程沒有涵蓋「測試」:從這門課的要求中可以看出寫測試碼佔很重要的比重,每寫一小段程式碼就必須寫一段對應的Unit Test測試碼。

Web Application Development

這是一堂同時跨四年級與研究所的課程,學習用Django寫網路應用程式,是學校十分熱門的一門課,而每週都有作業。我個人先前恰好學過大部份的內容,所以還行,但對於沒有學過的同學,幾乎是一週要學一個新的語言:
  • 第一週作業:用CSS/HTML繪製出一個計算機
  • 第二週作業:讓計算機會動(我的做起來像這樣
  • 第三週作業:讓計算機在Django上跑
  • 第四~第六週作業:寫一個社交網站,可以註冊、登入、留言、評論與追蹤等
作業是做一個類似於Facebook的社交網站

反思
  • 交大的網路應用程式設計並沒跟上時代,多數同學都是自學:應用程式在交大的重視度較小,而網路應用程式則被包含在資料庫這門課底下,使用PHP;雖然PHP不失一種易學習的語言,但有較完整架構的Django或ROR並沒有課程在教,而CMU這裡則是已經從Java換到熱門的Django架構(今年)。

Network Security

這門是研究所的課程,與矽谷校區的同學同步,所以上課前都會開啟教室視訊,對方教室的同學也可以發問。是一位印度教授在授課,剛開始的前幾週偶而會漏掉幾個聽不懂的字,但漸漸有改善。
除了上課以外,這門課到目前為止做了:
  • 每次上課前閱讀一至兩份論文
  • 作業一份:寫防火牆
  • Project討論
論文一篇約十幾頁至三十幾頁,起先我需要花半天的時間才能瞭解一篇論文大概在講述什麼,漸漸的配合上閱讀技巧,可以在兩小時內抓到一篇論文的討論的重點,也會稍微跳過一些細節部分。

其中防火牆作業用到我過往在交大OSDI課程中學到閱讀大型程式的方式(cscope, ctags)以及修改kernel code的經驗,而有些同學並沒有相關的經驗則在這次作業中挺卡關。

Project部分近日也在進行中,我們會與微軟公司的一位研究員一同合作、定期開會討論,成員有韓裔美國人、土耳其人與印度人,與其他成員聊天、討論是最有趣的部分。

反思
  • 交大要求的閱讀並不多:雖然許多課程都有買教科書,但是會閱讀完的同學並不多,我認為與學習環境的關係最大,如果多加些閱讀的作業會有幫助。
  • 交大課堂產學合作較少:如這堂課我們組選定主題之後,老師找了一位微軟的研究員與我們共同進行,所以可以使用到微軟的資源,最重要的是研究內容可以使用真實在運作的服務,而非只是實驗室內的小模擬。

Advanced Web Design

這是設計學院的課程,教的是進階的網頁設計,相對於其他CS的課程,這門課其實相對輕鬆許多,老師對於作業的要求較有彈性,也很重視討論,於是有一半的課程只有討論,大家跟附近的同學聊天、老師則會與同學一一了解情況。

第一次作業是將現有的FBI網頁改成現代的新網頁,同時支援電腦、平板與手機(我的作業在這裡),設計是一個不斷問題修正與討論的過程,寫作業的過程是我學習到最多的部分。

由於交大沒有相對應的課程,所以「反思」部分則略過。

整體修課而言

  • 交大修課其實是很輕鬆的
    • 交大作業期限通常是兩週以上,而CMU作業大部份是每週一份,且都滿大份的。
    • 交大上課同學打混比較多,在CMU多數人都很專注,且積極問問題,特別是Design Pattern那門課,如果錯過一些概念就會跟不上。
CMU的資工系大樓,比爾蓋茲所建

結語

雖然生活很繁忙,但是我十分喜歡這裡,在課程中學到的東西比以往扎實許多,而每一個不懂的地方都可以問很清楚,身邊也有很多實事求是、打破砂鍋問到底的同學,我也認為這是求學最好的態度。

Wednesday, January 21, 2015

[CMU v.s. 交大] - 學期初修課心得


前言

在Carnegie Mellon University交換過了快兩週,選課差不多都確定了,而部分課程的第一次作業也交了;這回交換的機會主要是透過交通大學協助的,而學校除了把學生送出國,也期望能把所見所聞帶回來分享,所以寫了這篇文章。

首先,透過幾個數字簡介CMU這所學校:
  • Computer Science世界排名第一(2010年華爾街日報)
  • 校園人數約6000人,一屆交換生約50人(這屆兩個台灣人)
  • 學費是交大的20倍
而我修的課有:
  • Principles of Software Construction: Objects, Design, and Concurrency
  • Web Application Development
  • Network Security
  • Advanced Web Design
前三者是CS類的課,最後一個則是設計。除了選修的課,開學第一週我也多去一些後來沒有選的課旁聽,加上幾年前在Stanford修課的經驗,我想針對這兒修CS課與交大不同處列出來,先是CMU優於交大資工的部分,其次是交大資工優於CMU的部分。主要是討論修課使用的工具與修課方式,而非學生態度、文化之類的。

CMU優於交大資工的部分(個人觀點)

Git

我所修需要寫code的課都用Git來發作業、交作業,所使用的是Github的Organizations,可允許老師與助教個別pull&push非公開的程式碼給學生。比起E3好幾個莫名的跳出視窗好很多,而Git也是實際與人合作時必備的工具,從學校開始有很好的使用基礎。
當然,非公開的Github使用方式是要付費的,CMU這樣的方式一門課約需要幾千塊台幣,而自行架設Git Server不妨是個省錢方式,例如吳育松老師網路安全實務的作業就使用Git繳交。

Piazza

從幾年前在Stanford修課到現在的CMU,這是幾乎每一堂課都會用到的平台,他能讓:
  • 學生自由發問問題(可匿名),老師、助教或其他同學可回答問題
  • 發布公告
  • 協助報告分組
就如同交大的E3,但比較好用且跟Email結合挺好,所以有人發問或回答問題都會被通知。還記得有一堂課因為課程中太多人問問題,怕耽誤到進度,於是教授放一台iPad在講台,若有問題則用Piazza提問,教授會統一回答。上頭同學們總是很熱絡是這平台最有價值的地方吧!

Testing & Checkstyle

對於作業,我在交大的經驗是必須要達到作業要求的功能,而至於方式與品質若沒有要求就隨意。但CMU跟Stanford修課的經驗中,滿講究code的品質,以下幾個例子:
  • CMU與Stanford的Java課程會要求學生寫完整的註解,前者甚至需要符合JavaDoc、跑Checkstyle(檢查code所有細節的工具,包含註解完整性),完成後再寫UnitTest後檢查Test的覆蓋程度(是否每行code的所有情況都被測試過),最後才繳交作業
  • CMU與Stanford中與網頁前端有關的課程都會要求要經過Validator測試(檢查語法是否正確),其中包含HTML與CSS

產學合作

主要講的是課程中有外部單位加入課程的部分,以下有幾個例子:
  • Rapid Prototyping是一門讓不同領域學生選修、組成小組做作品的課程,我去上前兩堂課,學期中各組必須要設計出解決「客戶」需求的產品,而這學期的客戶則是醫療看護,於是課程中老師視訊了三位照顧病患的人,有病患家屬、護士與研究單位等
  • Network Security有期末Project,今天老師才宣布有外部公司提供獎金給比較好的Project

Reading

交大大部份的課程靠老師的投影片就可以考試。而CMU跟Stanford滿多課都會被要求要讀課本或論文,有些課是在第一次上課發的課程行事曆中會包含每週應該要閱讀的課本章節,可能包含隨堂考;而我修的一門研究所課程則是每週要讀一兩篇論文並寫感想,若沒有讀的話上課容易聽不懂,所以一學期下來要讀的論文大概這麼多...


交大資工優於CMU的部分(個人觀點)

圖書館

交大的圖書館藏書實在頗多,在學校總是可以很容易的借到幾乎任何一本電腦相關的書籍,且熱門的書籍甚至有好幾本,還有不少線上資源。CMU我則找不太到,也發現他的書並沒有很多,且課堂修課要用的書在學校書局也沒有賣,得自己上網買。

教授很親民

由於交換生不太能在選課系統上選課,所以CMU開學的第一週我花大半的時間在一一找教授加簽,也發現這兒大部份教授實在很忙,除非是修課生或有直接相關的事情,Email常常不會被回覆。例如很多教授會在自己的網頁上寫怎樣的Email是會被他忽略的,而Email又該如何寫才可能被回覆,應該是因為他們Email都是公開的,必定有很多想要申請入學、申請研究工作或外部公司等的信吧!而在交大我們總是可以很容易找到教授、安排會面時間等。

結語

個人覺得課堂使用版本管理系統、作業要求寫測試與足夠的參考資料閱讀是在交大修課過程中不足的部分,但也是很容易學習的部分。而在美國的習慣中較個人主義,所以任何問題必須要自行去問,才有可能被解決,這也是我學習的過程之一;相對台灣,我們有很多的資源如圖書館跟教授其實都是很珍貴的。

Friday, November 14, 2014

Business Model Canvas的九個欄位

獲利時代(Business Model Generation),大概是第三個人跟我推薦這本書之後,我終於買了它。書中的Business Model Canvas讓我用更完整的方式去看一個專案或產品,以及它與市場的關係,也很想分享這個書中最重要的Business Model Canvas,讓更多人可以一起發想與設計,做出更多人們想要的商品。

前言

以往在討論專案想法或規劃時候,我們會約略感覺到哪部分有不足,而也可能在執行過後才發現有東西忽略了,即表示缺乏一個可以設計周全的方式。而書中介紹的Business Model Canvas是很好的工具,透過思考表上的每一個欄位,我們可以很清楚的讓參與人知道專案目前的定位與運作模型,同時會不斷變形與進化以適應專案發展。最終目的則是找到一個可以讓專案或是公司順利運作的模型。


內容結構

書的第一章節講述了Business Model Canvas表格中的九個欄位與對應的意義,我認為這是最重要的部。而中半段則是針對各種Model進行討論與分析,其中我認為最有趣的是在探討「免費服務/商品」是如何辦到的這部分;另外也介紹一個商業模型設計與討論的發展環境應該是如何。最後部分則是探討如何不斷適應與修正模型。


Business Model Canvas的九個欄位

把這九個欄位:發想、討論、不斷修正,專案就不會再虛無飄渺了。第一次的思考過程是可以同時依照順序的,所以在思考一個元素的時候,不需要馬上就思考其他元素互相影響的關聯關係,可以建立在前一個元素上往下思考。(我照自己的解釋方法翻譯成中文,可能與中文版的不同)

A. 目標客層(Customer Segments):要賣給誰?

首要,必須將客戶對象描述的非常精確,什麼樣的人?年齡層?區域?他可能是「大眾市場」、「部分小眾市場」、「多元化市場(兩種無關的客戶層,如Amazon提供網路書店與雲端伺服器)」或「多邊市場(面對兩個以上互相需要彼此的情況,如點餐系統須要有使用者與商家)」。

B. 價值主張(Value Propositions):要賣什麼?

就是要賣的商品或服務是什麼?有了目標對象之後,我們便要思考我們是要解決他的什麼問題,所以要提供他什麼樣的東西。這個東西的特色可能是:新穎的、比以往效能更佳的、或是更加便利等。

C. 通路(Channels):透過什麼方法賣?

要賣的商品或服務如何傳達到我們的目標對象?直接的銷售,或透過合夥的間接銷售。這兒有個有趣的點,注意到傳達過程不單單包含「購買」這個行為而已,應該依序為「認識品牌與產品」、「評估產品」、「購買」「傳遞價值主張」、「售後服務與關係」。

D. 客戶關係(Customer Relationships):跟客戶的互動關係是什麼?

客戶看到的除了商品之外,還有這家公司與他互動的行為,即是客戶關係的範疇。可能提供個人協助(如電話客服)、自助式(如洗衣店)、自動化服務(如網站購物推薦)、社群(如小米手機的米粉們)或共同創造的關係(如YouTube讓使用者提供內容)。

E. 收入(Revenue Streams):賺多少錢?

恩,就是以上的元素拼湊起來之後,哪部分可以賺錢?而又是賺多少錢?它可以是銷售費(賣多少賺多少)、使用費、會員會費、租金、授權費或廣告費等。就算是提供免費的服務,也一定會有其他Value Propositions可以賺錢,不然必定無法維持。

F. 關鍵資源(Key Resources):我有但別人沒有的東西是什麼?

在執行的過程中,我們的不可取代性是什麼?當遇到對手時,客人一樣會選擇我們的原因是什麼?是因為我們有別人所沒有的金錢資源、人力資源或智慧財產等?

G. 關鍵活動(Key Activities):為了維持以上東西,需要做什麼?

模型快要想好了,但是為了實現模型的內容,我們應該要做什麼事情來維持?例如要生產產品、要廣告產品、要維護平台運作等。這個欄位是要列出我們要做的事情。


H. 關鍵合作夥伴(Key Partnerships):夥伴有誰?

這部分其實是選擇性的,也可能沒有夥伴。但夥伴的存在可以協助我們降低風險、取得特定資源等。

I. 成本(Cost Structures):要花多少錢?

最終,為了維持所有上述的事情,需要支出多少,包含固定成本與變動成本等。當然,成本如果大於先前討論的收入,整體而言就是賠錢(但不代表不能這麼做)。



結論

透過思考以上九個欄位,再與其他人不斷發想與修正的方式,可以讓專案的發展更完善,做錯事情的機會降低,或是看見先前忽略的部分。很多有經驗的人可能早已內化這些內容,但是若能畫出來放在白板上,大家可以更明確的同步腦中想法,或是做下一步的討論。

Monday, August 4, 2014

Carnegie Mellon University 卡內基美隆大學

在幾次和同學聊天的過程中,發現仍有滿多人不認識這所學校,於是透過這篇文章介紹,同時也讓自己更認識CMU。關於CMU的資料不論在學校網站或Wikipedia上都十分充足,而在此我是將台灣學生較關心的一些「事實」列出,並附上值得閱讀的參考資料。


簡介

  • 中文名:卡內基美隆大學
  • 英文名:Carnegie Mellon University
  • 位置:Pittsburgh, Pennsylvania, United States (美國, 賓州, 匹茲堡)

  • 校訓:"My heart is in the work."
  • 成立:1900年

學院

  • 科技工程學院 Carnegie Institute of Technology
  • 藝術學院 College of Fine Arts
  • 人文暨社會科學學院 College of Humanities and Social Science
  • 工業管理研究所 Graduate School of Industrial Administration
  • 公共行政管理學院 H. John Heinz Ⅲ School of Public Policy and Management
  • 自然科學學院 Mellon College of Science
  • 電腦科學學院 School of Computer Science

校友

  • 詹姆斯·高斯林 (James Gosling): Java程式語言發明人
  • 安迪·貝托爾斯海姆 (Andy Bechtolsheim): Sun Microsystems共同創辦人
  • 吳恩達 (Andrew Ng): Coursera創辦人、參與Google Brain與「百度大腦」計劃
  • 交大資工系吳毅成、吳凱強等教授
  • 19位諾貝爾得獎者
  • 12位Turing Award得獎者

排名

  • QS World University Rankings (2014):CS世界4名
  • Academic Ranking of World Universities (2013):CS世界6名
  • U.S. News & World Report ranks:CS研究所第1名
  • 華爾街日報(2011):CS第1名
簡而言之就是Computer Science中優秀的學校,以下是之前Facebook創辦人到CMU訪問的一小段影片:


傳統

  • The Fence(籬笆):學生用手油漆上一層層東西在籬笆上
  • Spring Carnival(春季嘉年華):「Buggy Sweepstakes」是嘉年華的特色,學生把人裝進小的輪車中,看誰在最短時間滑下山坡
  • Mobot(機器人比賽)

參考資料


Thursday, July 31, 2014

你為什麼不踩草皮?


我們大學校園的中央有塊草地,位置在最多人的資工系工程三館與圖書館之間,每天經過的同學相當多,是絕大多數學生上課必經的區域。而我們觀察到每位同學都會繞過草地,而放棄比較快的方式:直接穿過。為什麼?

「因為小學老師說不能踩草地」、「大家都繞過去我就跟著繞了」、「草不是不能踩嗎?」是我問了近十個人中得到的答案,這些答案也成功順服著大家不該踩草地;然而當我們回到問題本質時,這是否真能夠清楚解釋並令人信服?

造景與美觀是我詢問多位同學之後得到這塊草地的設計目的,讓我回想起過去與設計師討論的內容,「設計必須要解決最初的問題」;而這些草地在本質上已經逾越造景與美觀的功能,儼然變成一個校園大路障。當本該只是美觀用途的設計影響到既有本質上的功能時,是否其實是一個錯誤?

曾經去過美國與歐洲,那兒草地是讓人放鬆的地方,不只是穿越,大家更喜愛在上面玩耍或曬日光浴。台灣氣候或許不同,所以從小被訓練不該踩草地;於是乎,在我們校園的例子中,同學不但少了一個可以玩耍與發揮的地方,甚至連每天在校園走路時都需要繞路。

這問題很嚴重嗎?我實際在現場測量,繞路一次會多花10秒的時間,校園有萬人以上,假設平均每日有2000人經過、在學學生與教授的時薪平均值為每小時200元、一年中有200天的在校時間,則得每年學校因為繞路而浪費掉的錢是22萬元。是的,22萬元。

不論是重新設計草地位置,或是讓大家就直接踩草地而過都是解決之道,只是這故事或許不只是草地,也投影在很多日常生活中。

我們應該當參與過沒有目標而無效率的會議、不知道為什麼而做的工作、不知道在教什麼卻還要念的書、⋯⋯,當下我們感到難受,或是已經無奈而無感,認為「因為大家都這麼做,所以我也該這麼做」或是「事情就是這樣,做了就會對了」,卻沒發現或是沒有足夠勇氣去思考問題的本質。

也許這個會議不開反而對大家都好、也許這份工作目的根本不明確而該去叫主管修正、也許這老師也不知道自己在幹嘛而應該翹課;太多的既有習慣讓我們忘記去思考問題最初的樣子,而盲目堅持。

我們正在做的事情到底有無解決到問題,意義與目標是否明確,還是只是無感的跟著大家繞過一次又一次的草皮,忘記停下來想想:為什麼草皮在這?它應該在這嗎?該踩嗎?

Sunday, June 29, 2014

PLATE點餐系統 開發手札

PLATE團隊負責人 Heron Yang 筆

PLATE點餐系統於2014年春天在交通大學第二餐廳運行一個月,累計約600位同學下載,數百位同學在系統上點餐,是由自發性、興趣與熱情驅使的在校同學共同開發15個月完成。
官方網站:http://plate.tw/,粉絲專頁:http://fb.com/plate.tw


Part 1 - 開發

2013年春,有位社團學長知道我對於專案開發有興趣,同時過去也有幾個小作品,於是找我參與他們已經有兩個人的小團隊。當時我第一個反應:「應該和先前好幾個團隊一樣,說比做還多,不會成功的」;然而第一次我們在一個借用的社團裡面見面,發現大家都很有熱情,紛紛把自己想做的題目丟出來腦力激盪,這成為了PLATE這趟旅程的起點。
蹲在社團的白板前,三個人輪流寫出自己想做的題目:Tim想做個股票相關的應用,Fucxy想做吃飯相關的應用,而我想做穿戴式裝置相關的應用;最終我們共同發現一個需求:「吃飯時候,總是不知道要吃什麼!」於是開始思考用Machine Learning整理餐點資訊後,提供點餐建議的應用,也開始構想怎樣的服務是每當吃飯時候就會想使用的;所以,我們有了一個大致的專案定位:想做一個餐飲的平台,而凡是吃飯時間,大家就會上來選餐、被推薦餐點。
當時我們在網路上做了些調查,看到Food Panda、EZTable、摩斯漢堡等類似服務,也閱讀了Peter的午餐大王夢文章,甚至實際拜訪了某個小公司的老闆,談論是否合作建制餐廳地圖。那時候我們第一次像是大人一樣的奔波,談論似乎跟商業有關的事業。
記得當時有一天,在我前往上課的路上,看到邵家健老師路過,而我知道老師在以往課堂上一直很支持學生的專案與創業,於是我便向前跟他討論起PLATE的構想,他十分激動,也告訴我們他的研究室有個相關的研究,認為這樣的應用很有需求,於是我們專案成為了老師底下的專題之一,回想起當時若乖乖去上課,而沒有為了自己想做的事情翹課的話,接下來一年半的PLATE應該壽命會更短。當我們確定目標之後,除了要有勇氣去追求,也要有勇氣去放棄。
從三月份我開始參與計劃,四月份準備開始執行開發,找了一位同學當設計(綽號Bass),幾次至半夜三點的會議決定出Logo與配色,也決定第一期開發使用者會有的功能:「查看推薦與點餐、查看列表、餐點與社交、查看點餐記錄、設定」,租了一台Linode機器,申請了PLATE.tw網址。團隊成員每個都以很高度的熱情投入,Tim把Coursera的Machine Learning在一週內啃完,而我則是把Stanford的iOS App Development的課程上了七成,也跟著寫了數個練習程式。
暑假期間,團隊一週有三天齊聚在社團開發PLATE App,每天八小時,相當高的效率也讓我們在暑假結束之前,有了一個Demo版本的iOS App可以展示,甚至還拍攝了一個介紹影片
回想起這段時間,是我們生產力最高的時期,早上構想的程式,下午能在分工下就完成並測試,那時的我認為動手做遠遠勝於嘴上談兵,每當一個想法浮現,花在討論與規劃上的時間並不多,而是埋頭寫程式,讓東西在最短時間內被生產出來。然而,也因為如此,這段時期雖然大家熱情最高,但也是做錯決定最多的一段時間,我們在往後的階段丟棄了幾乎所有這時候做出來的東西。

Part 2 - 團隊組成

時間來到九月,在與老師溝通之後,團隊極力想安排與資工系的會議,原因是我們的作品必須在更多人的檢視與支持下才合適拿到餐廳裡使用。然而,這場會議讓團隊整整等了一個多月遲遲沒有開成,我們寄了超過三封的郵件,甚至直接印出報告書投交到辦公室。當時團隊氣氛低迷,Fuxcy在一次意見不合的會議中離開了,而我和Tim則在牆上,開始畫著規劃圖,內容是會議若是開不成的Plan B、開不成也營運不成的Plan C、…,我們一路寫著至年底最壞情況的計劃。
這時Anthony加入團隊,負責Android程式這部分,也就是接寫Fuxcy原先的東西,但是當時我們並沒有持續開發,反而是找了與原本題目相關的其他小程式實作,原因是PLATE這個東西很大部分在運行上需要透過系上或學校的允許,而在會議遲遲沒開成的情況下,大家對於開發PLATE沒有明確的預期效果,怕任何的持續投資會做錯更多的事情。反之,大家對一些有趣的應用感到興趣,例如讓餐點在盤子上旋轉的特效,這也成為之後我們專題報告時的部分內容,確實滿有趣的。
終於,到了十月,系主任的信終於寄到團隊手上: “The team has my support.” 而我們接著與系上計算機中心談論伺服器與網址的問題,於是團隊又開始忙起來、回到正軌,當時的每個會議我都會演練五到十次,並很認真思考聽者想聽到的內容;雖然偶有不足,但回頭看,PLATE從最開始至今的會議並沒有失敗過。
由於PLATE也是資工系的專題之一,我們多了一個與人分享的機會:專題課。我們把影片與構想在台上報告,第一次報告結束之後,Sidney學姊前來聊天,她表示她在另外一門課的專題想做類似的系統,所以認為可以合作。雖然事後我們開過幾次會與她的團隊溝通,但最後並沒有實際的合作方式,反而寒假時,Sidney加入我們幫忙宣傳方面的事情。
而第一次在系館大廳跟Sidney溝通時,同班的Jackson恰好在一旁聽,事後Jackson表示對於我們做的東西很有興趣,也曾經構想過類似的作品,認為這確實是未來的方向,於是乎一陣子之後,Jackson加入PLATE,幫忙行銷公關的部分。一次次的機緣連成機會與可能。
當時Bass因為個人方向不同,所以漸漸離開團隊,往自己有興趣的另外一個方向走,我們開始很積極的在交大尋找可負責設計的人。先在人社一館貼了傳單,也到處詢問;最後,在人社一館的某面牆上看到一個頗不錯的App設計海報,便敲門問附近老師得知這海報的製作人Jessie,於是我們多了一位設計。我仍記得與Jessie見面時,Jackson嘗試說服她加入時候的情緒,很單純相信PLATE是一個能夠讓生活更好的平台,而且我們是那群能夠完成它的人。

Part 3 - 溝通與定位

接著,我們與學校第二餐廳的經理溝通,規劃PLATE系統營運的方式與細節,經理是這次專案中非常支持團隊的人,也表示他個人很想有這樣的系統給同學更方便的用餐環境,一直到更後期遇到困難的期間,經理也都是一樣的態度協助著團隊。反之,團隊也見了總經理,他的態度則是認為這樣的系統對於他的幫助不大,覺得在交大運行單純只是做善事幫助同學,意願並不高。
而與系上、系計算機中心、餐廳經理等的溝通過程中,團隊繼續開發第二期的App,我們把原先五個「查看推薦、查看列表、餐點與社交、查看點餐記錄、設定」功能修正後只剩下一個功能:「點餐」。團隊認為點餐是提供所有吃飯相關服務的基礎:透過點餐,我們能夠知道所有人對於餐點的喜好,未來得以推薦餐點;透過點餐,我們可以與Facebook結合,分享餐點引起話題,同時協助商家廣告自己;透過點餐,我們得以擁有使用者對餐點喜好最正確的資訊,夠過分析之後可以提供給商家,以做顧客市場分析。
同時,我們也曾在暑假把PLATE的構想與學校外圍的商家分享討論,發現大部份的商家對於這樣系統並沒有太大意願使用,首要原因是它預期帶來的負擔大過於獲利,其次則是上頭充滿太多的未知數,甚至一開始系統上並沒有使用者。於是,團隊認為應當從學校開始,透過系上老師的指導,並以學生的身份,對於失敗的容許度較高的方式進行第一次的營運,這也是PLATE最先投入在交大第二餐廳的原因。而既然我們在第二餐廳,透過點餐系統,首要要解決的即是「排隊問題」,我們認為學校內的餐廳每到用餐時間,全部的人都塞進餐廳 “Busy Waiting” 導致人山人海,甚至遲遲吃不到午餐,而我們的解決方式是每個人應該把自己的訂單在事前送出,而只有當餐點完成的時候,被 “interrupt” (即被通知之意)來現場領餐。
在Jackson的安排下我們跑進數個大班教室(如微積分課)內發問卷調查,發現校內約莫85%的人使用Android智慧手機,而非iOS,於是決議把團隊開發的所有成本只專注在Android App,把暑假的iOS程式完全擱置;同時商家介面從原先的網頁版本改成Android App,往後運行在思源基金會贊助我們的平板電腦上。我們稱暑假開發的iOS系統與網頁版商家介面為PLATE Demo版本,而開學後新開發的這個版本為正式版。然而,這個正式版,必須先經歷接下來的Alpha與Beta測試。
終於,我們在年底透過經理招集了第二餐廳的所有老闆,齊聚一堂聽我們報告並展示PLATE,猶記得會議的前一天,商家的Android App第二個頁面的介面仍是空的還沒動工,原先認為這次展示不應該拿出實際作品,因為滿可能中途拋錨。但,老師在前一天和我們說:「就拿出來給大家看啊!壞掉也不會怎樣!」恩,也是。於是展示的前一天,我找了Tim跟Anthony: “Hey, where are you guys? We got to rock this out.” 終於,半夜我們把隔天的東西準備齊了,也做了數次排練。那天的會議,在發下去的意願單中,我們收回了全部老闆的簽名,當天晚上我請了團隊成員一頓很開心的慶功晚餐。

Part 4 - 測試

接在商家會議之後,團隊開始進行寒假期間的Alpha測試和下學期開學時的Beta測試。
寒假期間,我們撰寫簡訊認證功能、商家營業時間機制、手機GCM通知、設定HTTPS、設計PLATE.tw官方網站等等,然後在最後團隊大家齊聚一起在多隻Android手機上反覆操作以發現問題,同時也邀請幾位朋友到場試用,聽取並記錄所有的建議與批評,這段期間是我們的Alpha測試期。
下學期開學的前兩週則是Beta測試,第一週邀請朋友加入測試,約莫30位同學,實際體驗透過PLATE系統在手機上點餐後到現場領餐的流程,那時候我們擔心會出現亂子,於是是一家家開放測試,同時團隊與商家建立合作方式,協助他們使用系統,共同商討人力安排與動線安排等事宜。
Beta測試這段時間是我個人在PLATE開發過程中最辛苦的一段時間,必須同時解決程式問題並上去修改程式碼、討論現場動線問題、與商家溝通並安排每日的測試內容,也同時與我們的第一批使用者溝通、蒐集他們的批評後修正。這段時間原先對團隊很有貢獻的Tim出國交換,而留下一份寫好的合約書,只要測試完成之後,隨時可以跟商家簽合約後開始正式營運;然而,這也成為那時的壓力來源,Beta測試的工作與所需能力已經在我能負荷的邊緣,而是否應該直接接著簽合約?
猶記得當時反覆被詢問:「如果出現任何問題與糾紛,誰負責?」理論上,團隊站在一個想改變現狀、解決問題的角色上,所以挑戰這樣的專案,對我們來說,成敗相對其次,而比較在意的是我們今天認為可行的PLATE,我們是否有使儘全力去嘗試。而誰負責?我想了很久之後,我想是我該負責的,而這樣的責任其實並不大,只是太害怕改變與嘗試的人放大了這個問題,想讓人畏懼之後繼續保持原樣而已。
兩週的Beta測試是頗成功的,我們在期間修復數個小問題,而並沒有大問題讓我們停駐,於是我們想把PLATE拉到另一個階段,然而在此時才發現忘記需與學校相關單位溝通,所以開始安排與總務處的會議。那是一場頗大型的會議,團隊約五人到場,加上老師與總務處逾十位的相關人員,我很真實的展示PLATE的構想與Beta測試的情況,總務長也很清楚地表示這場會議並不討論細節,而只是決議學校是否支持點餐系統的運行;在會議接近尾聲的時候,我聽了很多預期中的問題與討論,做了簡單回復之後,我說:「我知道PLATE要運行會遇到很多困難,也會被質疑很多問題,但我們也同時很清楚,這樣的系統今天我們不做,不久之後會有人做,而我不想看到這樣」大家沈默一陣子之後,總務長說:「好,那準備差不多要推出時跟我們說」。

Part 5 - 再溝通

總務長點頭之後,團隊本以為事情會變得順利,然而實際上卻變得棘手了。學校的執行單位事務組與我們開始會面與討論,團隊不斷被問:「如果太多人用爆掉怎麼辦?」、「現場有糾紛怎麼辦?」、「開放中午時段會不會很亂?」,感謝Jackson有耐心的一一回復這些問題,而我當時則覺得這樣的做事方法與團隊的本意衝突,我們是一個在嘗試改變,且願意接受失敗的一群人;相對的,學校人員則希望讓不確定性與風險降到最低,尤其害怕會有人客訴。
而這樣的溝通衝突,導致團隊人員都很疲倦於回答太多預設情況的問題,無奈於太過保守的做法,且溝通時間不斷拉長,本認為三月可以接在Beta測試過後把系統推出,卻至四月多遲遲沒有定論,過程中團隊也需要跟學生議會組織溝通,回復議會的提問。而,學校希望系統限制人數、限制商家數目、關閉尖峰時間等,都成為我們更之後運行時的潛藏缺陷。最終決議,我們需要關掉中午尖峰時間後開放系統。
這段時間有一個更棘手的問題即是二餐現場網路的問題,提供給商家的平板電腦並不適合直接使用交大的校內無線網路,原因是該網路並不夠穩定,於是從寒假開始,我們不斷在安排與討論,甚至請人評估現場佈線的方式。Alpha測試過程中,現場網路是使用3G網路,透過一個小台路由器分享給多台平板電腦,而3G網路則是團隊成員輪流去中華電信申請七天免費試用而來的。至於佈設實體線的費用實在太貴,餐廳無法在第一次測試階段支出這樣的費用,於是在校內加設無線路由器應當是最佳的方式。然而,我透過郵件與事務組嘗試溝通此事宜時,Jackson從事務組回來後說:「他說你信用詞錯了,不是我們計劃學校計算機中心架設,而說是我們要『拜託』他們幫忙」。
最後,網路問題學校方面表示有能力但並無意願與足夠理由幫忙,於是我們和餐廳協力處理:路由器費用由餐廳承包商支出,而網路月租費則是參與商家分擔。第一次聽到這個訊息時,我其實是相當難過的,這些商家是第一期願意和我們共同承擔風險改變現狀的人,而開發過程中我們也都堅持團隊自行負擔第一期的營運成本,包含開發、現場人力、維護等,而配合上思源基金會贊助的機器與學校的幫助應該可以讓商家無壓力的參與第一期的開發,而卻事與願違。
這段時間,我很高興團隊成員的耐心,有時候當我發現溝通時間已經超過預期時,Tim或Jackson都持續在安排下一步,Anthony與Jessie也在需要的時候替系統問題進行修正。PLATE團隊像是在燃燒的搖滾魂,遇上保守的學校單位,我們最終在火焰殘存之際,爭取到校內的公開營運的許可。

Part 6 - 營運

本來的有四至五家餐廳可以參與第一期的營運,然後後來因為網路架設因素,只剩下三家持續合作,分別是米克Q手調飲料、八方雲集與麵朝。而營運時間必須依照與學校的協議,把中午尖峰,也是效果最好的時段關閉。團隊開始致力於粉絲專頁的宣傳與現場動線的告示牌等事務,然後讓系統在2014年5月1日正式上路,開放讓全校同學下載使用,我自己則是常常閒空時待在餐廳角落觀察使用情況,順道聽路人對於系統的看法與八卦。有了Beta測試時的經驗,我覺得並沒有太需要擔心的部分,而聽取到的建議與批評不論好壞跟激烈與否,我都會記錄下來然後冷靜思考,很多部分其實窒礙難行,但我也去思考問題的根本。
商家網路在營運初期頗正常,然而來到第三週漸漸出現問題,因天氣變熱,小台的3G網路無線分享器頻頻過熱關機,團隊成員每日三不五時就需要到現場維護並解決各類問題,漸漸大家疲倦了,而網路的根本問題並不能得到解決。同時,系統設計上的預定功能仍欠缺設定領餐時間的機制、商家數目不夠多、需求量高的尖峰時間卻被關閉系統等原因,讓我們決定提早結束營運。無期限凍結PLATE專案。
PLATE點餐系統成軍15個月,在交大第二餐廳運行,累積有600位使用者下載,數百位同學點餐成功。PLATE的網站與可查看菜單的App仍會持續在市面上讓大家看見,以待未來有日可以繼續經營。

Part 7 - 謝謝,我學會了

PLATE結束了,但我卻是很高興而滿載而歸的。這些數千字的文字仍是無法傳達整段歷程的點點滴滴,一路上給予我們挑戰的人很多,幫助我們的人更多,從思源基金會執行長周吉人不求回報的贊助我們五台平板電腦,到老師不斷激勵並給予我們希望,再到團隊成員以熱忱工作一整年,支撐著整個專案運行。更值得我特別的感謝的是Scott學長,一路上也跟著我們一同商討並解決問題,幫助PLATE的Server Code的架構與後來的各種測試,以及Android App和伺服器通訊的網路行為等,還有在團隊決策上的建議;曾經好幾次我們堅定自己的想法而沒採用Scott的建議,卻在最後踩到地雷爆炸時才發現Scott講的是對的。
這次旅程我也接觸了很多人,團隊與作品或許不能一直順遂,但是人脈卻是可以永遠經營。到了近期,總是會持續遇到一樣抱有創業、創新想法的人,我都會盡力很開放的與他們聊天、交換意見,分享總是讓我更富有。
當然,PLATE最終沒有繼續,但對我來說,「如果要集滿十次失敗,才能換一次成功」那我已經收集了第一次了!這裡,我想條列出幾點所學:

一、別想自己負責全部

記得第一年春天,蹲在借用的社團裡面討論專案時,我覺得自己很能寫,可以在短時間內把想要的東西寫出來;也覺得自己會設計,想參與所有的設計;更覺得自己會規劃,所以希望計劃能照著想像中的樣子運行。然而,這也成為後期最大的問題。
直到專案漸漸走到公開釋出的階段,我發現我無法同時再掌控所有的事情,無法同時修改程式碼又安排行銷事宜,而且角色是尷尬的:站在決策者的角度,希望程式可以有更完整的功能並且沒有錯誤;站在工程師的角度,希望程式有最少的開發成本就能動。
於是,我認為在專案中,每個人應該非常清楚自己的角色與定位,也了解自己與團隊的合作關係。在往後的專案中,我會在開發者與規劃者之間擇一,然後把分內的工作認真且抱有熱情的完成。

二、少,然後精

“Be a thinker, I said to myself.” 想法來自極簡主義,一家公司、一個App應該都只有一個簡單卻確切的目標,而當我們覺得目標不只一個,同時還想要很多東西、很多功能的時候,表示我們想得不夠清楚,也不夠了解自己的定位。
PLATE一開始想要有推薦系統、人工智慧的餐點分析、點餐與社交等功能,但實際上我們發現真正想要的是點餐。而PLATE的關係架構中,除了團隊內部成員,還有老師、校方、系上、餐廳、餐廳承包商等,關係複雜於是難度高、溝通成本高,在沒有足夠能力簡化這樣的狀況時,我們漸漸失去專案的掌控權。
我認為在往後不論新專案或是任何的規劃,都必須思考到非常深,方知道問題的核心,然後夠過最簡單的方式專注於核心問題,並解決之。

三、再想多一點

當事情變得複雜時,我們往往難以全面分析,並找出所有事情的邏輯,於是容易一看到可行的做法就埋頭苦幹。然而等到抬頭發現這其實根本沒有在解決問題時,我們必須把做錯的事情都丟棄,從頭再來。
PLATE初期的程式不到半年就全部丟棄改版了,原因是我以為自己能把iOS App寫好,但忽略其實用iOS的人相對少數;當過多的會議時,我們常常會忘記自己的速求,更忘記我們必須隨時在會議中思考別人的立場並爭取最好的共識。
所以,一樣的, “Be a thinker, I said to myself.”。

四、拿掉個人情感

這是很殘酷的,但必須這麼做,否則會結局會更慘。當我們在做決策時,往往會帶入心理因素,像是:「已經做很久了,應該繼續撐一下就好」、「我相信這問題不是大問題」等;然而事實告訴我們,我們必須徹底的無視這些心理因素,然後把所有影響決策的因素理性的攤開,再做出決策。
PLATE開發過程中有很多預設的心理情感導致錯誤,例如:我們認為團隊已經做的非常辛苦了,所以必須在最短時間,縱使答應學校各種系統限制也要把半殘的點餐系統開放;最後,事實其實跟我們的直覺是幾乎一樣的,關閉尖峰時間、少量商家,所以想用的人很少。而心理因素讓我們甚至忽略本來的直覺。

五、成本,越低越好

如PLATE這類的創新應用,成本永遠是越低越好,過程中有很多的選擇讓我們想嘗試較高成本、較長期的做法,然而長期的做法其實並不適合。原因是創新專案開發(或者你想說創業也可以,但我並不喜歡這個名詞),我們一直在跟時間賽跑,如果這一期的期限到了、錢用光了、人累了(人力成本花光了)沒有達到預期的效果(獲利),而就無法跑到下一個階段,專案會被停止而失敗。相對的,我們必須把成本不斷壓低,讓作品可以在時間內進入下個階段,然後在下個階段才有另個階段的投資,提高作品的完整性與性能。
PLATE開發過程中,我們曾把Demo版本完全放棄,而開始撰寫新的Android App,也放棄當時Web App這個選項。而今回頭看,我認為Web App是比較好的選擇,雖然犧牲掉更好的使用者經驗,但對於最初期的開發,重點是在東西是否能夠快速修改,並且有足夠的力氣去應付後來的麻煩事。Scott當時給我們的建議是:「沒大問題就別改」,可惜當時沒有聽進去。

Part 8 - 後記

「PLATE要結束了,但是我們要深深一鞠躬再下台」我和Tim這麼說,那時大家都已經很疲倦在處理現場的問題,卻得不到對應的成效。我們做出了最後一次的規劃,把參與人員一一列出,擬定怎麼告知他們專案結束的消息,再寫信給每個參與和幫助我們的人。然後我和Tim分工把這段歷程寫成一份完整的數十頁報告,印出來之後,一一拜訪參與計劃的人,把我們的營運成果很誠實的告知並感謝他們讓我們PLATE可以走到今天。
我現在仍相信PLATE這樣的系統是被需要的,而且有非常的市場與發揮空間。點餐系統意味著希望使用者改變現有的吃飯習慣,先訂餐再到餐廳領餐,也改變商家習慣的營運流程,所以需要特別大的成本來驅使大家嘗試;而我認為我們之所以沒法現在成功的首要原因除了經驗不足,就是無法支持這麼大的成本。

最後那天,Tim請團隊吃了一個豐盛的晚餐,感謝所有人參與這段旅程;飯後,Tim和我待在我們平常開會的白板前:「來,下一個題目是什麼?」

Tuesday, June 17, 2014

惡作劇精神

在MIT、Harvard、Stanford等名校,惡作劇是很常被聽見的,但這並不是惹人麻煩的事情,反而是值得鼓勵、充滿創意與反抗平凡的行為。

人很容易依循習慣而為,在安逸中漸漸忘記初衷,然後漸漸對夢想不再要求,而找了一個說服自己卻說服不了其他人的理由開始隨便。而這群搗蛋的人在提醒著我們應該要讓生活充滿創意,在有限的資源與環境中不斷創造,再把一次次的驚奇寫進人生經驗中,讓生命每一秒都在躍進。

在MIT這樣的行為被稱為Hack,而與我們常聽見的電腦Hack是有一樣精神的,都在有限的資源與環境中,不斷挑戰並創新。較為有名的例子有:1982年,Havard與Yale美式足球比賽中,MIT學生在廣大的球場中地上冒出一顆大氣球寫著MIT;2012年,這群Hackers把MIT Green Buidling變成巨大俄羅斯方塊遊戲機,還可以實際操作玩樂。

Michael Snively在他的部落格中分享了這樣Hack應該遵循的道德標準,我將它翻譯如下:

  • 要輕巧的,不要留下證據
  • 把東西歸成原樣、或是更好
  • 不要造成不可修復的損壞
  • 不要偷任何東西,而如果必須借東西,一定要歸還
  • 暴力法是最後無能的手段
  • 不酗酒再惡作劇
  • 不遺漏任何東西
  • 不獨自行動
  • 以上沒論述者,以常識判斷
能觀察到我們身邊有很多環境缺少這樣的精神,大家太過於沉浸於平凡安穩的生活;而如此一來,我們失去很多生活本來有的樂趣,也不懂得跳脫現有框框思考,最終會淪為沒有創造力的機器。於是,我們都需要有惡作劇精神,不是調皮,而是創造。

參考資料

Wednesday, March 5, 2014

QR Code實務應用探討 - 其實並不方便

QR Code是二維條碼的一種,讓使用者透過手機鏡頭掃描QR Code圖案,即可解碼出對應資訊,其中「QR」為Quick Response的縮寫,表示操作過程中,使用者不用按任何按鍵,程式會自動判讀,於偵測成功時跳出對應的資訊。常見的資訊內容有網址、通訊人資料與身認認証等。本文,我想針對放置於「宣傳品」上面的QR Code做探討。

雖然這項科技看似便捷,但我認為QR Code其實是難用的。很大一部份的人對QR Code的印象是「麻煩的」、「不直接的」等,推斷可知這些想法來自於過往的使用經驗,若進一步探討,可以專注於「為何QR Code是不直接的」這問題上。


QR Code使用情境

當我在路上看到一張海報,在截角處有個QR Code提供我掃描,而我對海報其他部分的內容感興趣,於是想透過QR Code得知更多資訊,所以拿出手機後,我需要:
  1. 解除手機密碼鎖定
  2. 找尋手機安裝QR Code掃描App並開啟(若無,需安裝)
  3. 等候開啟App的載入時間
  4. 掃描並解碼(光線不佳情況下需要較長時間才可以成功)
  5. 點掃描結果

問題一:操作流程麻煩

從以上五點可以看出,「掃描並解碼」這個與QR Code技術本身有關的部分只有占一點,然而其他流程操作卻占了四點,而這也是我認為QR Code在實際運行上其實並不方便的主要原因。
如果要嘗試解決這個問題,以上幾點步驟做修正,例如讓QR Code像是相機App一樣寫在系統內建,可以在未解鎖情況下快速開啟。

問題二:手機需有網路連線

上述情景中,我們的手機不見得處於可以連線的情況,而在實務面,很多使用者行動上網的單月流量限制各不同,有人並無行動上網功能,也有人習慣沒事就關掉行動上網功能,而若是為了QR Code掃描又開啟網路連線,耗時。

問題三:QR Code對人沒有意義

QR Code是電腦根據資訊內容翻譯過來的,但圖形內容對人來說並沒有意義,一般人也沒有辦法直接透過QR Code圖形翻譯出對應內容,於是乎,這件事情讓QR Code整合進版面設計時,讓畫面變醜,且對人並無認知上的輔助意義。

以下是同一份資訊(網址HELLO.tw)直接呈現與使用QR Code呈現的示意圖。
  

實際情況

由於實際上使用QR Code進行掃描的成本比我們本來以為的還要高(不如預期的心理狀態),所以使用者對這件事情產生負面的使用經驗,開始認為這是一件麻煩的事情。於是趨動使用者去使用的動力弱,造成其實QR Code並不多人用的現象。
現實生活中嘗試解決問題的例子許多,主要都是夠過「提升掃描QR Code」的意願(見參考資料第2, 3點),目前尚未看到是實際解決「操作流程麻煩」這根本問題的人。

參考資料

Monday, February 24, 2014

創新軟體產業,不能再錯過了

台灣已經錯過很多黃金機會了,怎麼還是沒發現已經錯過多時?

發生了什麼事?

我打開我的手機,看看我用的聊天APP。
LINE是日本開發、韓國投資的;WhatsApp是美國的,且近期被Facebook以190億美金收購;WeChat則是大陸的,最近進軍台灣來勢洶洶;那台灣的APP呢?

再看看我們最常用的網頁吧!
Facebook無疑是Mark Zuckerberg在大學時期開始架設的網頁、Google是約十歲的公司;而大陸則有人人網、百度等使用者龐大的網站;那台灣除了剛凋零的無名小站,還有呢?

那麼再來看看許多正在進行且稍有成功的新式科技:
Evernote, Pocket, Flipboard, Foodpanda, Dropbox, ...其中哪一家又跟台灣有關呢?

為什麼會這樣?

我們真的很不重視這塊!好幾次我拿著類似的想法與別人討論時,很多人總是會說,一定要有硬體才會成功,而也只有會做硬體才有深的技術底子,也是之後在個人或公司經營上唯一的路。

而我不認同。台灣現今很多做硬體的代工商,漸漸越來越辛苦,也有很多開發中國家想要競爭,而我們在這個大餅上不再俱有絕對優勢;一定要有「硬體」才是經營之道的想法早已不合時宜,如果不能改變這想法,不但不能改變現在情勢,甚至我們早已失去下一場競爭的參賽資格。

它並不簡單

重視任何新式軟體的開發,沒有接觸硬體,不代表沒有深度。而這類偏應用的程式開發,雖然風險高,但是不代表沒有長遠性,只是完全在於怎麼經營能力而已。

一路上,我接觸過各種想挑戰新想法並實現的人,但是他們總是遇到力不從心的困境,整個環境告訴他應該學更多底層的東西、選擇現今代工商上班、接受別人安排的經營方式,而想實踐一個新的想法的作為被視為是膚淺不切實際的。而我一樣不以為然。

做一個LINE、寫一個Facebook是簡單的嗎?這類的軟體開發,雖然用較高階的語言寫,但不代表程式能力要求低,在整體資料庫的設計、大型程式架構、伺服器系統資源管理等都完全不比跟「硬體」有關的來得容易,同時更關係到人、經濟、產業、文化、市場、行銷、設計、品牌等太多事情,是一件非常有挑戰性的路,絕非大部份人認為的「容易」。

小結

我覺得想經營新式科技或想法的人應該有更多人的幫助與指引,而大環境存有的偏見是有害的,台灣在代工地位上已經不如以往,下個世代的科技也已經錯過半截了,不能再繼續阻止自己成長了。

Thursday, January 30, 2014

不應該完美 - MVP (Minimum Viable Product)

「我們是不是應該把它弄到完美再推出?」

新創團隊對於產品規劃上,往往會有人提出這樣的建言,而下一句話也通常會講述哪個功能是必要、哪個事情一定要處理等理由,再提出時程延期的建議。而我一年之前也對於這類的問題感到不解,是否應讓東西更完美所以延期嗎?

回答這個問題,我思考每人都引以為鏡的公司Apple和Facebook在這問題上的解決方法。而這兩家公司恰巧用相反的方式:Apple喜歡有年度發表會,邀請記者集聚一堂,揭露沒有人能猜測的新產品,而產品的樣子在那一刻定案,是否被市場接受也在數週內可以看見成績;Facebook曾喜愛嘗試新功能(針對IPO之前的經營方式做探討),也在不斷試水溫中修正,例如Facebook Home,執行長Mark在公開演講中認為是嘗試階段,往後大家會接受,而針對網頁有時會當掉的情形,他則以「東西都會壞呀!壞了修他就好!」的態度回復。

對於Apple和Facebook的例子,可以解釋成實體產品公司與純軟體公司的經營差別,也可以解釋成形態上的不同。Apple從個人電腦最初一直營運至今,規模甚大,可以支出的成本大,於是能夠承擔若單一產品失敗的風險;Facebook則是2004年成立的Startup,且以一個大家不認識的商品進軍市場,接受度十分不確定,公司處於較不穩定且目標不明確的情況下,不易承受失敗的風險,所以試水溫成為重要的方式。

分析完Apple與Facebook的例子,我認為新創團隊應當採用Facebook類的做法,因為在沒有錢與產品接受度不確定情況下,團隊不能夠接受累積很久的成果於一次發表的時候宣告失敗的可能;相對的,透過先釋出部分重要功能的產品,再慢慢修正、增加功能的方式顯得正確,數個小失敗是可以被允許的,同時間團隊更了解市場的喜好而做修正,或是放棄一些其實市場根本沒興趣的功能。

MVP (Minimum Viable Product)與Lean Startup都是這類做法的名詞,其中MVP表示創新團隊最一開始應該推出含有核心功能的產品即可,其他部分則應該以最快的速度與最高彈性的方式完成,搶先進入市場,且更快了解到市場喜好後再修正產品。

根據以上說明,我認為創新團隊不該花時間讓東西「完美」,而是應該注重在消耗完「團隊成本」之前推出產品,盡訴確認產品是否被接受、找尋商業模型。

「不,應該是檢視我們的產品是否達到MVP的功能!」

Monday, January 20, 2014

[Plate團隊參與筆記] 沒有無用的人,只有無能的領導

Plate團隊發展至今,有新成員加入,也有成員離開,每位參與人對團隊的期許與想法都不同,但大家都清楚知道團隊與自己的關係。對我們來說, 最重要的不是找齊全世界最強的人,而是讓所有參與人獲得最合適的位置,愛上自己的工作,然後組織出最堅強的團隊。過程中,每個人都是獲利的、開心的、熱血的。

團隊運行過程中,我們會針對缺乏的部分對外找人幫忙,同時也檢視內部成員是否都有不錯的參與情況,而對我來說:「如果一個人,沒能幫助大家,提升整體效力,不是因為這人能力不佳,而是他做錯了工作!」我們要做的不是責備也不是抱怨,是需要重新檢討工作分配,讓每個人做自己喜歡的事情,然後自己的貢獻幫助了整個團隊或產品,獲得參與感與成就感。

試想自己有一份工作要完成,它是一件雖能力可及,但卻厭煩而無心再認真做的工作;相對於一份新鮮的工作,上頭有很多新奇的事情讓我想嘗試。雖然不論是前者或是後者,透過一開始的合作共識,應該都能在時限內完成交差,然而可以明顯知道後者可以帶出較好的成效,做出來的東西較有生命力。這並非一面倒的法則,卻解釋不能單從一個人的履歷、就讀的系所或經歷給予工作,應該實際溝通,聽他想做的事情,然後找出對應的工作分配。

實例中,看過一些成績好的資工系學生其實更適合負責非寫程式的工作,而同樣是程式開發者,也有人對於產品外貌感興趣,有人則只對技術有興趣;若是我們逼著只對技術有興趣的人緊跟所有產品開發,必然成為當事人與團隊的負擔。這則是一個分工失敗的例子。

從心理學的書當中,我們可以清楚知道一個人談論到自己喜歡的東西時候,眼睛會睜大、瞳孔放大,同時也會有許多特定肢體語言出現,從這本能現象中就可以判對一個人是否喜歡自己眼前的工作,再配合上個人的性格之後,組成這人在執行工作時做法與態度,而合作後若是沒有好的結果,則便是最初的分工問題。是故,我相信沒有無用的人,只有無能的領導。

Monday, January 13, 2014

目標是做決策的根本

決策,也就是「做決定」,是我們每天頻繁遇到的問題,而生活就是一連串的決策,最終走到一個目的地。小的決策可能是「先吃午餐還是先念完書」、「要不要帶雨傘」等,而大的決策則可能是「研究應該做什麼方向」、「畢業後要唸書還是找工作」等,其中大的決策可能花很長一段時間在思考,同時也會詢問很多人的建議。

最近好幾位朋友跟我聊天,都陸續提出類似的大決策問題,「我畢業後要幹嘛?」、「我應該要修什麼課,方向是什麼?」、「我該出國嗎?」等,我自己也在思考很多個類似的問題,不同問題之間甚至有很多的交互關係,最困難的點在於每個問題我們都不曾遇過,所以無法根據經驗回答,於是猶豫。

恰巧,不久前在朋友推薦下看了一本頗有意思的書:「目標」,雖說書中主要探討管理學,但應用不只在管理,甚至人生規劃等都是有幫助的,而書本中一開始的部分,探討「問題本質」的方法是我目前看到最正確解決決策的方法。

「目標」是做決策的根本。

當我們面臨很多決定而猶豫時,應該思考的是對於這件事情之於自己的目標是什麼,然後在這目標底下,我應該怎麼做眼前的決策,或是更長遠的安排,所有的問題都有了方向而簡單。

仍然以最近許多朋友和我自己都在面臨的決策為例:「畢業後之後要做什麼?」,如此問題的根本變成是「我人生規劃中的最終目標是什麼?」。每個人都有所不同,在朋友間,有人想要專研某項技術,有人想要過安穩生活,而有人想跳舞、想寫小說,社會也因每個人都有自己堅持的目標而美麗。於是乎,確定自己目標之後,畢業後要做什麼顯得容易回答:「找一個最可能到達那目標的路」。

也是在朋友之間,我看到用這方式而做很棒的人生規劃的例子:喜歡技術,所以嘗試許多開發團隊,並不斷經營自己的作品,累積的成果變成履歷;喜歡表演,所以高中多念一年準備出國,接觸並參與世界上他喜歡的那些表演人;喜歡旅行與異國風情,所以嘗試交換學生。

無形中,當我們堅持自己的目標時,做決策時的選擇變多了,更多人認為這個人就是喜歡做某項事情,所以這件事情給他做,不但他有過去經驗,也因為興趣所以可以做好。如此一來,更多的路會開啟讓我們走到本來的目標。

用於團隊管理更是如此,在短期、中期、長期需要一個十分明確的目標,讓團隊規劃上依循目標而走,也讓所有參與人都明確知道當下應該努力的事情是什麼,不會有發散的想法或做不必要的事情。

然而,也有許多與這方法較相違的例子,多來自不容易改變的「習慣」,例如唸書。從小學一路到大學,成績一直是逃不掉的話題,也很多人認為「要努力」就完全等於「要努力唸書」。但,這或許應跟自己在追尋目標中,唸書是不是其中必要條件之一有關,若是一個愛音樂的人,卻讓自己受限於念書,那是否與目標根本背道而馳?在機會成本的概念下,甚至是不斷在浪費掉自己追求目標的成本?

最後,如果自己已經清楚知道目標是什麼後,面對決策的判斷依據變為「哪個較可能帶我實現目標」,可以依據過往經驗判斷,更可以問其他已有經驗的人。再來,如果仍不能做決定時,表示選項彼此間是差不多的,其實選一個直覺對的就好,然後開始規劃下一步。

參考資料:

Saturday, October 5, 2013

「賈伯斯」電影觀後心得

  • People don't know what they want until you show it to them.
  • The people who are crazy enough to think they can change the world, are the ones who do.
  • You are your own worst enemy.
以上是三句在電影裡出現的對話,也是在傳記中被大家流傳的語錄。

觀賞完這電影後以及閱讀傳記之後,我瞭解到賈伯斯是一個能夠看見怎樣是正確的商品,且態度極度堅決再追求完美,因而在設計電腦任何一部分時候,知道人想要的是什麼。

然而,現實面總是與理想相違,追求完美成本太高,沒辦法在如此的情況下經營公司,賈伯斯對這樣的堅持沒有退讓,使自己變成孤獨的,我覺得即使他的產品被所有人喜歡,在他的世界裡,應該都是沒有人能夠去瞭解而孤單。

他也讓我瞭解到一件事情,"Insanity Simple"不只是針對產品的設計,對於自己生活規劃也是如此,能只堅持一件事情做底其實是件非常困難的事情。

Monday, August 12, 2013

或許,我們根本不該去上課

或許,我們根本不該去上課。上課,不是一種堅持,它不代表用功、不代表是正確的學習方式;相反的,翹課不該被唾棄,在多數的情況下,這是對自己負責而不得已的選擇。

在我所修的課裡面,絕大多數開學前兩週有約九成的人來上課,而過了學期中旬剩下約半數,再扣除「玩手機」、「玩電腦」、「睡覺」和「放空」的人大約只剩三成(當然教學熱忱的老師所授的課情況較好,但也有更糟的)。

「學生不夠認真」是一般人對此狀況的直接反應,一直以來學生也默默扛下這個責任;然而我們再以學生的角度去思考:從國中到高中,再到大學,一天必須聽講數個小時的課,一個學期就是半年,到了期中考之後早已到達一般人的體能限制,無法再有足夠的專注力,造成學習狀況極低,而實際情況中,教授老師依然繼續著課程,根據著原定的教學進度。

「別再把所有責任推給學生了」,學生沒有一個會希望自己學習狀況差,也一定期待在課堂中學習到知識,而面對這樣的需求,學校給予的是一個容易取得知識的平台,還是它艱苦費時?唯有極少數老師對教學抱有熱忱,其餘則是以一份工作看待教學,他們會把教學進度上的內容呈述給學生,而在交大資工系,許多老師使用原文課本出版社的投影片,上面是課文的簡要或是一字不漏、密密麻麻的原文課本內容,然後上課時照著投影片一頁一頁念過去,從學期初到學期末皆是如此。我詢問過很多同學與自己的經驗,發現這樣的方式盡乎沒有效果,上完課之後有不少同學甚至整堂課的內容完全不了解。

如此的狀況每學期都出現在多數的同學身上,而到期末才拾起課本把一整學期上課內容以自學方式去瞭解,更多人是期末考前兩天才開始讀,但既然學生有如此的學習能力,為何卻花一整學期浪費時間、堅持留在課堂而根本學不到東西。當此現象已發生在絕大多數學生的身上時,是不是不該再一昧地把責任砸在學生身上?

為什麼寫這篇文章? 希望讓更多人瞭解到,或許,我們根本不該去上課。上課不是一種堅持,上越多的課不能見得帶來期待的效果,而該經過自我學習狀況分析之後,勇敢選擇對自己時間更好的投資、放棄既有的堅持;盲目撐過的每一堂課,累積起來造成的負效益萬分可觀,絕對是我們社會應該關注的。

相關閱讀