《當科技變身時尚》讀後心得分類：心得

《當科技變身時尚》16%的科技行銷密碼

簡介

義大利米蘭，時尚名模正身穿新款春裝，手拿液晶螢幕搖曳生姿走上伸展台。不知何時開始，冰冷的科技產品竟變成時尚配件，驚豔四座……

科技產品演進至今，已不再是功能論輸贏，取而代之的是造形、設計，是給消費者時髦的感覺。然而，許多科技大廠卻無法走過這個階段而退出舞台。

國內最具權威的科技趨勢專家黃彥達以多年的研究觀察，強調科技產品必須突破16%的關鍵門檻，才有機會屹立市場。書中告訴讀者為什麼PDA在風行了一陣子後，始終欲振乏力？手機與PDA的結合是否能造成另一股風潮？網路可以走進客廳，結合一般家電用品嗎？如果可以，產品該如何設計，銷售上又要如何吸引消費者？

讀後心得

讀完了這本書才知道創新型產品的行銷多麼的辛苦，難怪在早期的電子業總有一種心態，就是老二主義，由老大去推廣市場、教育市場，然後老二就可以省了大筆的行銷費用，這種營運模式在現在這個微利的年代，應該已經無法生存下去了。

所謂的行銷4P－－Product（產品）、Price（價格）、Promotion（推廣）、Place（通路），我想是所有的行銷人每天要注意的項目，而本書討論創新型產品的行銷，引用Rogers的《創新傳播》理論，把所有消費者分類成五類：創新者、早期採用者、早跟進者、晚跟進者、落後者。而這五類的消費者利用統計學上常用的常態分配曲線來看，創新者加上早期採用者大約是16%，只要所有的產品普及到超過16%之後，行銷的方法就會產生極大的變化。

本書談到了這幾年的熱門產品與看不到的服務：ＷＡＰ、ＰＤＡ（股票機、電子字典）、ＰＣ、ＡＤＳＬ、３Ｃ、ＮＢ、ＴＡＢＬＥＴＰＣ、手機、ＭＰ３、ＭＯＤ、ＩＣＱ......等等，這些產品看似簡單的背後，他們的行銷及推廣的方式竟然有那麼大的差別。

我們往往從國外翻譯的書籍來了解行銷這類產品的原理及方法，但是台灣的市場不同，而所有國家對科技產品的接受度也有很大的差異，例如日本人對科技產品的接受度就很高，法國就很重視產品的設計與單一用途，所以本土化的行銷書籍也應該大力推廣才是。

《與熊共舞》讀後心得分類：心得

＊本書行銷術語：

假如下一個專案一點風險都沒有，就別做。

風險越大，報酬就越大，對於軟體開發來說尤其如此。在充滿競爭的環境中，一味逃避風險的公司很快就會發現自己落後了，但如果專案經理對於可能造成失敗的威脅視而不見的話，又會使組織「過於冒進」。為了解決軟體開發人員「逃避又怕落後，冒險又怕失敗」的兩難，本書將教讀者如何辨識風險，並去擁抱「值得冒的風險」。作者還列舉出風險管理的好處，包括：

使積極的冒險變為可行
防止盲目管理的發生
花最小的成本做好最起碼的防護措施
釐清責任歸屬
隔離子專案的失敗，使它不會衝擊到整個專案。

讀者可以用本書提供的策略來加強專案的防禦工事，對付軟體專案中最普遍的風險：

時程延宕
需求膨脹
人員流失
規格崩潰
績效低落

《與熊共舞》將幫助您，在風險演變成致命的問題之前，就紓緩風險。風險就在那兒——它們本來就應該在那兒——而你當然有辦法管理它們。

＊讀後心得：

本書的架構簡單明確，從風險管理的Why?→Why not?→How?→量化→驗證。共分五個單元，我想這是寫程式搞電腦的工程師，最常用的方法。定義問題的那幾個章節有點長，不過習慣用小故事切入並形容問題的作者來講，讓閱讀者很容易了解。

沒有寫過程式的人幾乎很難想像這個行業是高風險的行業，為什麼當初講好的時程無法按時交貨？為什麼只是修改一點需求他們就做不出來？為什麼抓不到問題？為什麼系統問題叢生？為什麼他們總有那麼多藉口？

上面這麼多＂為什麼＂其實就是對軟體系統開發＂不確定＂的表象，不確定就是風險，要如何量化這些不確定，就是本書要給大家的解決方案，雖然說這些統計的理論有點方法，不過作者利用程式設計最常用的模組切割方法，就是定義清楚＂輸入＂與＂輸出＂然後把結果給導出來。

最常用的回饋分析法被泛用在這本書的風險量化的方法，利用過去的經驗值建立資料庫，然後在下一個專案開始的時候當成風險的參數，經驗法則是每一個企業存在時間的價值，要建立資料庫是這幾年知識管理的重要方法之一。

對於瀑布式與逐步交付的開發方式，本書的第十六章有很詳細的說明，這個在各種專案開發的書都有很清楚的描述，如果您是使用電腦工具的高手，例如使用MS Project，可以很方便的用這些工具切割出模組來，也很容易找出人力資源的衝突，但希望使用這些工具的管理者還是要了解這方面的基本原理。

最後，我對附錄Ａ的小故事印象深刻，在職場上工作，尤其是大公司工作，各部門各司其職往往不想去了解別人的難處，而系統研發部門往往就揹負這種風險的壓力，要如何改善？是需要各部門的人都了解的。

延伸閱讀：【流程】軟體開發流程的壓縮與再造

程式設計師的工作慣性

這次要討論的主體可能跟創新的關係很小，請容許我離題。一般來講年後換工作的風潮在各個行業都會發生，我們來分析一下程式設計師工作的型態，這些分析可能在各行業都可以適用。

首先，我面對到程式設計師換工作的主要原因大部分是認為原來的工作創新度不足，使用的開發工具比較舊，原系統已經不做大幅度開發，只作例行性的維護，缺乏新鮮感，種種的跡象顯示很難獲得成就感，或者是無法獲得大家的一致的認同有價值。

但是，這時候程式設計師的確是一樣的忙碌，每有忙著救火，卻得不到掌聲，如果你正式處於這種狀況，你第一個想到解決的辦法就是換工作吧！然後原公司可能會在找一個人頂替你的位置，而你接觸新的工作，同樣的狀況兩年後又發生一次，這是一個無法解決的惡性循環。

問體出現在哪裡呢？我想並不是技術能力的不足，而是錯估了處理問體所花的成本，接專案的人總認為有一個洞，把他補起來就好了，哪知道有很多洞要補，而且補了洞還不一定知道是不是會產生另一個洞，所以需要從系統架構上的問題去了解，然後再來解決。

第二，可能是在系統整合上的問題，現在的系統大部分是採用開放式的架構，大家協同把所有的子系統放上去，第一次整合測試沒問題，第二次也沒問題，測試過後就上線了，但是系統運作的時間久了之後，有的子系統因為檔案讀取失敗，資料庫沒有正常運作，或者是當初沒有考量道的錯誤，造成平常操作人員的困擾，因為程式設計人員也換過了好幾代，文件不齊全，原始程式碼沒有說明，導致無法找出問題點。

這一類的程式設計師總覺得自己在接爛攤子，接愈多包袱愈大，最後只好選擇丟掉，其實，要解決整合的問題，別無他法，就是程式設計師或者操作人員下去做分析，詳細的一步一步的把錯誤訊息找出原因，然後把問題發生的狀況紀錄分析，然後看是要改程式來解決，或者是從作業流程去改變，這個以目前用 Excel 來做應該都綽綽有餘了，這個過程可能隨時都在做，但必須密集的去分析解決。

最後，可能跟資源的整合或是分開有關，公司會資源整合一定是有某些產品的收入不合經濟效應，所以一個人本來負責一個產品或專案，但是可能一個人變成負責兩樣產品，如果程式設計師還認為事情是Double 的話就錯了，可能剛開始的時候是這樣，既然負責了兩件事情，就要把程式碼變成一份，這樣慢慢地就變成一件事情了，不然比較差的方法就是安排事情的重要程度來處理。

另外最重要的想要換工作除了是被挖角跳槽之外，其實也有景氣循環這一回事，景氣不好的時候，開發新功能新產品的事情是比較少，維護程式系統的事情比較多，認清楚你的專長是在開發新系統還是在維護系統，在搭配業界的景氣循環，才不會永遠在景氣循環或是過年的時候換工作。