- 不基於語法選擇程式語言，而是看需求，選最適合的
- 比原來更深入，去追，去了解你在使用的程式，已經被做完的那些 code 是寫些什麼
- 你有使用過原始碼控制系統嗎
- 是，git
- 你能用一個步驟建出所有結果嗎
- 是，用 shell 初始化 (git pull and npm run dev) 網站程式
- 是，用 composer script 組出整個網站的配置資料
- 將固定（或重複的動作）可自動化過程自動化
- 你有進行每日編譯嗎
- 否，但我每次更新都跑 CI 自動化測試
- 弄壞測試、導致測試不通過就是不行
- 你有沒有問題資料庫
- 沒有
- 重現問題的完整步驟
- 應該看到的行為（可附圖，截圖手繪怎樣都可以）
- 實際看到的（有問題）行為
- 發現問題的人
- 被指派的負責人
- 是否已修正
- 無痛錯誤追蹤
- 沒有
- 你會先把問題都修好之後，才寫新的程式嗎
- 否，原因
- 維持「進度」，程式設計人員蓋技術債
- 承上，進度落後常常是因為正式時程未包含除錯階段
- 沒有人試圖在減少問題數量
- 零錯誤做法：無論何時都要先修正錯誤才能寫新的程式
- 越晚修正成本越高，回憶過去，痛苦的就是忘了了
- 若時程包含很多待修正問題，那這種時程是不可靠的
- 若錯誤數量為零，面對競爭時（加需求）反應可以更快
- 否，原因
- 你有一份最新的時程表嗎
- 否
- 擁有時程可以強迫自己決定要製作哪些功能，並剔除現階段最不重要的功能，避免功能過度膨脹 featuritis, as scope creep
- 你有寫規格嗎
- 改規格比改程式成本低，等到程式寫完才改待價高出許多（情感與時間）
- 沒有規格就不寫程式
- 程式設計人員有沒有安靜的工作環境
- 否，沉浸狀態, as in the zone
- 你有沒有用市面上最好的工具
- 工具越好用，程式設計師越能專注在程式開發
- 你有沒有測試人員
- 有，但不夠
- 是否在面試時要求面試對象寫程式
- 否，隨性出題請面試者展示他的寫程式習慣
- 是否進行過走廊使用性測試
- UI 部分，在走廊隨便攔下 5 個人試用你寫好的 UI 可找出 95 % 以上的問題
- 字元集，沒有所謂的「純文字」，所有軟體文字都有一個對應編碼
- 規格的重要，就算只有寫給自己看，也要強迫自己寫規格，有規格才能避免寫出低劣品質的程式，因為規格要你詳細描述程式運作，所以能迫使你「實際設計程式」
- 規格來來去去定案後才開始寫程式，比先開始寫程式，之後才發現彼此認知有落差，東改西改要輕鬆很多
- 寫規格理由一
- 當你「以人用的語言設計產品」時，只需要花幾分鐘就能考慮多種可能性，並且修訂，以及改進自己的設計
- 相對的你「以程式語言設計產品」時，反覆設計就要花上好幾週的時間
- 寫規格理由二
- 節省溝通時間
- 品保人員讀規格就知道程式動作，也知道如何測試
- 行銷人員讀規格就能知道如何寫曖昧的資料，放到網站上宣傳尚未出現的產品
- 業務人員沒有讀規格，但是可以吹噓產品很猛，因為他們就是要吸引客戶
- 開發人員讀規格就知道要寫什麼程式
- 客戶讀規格則是要確定，開發人員正在製作他們「想買」的產品
- 技術文件作者讀規格才能寫出好的說明手冊
- 這些溝通在沒有規格時還是會發生，但會花上好幾倍時間（A 打擾 B 問問題）
- 節省溝通時間
- 寫規則理由三
- 沒有詳細規格，就無法定出可靠的時程
- 寫作就像練肌肉
- 功能規格 v.s. 技術規格
- 功能規格
- 以使用者角度來描述產品如何運作，不管東西如何做（怎麼寫程式實現）出來．
- 述及功能，詳述畫面、詳述功能表、詳述對話框
- 技術規格
- 描述程式內部的實作
- 資料結構、關聯式、資料庫模型、程式語言、工具選用、演算法
- 功能規格
- 功能規格範例
- 概要
- 闡明這份規格是未定案版本，在定案前都還需要修改多次
- 展示畫面圖案及配置只是為了說明其中功能，實際外觀需要參考設計師意見，並視使用者反映逐步開發
- 情境1, 2, 3…
- 想像一些真實人物如何使用產品
- 非目標
- 這個版本不會支援下列功能
- 剔除進階（沒那麼重要）細節
- 剔除沒時間做的細節，留到下一版
- 這個版本不會支援下列功能
- 流程圖
- 闡明這份流程圖並不完整，只是你可以透過這份流程，對使用此服務或功能，有大概的「概念」「腳本」
- 各個畫面的規格
- 功能性以及互動設計，非外觀與畫面配置
- 未定項目
- 此服務還需要與其他人討論的細節部分
- 技術詮釋
- 建議開發人員這邊的程式可以怎麼用之類的
- 概要
- 功能規格必要項目
- 一段聲明（自衛）
- 例如：先聲明這份規格還沒完成
- 例如：就我所知這份規格已經夠完整了，若有遺漏請告訴我
- 一位作者
- 情境
- 非目標
- 若要把各種「心愛」的功能都做出來恐怕永遠做不完
- 概要
- 此規格準備要描述的東西的大致輪廓
- 細節、細節、細節
- 為所有的可能畫面取個正式名稱
- 再對每個畫面鉅細彌遺的描述
- 未定項目
- 需要討論的東西，討論後定案
- 程式人員開始作業時，所有未定項目都要清理乾淨
- 旁註
- 技術註解
- 測試註解
- 行銷註解
- 技術文件編寫等等
- 規格必須是活的
- 需要時常更新規格，只有在程式真正完成時（功能完備）才會凍結規格
- 雲端同步同一份規格，加上修訂標記不必重讀整份文件
- 一段聲明（自衛）
- 產品經理
- 搜集需求，定義程式應有作用並且撰寫規格
- 配額五位程式設計人員
- 產品經理以規格定義產品，程式人員負責以程式實作寫出產品
- 產品經理要協調行銷，文件撰寫，測試，地區化，以及其他程式人員不會處理的繁瑣細節
- 不要把程式設計人員升為產品經理，產品經理需要能
- 撰寫清楚的文章
- 外交手腕
- 對市場的敏銳度
- 對使用者的認同
- 良好的 UI 設計
- 別讓行銷人員擔任產品經理
- 別讓程式人員對產品經理報告
- 交代細節，建立共識，放手交給團隊執行，不需要處處（程式設計人員對產品經理）報告與干涉（產品經理對程式設計人員）
- 要有趣
- 規格很好，但沒人閱讀，需要寫出吸引人願意閱讀的規格
- 寫規格就像可以用腦執行
- 寫出可理解的「白話」，與技術細節部分的「旁註」
- 寫得越簡單越好，三的法則
- 把想要表達的東西控制在「三句話」「三步驟」「三行」等等，如果沒辦法，細分為「三塊」
- 自己重讀幾遍
- 不要使用制式樣板
- 例如每份規格一定要有實作某個元件，就算那份規格描述的功能跟那個元件沒有相干
- 為何沒有人要訂時程？
- 執行起來很痛苦
- 沒人認為值得做，因為訂了也沒準過
- 如何訂出無誤的時程
- 不要使用專門的 MS Project
- 需要花大量時間處理/追蹤工作關聯性
- 關聯性指的是第一件工作必須在第二件工作開始前完成
- 對軟體開發而言不需要特意花時間建立追蹤管理，只要有任務清單即可，例如 Excel
- 且 Project 有自動均衡時程的功能，但對軟體來說，你不會突然把工作指派給本來不是在處理這件事（或不擅長）的人
- 任務清單則簡單就好
- Feature，例如刻出一個素還真
- Task，例如建立頭部模型、繪製服裝、找軀幹材料等等細部任務
- Priority，優先度，例如雛形草稿可能為 1，找軀幹材料為 2、頭部模型 & 繪製服裝為 3
- Original Est，原始預估時間
- Current Est，目前已花費時間，與前者一起做參考讓下次的預估更準確
- Elapsed，耗時，當任務完成時，此欄位會跟 Current Est 值一樣
- Remain，剩餘時間，與前者一起參考提醒你該刪減功能，或延期，當任務完成時，此欄歸零
- Developer，若是共享任務表，可記錄開發者是誰
- 排時程最重要就是先列出任務清單（看著規格分配任務）
- 只有程式設計人員才能估計出自己的任務時間
- 要把任務分得很細，分配好的任務可以以小時為單位，如果超過 24 小時（超過一天），表示任務可能還分得不夠細
- 把任務分細還能消除軟體專案中大量不穩定的成分，因為會迫使你弄清楚哪些功能是真正要寫的
- 每天更新任務一次即可，不用一直盯著每個欄位時時去更新時間消費異動
- 加上休假日，推估出產品完成日
- 把除錯時間排入時程（多估一點），程式設計人員通常會邊開發邊除錯
- 不要在該除錯的時候寫新程式，隨時讓錯誤數目盡量減少，因為在寫出程式的同一天除錯會比較容易，因為一個月後再來除錯，你就會懷疑那個到底是不是你寫的
- 除錯需時本來就不好估計，所以若保持隨時只有一兩個主要問題，那未來無法估計的項目就不多，可容易推估產品完成時間
- 你可能會問開發時就把除錯都做好，為什麼還要另外安排除錯時間，因為丟給測試測完還會迸出程式設計人員沒想到的問題
- 把整合時間排入時程，合併別人的程式進來也有可能會噴掉，也要除錯時間
- 加上緩衝
- 預防工作耗時超過預期
- 針對未預期但必要的工作做預留
- 絕對不要叫程式設計人員縮減估計時間
- 不要認為能用「精細」的時程請程式設計人員做得更快，因為寫程式的是人
- 若需要讓上層訂一個時程，可在任務清單加上 Rick 欄位，讓他們押上覺得需要的時間，完成再來看實際執行後的差距
- 寫程式需要先想清楚所需步驟，這樣估算出來的所需時間，大概是沒想清楚的所需時間的三倍
- 或許可以加人力，但他們需要時間適應，在前幾個月只有一半的效率，在軟體業界要找到一個好的程式設計人員平均至少都要花六個月
- 你或許能讓員工在一年內全力以赴，暫時提高10%產能，但太短視近利
- 你或許能懇求員工不計辛勞努力加班，暫時提高20%產能，但有接下來有9成時間會拿去除錯
- 時程像積木
- 我們把產品切為（預估剛好的時程）積木裝進的剛好的箱子（完成產品），積木太多（根據產品需求，開出來的估計時程很長）塞不進箱子裡（無法完成產品），要麻找大一點的箱子（延後完成產品），要麻拿掉一些積木（刪除任務，降低所需時程）
- 根據上述說明我簡化為下述
- 箱子 = 根據規格定義好的產品 v1
- 積木 = 產品 v1 細分的每個任務所需時程，時程是無法壓縮的，跟積木一樣不能改變形狀
- 理想上，箱子 can be filled by 所有積木 = 完成產品 v1
- 實際上，箱子 can not be included 所有積木（積木越來越多 = 任務越來越多）
- 箱子加大：重新定義產品 v1 需求，延後產品 v1 完成時程
- 把積木留著等第二個箱子（產品 v2）：刪除功能，讓產品 v1 準時完成
- 排出時程可逼自己先完成「有用」或「重要」的功能，避免把時間壓在完成「容易」或「程式設計人員覺得有趣」的功能
- 不要使用專門的 MS Project
- 每日編譯：現在是每日（小時）自動測試、自動部署到測試機，測試人員可以快速知道，該修正的問題是不是已經被部署到測試機並修正
- 確定知道問題的狀況，檢查 daily log
- 確定你會得到經濟上的回饋，不要把系統問題的經濟負擔轉移到使用者身上
- 準備技術支援電話給使用者打來，且不應給使用者付費，須由系統提供者付費
- 找出哪些問題值得全部修好
- 只有當修正問題得到的價值，超過修正問題所花的成本時，修正問題才是重要的事，例如為 IE 6 用戶刻一個他能正常打開的前台 UI
- 軟體開發不同領域有不同適用的規則，五個世界：
- 熱縮封膜軟體，即給一般人用的軟體，例如商業軟體 office，共享軟體 linux
- 因為是給很多人使用的，對各種電腦系統的支援性須格外有彈性
- 重視包裝與易用
- 他們通常都有替代商品（是一種對開發者的困擾）
- 開放源碼軟體，有點重疊在上一點的範圍，這類軟體開發動作通常分散在各地運行
- Web 軟體，內容網站，易用、跨瀏覽器，第一點的變形
- 顧問式軟體，CRM、CMS 等
- 內部用軟體，給某家公司電腦、特定狀況下可以用就好的軟體
- 嵌入式軟體，不常被更新，品質要求高
- 遊戲軟體，不會有與舊版無法相容的更新
- 用過即丟軟體，例如專案建置腳本
- 熱縮封膜軟體，即給一般人用的軟體，例如商業軟體 office，共享軟體 linux
- 紙上原型，用紙筆快速勾勒出需求原型，開始討論、修改，定案在開始寫，無需大費周章建立精美原型
- 架構太空人
- 發散的提供很多解法，但卻不是用來解決一開始準備要討論的那個重點
- 嘗試解決那些他們自認能解決的問題，而不是那些解決了會有用處的問題
- 偶爾發生一兩天都無法進入沉浸狀態（無生產力），只能做些不用大腦的雜務
- 生產力的關鍵：開始（走出第一步）就對了
- 每天前進一點點，只要一直前進，持續寫程式持續修正錯誤，時間就會站在你這邊（每天都進步一點，面對競爭對手就可以爭取到更多時間）
- 不要讓產品依賴於大企業，就不用因為大企業產品升級版本，而讓自己窮於更新、移植、追趕，讓自己產品合於新版本
- 寫程式是一種工匠技藝，不是開個軟體工廠，以生產線的方式，就可以大量製造出高品質的程式
- 寫程式不是量產，也不全然是工匠技藝（但也可以是），他是一種設計，而設計價值是比成本增加更快的模糊區域
- 修正 1% 的問題，可能會用掉 500% 的功夫，不只是讓主要的程式會動而已
- 所以工匠技藝是很昂貴的，所以開發產品最好是針對大量的客戶，讓公司（收入）負擔得起額外的成本
- 搜尋，最重要的是要搜尋的到很多結果（錯誤），重點是在於搜尋的結果有無正確的排序（最準確的排第一之類的），google 的 page rank 演算法
- 去鋸齒的文字，雖然去鋸齒可提高螢幕可閱讀性，但也有鋸齒存在的必要（標題、整體外觀、縮圖效果）
- 網路透通（遠端資源就像本地資源完全相同）化，例如 RPC，遠端呼叫程序，他可以讓你在本地呼叫他就像是使用自己的 function 一樣
- 以上論點針對「透通」，也就是可以「完全相同」有其他看法
- 可使用性，網路斷線就無法使用，網路速度太慢也會造成中途斷線
- 延遲
- 可靠性
- UNIX 與 Windows 所依循的系統資源基本上是完全一樣的，例如幾乎完全相同的檔案系統、記憶體、socket 服務等，剩下的不同就是：
- 文化差異，其中有一項較為明顯的是
- UNIX 文化重視對其他程式設計人員有用的程式
- 用命令列可以呼叫其他程式
- 執行成功不會有任何輸出（沈默是金），喋喋不休的程式沒辦法跟其他程式好好合作
- 公開原始碼
- Windows 文化重視對其他「非」程式設計人員有用的程式
- 讓 Muggy 阿姨寄信之後，可以看到寄信成功的提示
- 對程式設計人員來說，需要撰寫 GUI 自動腳本來與其他程式配合，當出現錯誤時，無原碼的狀況會讓這些作業更加難除錯
- UNIX 文化重視對其他程式設計人員有用的程式
- 蘋果也做了 Windows 文化的行為，把 Unix 中的 bin 跟 lib 改成一般人可能看得懂得 applications 跟 library
- 在消費型軟體產業裡，不能靠客戶告訴你當機的狀況（怎麼當機的），因為很多客戶技術背景不足，而且大部分客戶根本不想為了提供當機報告而暫停手邊工作，所以你必須能把發生的錯誤做成自動回報
- 收集資料，收集那些極少量但關鍵的資訊是很有幫助的，例如程式在哪一行停止運作，發生時間，客戶若願意描述操作動作會更好（幫助重現）
- 產品版本
- 作業系統版本
- 瀏覽器版本
- 發生問題時的程式檔名跟行號
- 用文字方式呈現的錯誤訊息
- 對應該錯誤的唯一數字代號
- 使用者對發生問題時正在進行動作的敘述
- 使用者的電子郵件地址
- 打電話回家，把錯誤報告透過網路送到家裡的伺服器
- 識別重複發生的問題，同樣狀況可能會在很多人身上發生很多次，而我們不希望每次一樣情形都建立新的問題報告，可利用關鍵識別碼歸類為同一種問題
- 除錯，到下次改本前的時間，優先處理最嚴重或最常發生的問題（根據問題報告）
- 選別分類，當有以下情況我們就不用加以修正，例如
- 使用者電腦不正常，記憶體有缺陷
- 使用者嘗試手動修改我們的檔案（程式）
- 使用者用了 windows 95 等舊作業系統（或舊應用程式）
- 使用者在記憶體極度不足的情況下開啟我們的應用程式，磁碟和記憶體可能都滿了
- 你適合這種做法嗎？
- 公司內部使用的軟體，問題回報可能實用性不大，但如果你沒有 QA，找錯誤的工作還是回到你本身的話就另當別論
- 若品質是你的競爭優勢，那你就需要盡量修正錯誤，你需要問題自動回報，因為軟體會在各式各樣惡劣環境中被執行，你需要靠這些報告來讓你作為提高品質依據
- 可以找一些將來會做為應徵者「未來的同事」來一起幫忙面試新人
- 不要找「非程式人員」面試「程式人員」
- 只要有一絲猶豫，就是不錄用，沒有「或許能錄用，不過我有點擔心...」這種，機械式地把所有模糊不清都翻譯成「不錄用」
- 要找的人很簡單：一、聰明；二、能把事情做好
- 如何辨認聰明的人：不必一遍又一遍地重複解釋事情（問題），應徵者說出的話會顯露真正的洞察力、智力、敏銳度
- 聰明，不只是知道很多事，不只是知道很多瑣碎問題的答案
- 面試要「提問的東西」，要跟雇用這個人，你所考慮「應徵者需要必備的東西」，要有所交集
- 不要問在網路上花一點時間就能找到答案的問題
- 要給應徵者「開放式的問題」，而不是問是非題、選擇題：
- 問些什麼：
- 簡介，先請應徵者自我介紹，並說明面試的進行方式，強調我們感興趣的是解決問題的過程與方式，而非那個問題的答案
- 關於應徵者最近工作專案的問題，若是學生就問他的專題、論文，或課程中參與過又喜歡的議題；要從開放性的問題中尋找什麼？
- 第一，尋找熱情，一個正在應徵的人，有時會因為在聊自己有熱情的東西，而忘記自己正在面試
- 第二，好的人選，會仔細地把事情由各個層面解釋清楚，聰明的人可以用你阿嬤都懂的方式，解釋他正嘗試描述的一個專業的東西
- 第三，如果專案是由多個人一起負責，尋找擔任領導角色的跡象，當老闆說Ａ，你做Ｂ，但客戶想要的是Ｃ，你怎辦？好的答案：我和團隊其他成員開會討論，寫了一份建議書；壞的答案：我也沒辦法，這情況誰來都一樣
- 不可能的問題，問一些根本就答不出來的問題，考驗他們的反應，例如：台灣有多少的 PHP 工程師，在台中有幾台千萬跑車；答錯無所謂，積極面對問題才是重點
- 程式問題，不要問行數會高過十行的問題，時間不夠
- 你滿意嗎，問他剛剛回答的程式答案滿意嗎
- 你有什麼問題嗎，讓應徵者提問，讓好的人選利用這次面試來決定是否要為你工作
- 問些什麼：
- 避免任何先入為主，例如他學歷很高，就覺得他很聰明，克服不掉自己的偏見
- 制約實驗中，狗是為了獎賞而好好工作，而不是真正在意自己工作品質的專業人士
- 正面評價卻不如該工作者的預期，對士氣也會有負面效果
- 兩位程式人員就該配一名測試人員
- QA 有否決權，阻止發行不合格的軟體
- 請另外一個人來看，才可以看到，寫程式的人沒看到的地方
- 不要讓客戶幫你測試軟體，不要發布未完成的產品
- 程式設計需要在腦袋中記住很多事情，工作的切換就需要很長的時間
- 專案負責人要盡量讓程式設計師可以專注在某件事情上，避免讓他切換，能幫他接住的就接住
- 程式設計人員總想把舊程式丟掉在重新開始，他們認為舊程式是一團亂，其實原理在於「讀程式比寫程式難」或是「舊程式效率很差」
- 千萬不要隨便從頭重寫
- 避免花費大量資金做重複的事情
- 客製化案子進度延誤、失敗、或各種災難，常見的原因是：客戶並不知道他們要的是什麼
- 業務必須知道：客戶不知道他們要什麼，也不要期望客戶會知道他們要什麼
- 冰山有 90% 都在水面下，軟體也是如此
- 推論一：把使用者介面展示給非程式人員看時，如果介面不好看，對方會認為你整個程式也是不好的
- 推論二：把使用者介面展示給非程式人員看時，如果介面非常漂亮，對方會認為這個程式幾乎已經完工，你花了一年去補上功能，大家反而看不到你的成果，以為你什麼都沒做
- 推論三：外觀漂亮的網站比起內容豐富的灰色介面會獲得更高的評價
- 推論四：讓客戶碰一些無害的東西避免耽誤開發者的時程，例如變更首頁 logo 的大小
- 推論五：展示時，唯一重要的就是畫面，不要自認能成功讓任何人想像成品會有多酷炫，也不要認為他們會注意到功能
- 略過
- 略過
- 略過
- 沒有犯下致命錯誤的公司，管理掌權者會是程式設計人員，但反過來，管理掌權者會是程式設計人員，不見得就不會犯下致命錯誤，導致公司失敗
- 沒有犯下致命錯誤的公司，通常都會很成功，例如微軟
- Eating your own dog food，吃自己的狗食
- 自己開發的產品自己作為「一般的使用者」去使用，你會發現身為開發者角度（測試會動）從來不會測試到的問題（使用不方便）
- 有些人不吃自己的狗食，因為他很難吃，軟體具有不夠好的使用者體驗，但管理階層不讓開發者修正問題到至少可以入口
- 策略一：去做就對了，先從自己開始，無法取得的資源或需求，想辦法自己自幹一個
- 策略二：利用病毒性行銷的威力，使用好的工具輔助你的工作，即使別人一開始都不願意導入使用，你可以堅持使用，即使只有你在用，你要讓大家感受到使用起來真的很有效率，漸漸說服（逼迫）別人也使用，例如你用了一套問題追蹤系統，但別人還在用 excel 管理問題，你就告訴管理 excel 的人，我真的很想修好這問題，但我會忘記他，可以請你輸入到問題追蹤系統裡嗎？
- 策略三：建立一個卓越圈，團隊不排時程？不寫規格？你自己開始寫吧，找出那些願意又有能力改善的人，想辦法讓他們支持你
- 策略四：讓笨蛋無害，讓損害最小化，交辦他範圍較小，功能性較簡單的一些任務
- 策略五：遠離干擾環境
- 策略六：提升自己的價值，如果你寫的程式不夠好或不夠多，如果你被掛上做不出東西，只關心流程的惡名，大概就gg了，你在你能所做的範圍內，一方面改善讓團隊更好，一方面也要讓自己有可受檢視的能力（寫程式）
- 讓大家對自己的工作更有責任感，不能再用管理階層批准了規格這種想法來作為藉口
- 有些事需要天份才能做好，而天份很難複製（讓有天份的人寫出文件，交給其他人要他們照做，就期望可以達到一樣的效果是不可能的）
- 一份看似簡單的規格，背後要考慮的細節從來都不簡單，這通常在開始開發就會慢慢發覺要預防的、要驗證的、流程應該怎麼設計等等，陸陸續續地發覺，有經驗的開發者，則可以用腦袋跑過一次，答出這些「延伸」細節
- 其實就是基於「隨時隨地嘗試著降低風險」，而其中有一項需要避免的重大風險就是「進度風險」，也就是某件事情所花費的時間比預期多
- 事情沒有像表面看起來那麼簡單，只會導出一個結論，「你必須先做設計再去實作」，且原則上「不要做無謂的設計」，漸進式的設計與實作是好的
- 非我發明症，指某個團隊拒絕使用不是自己創造的技術
- 如果是核心的事業功能，不管是什麼都要自己來做，不要交給外包，例如公司如果重視的客戶服務，就不能外包請別的客服團隊來cover這部分，如果公司的價值就是程式設計，就不能外包給其他工程師，或是找「輪子」，你必須「自己做輪子」，你才能完全掌握你的核心價值
- Ben and Jerry 模式
- 長時間慢慢對幾個目標建立起一個事業，適用於已有需多成熟的競爭者在市場上
- 這種模式沒有網路效應，客戶鎖定薄弱
- 只要小額資金，所以可快速達到損益平衡
- 企業文化很重要
- 錯誤成為珍貴的教訓
- 需要很久的時間規模才能變大
- 可能會成功
- 一定不會損失太多錢
- Amazon 快速茁壯模式，又稱搶地盤
- 砸錢搶市場
- 適用於你是一種全新科技，或全新的事業，沒有明顯的競爭者
- 網路效應跟客戶鎖定都很強
- 需要極大量資金，所以要很多年後才能獲利
- 不可能有企業文化
- 錯誤很少會被注意到
- 很快就可以使規模變大
- 成為億萬富翁的機會很低
- 失敗的機會很大
- 網路效應指客戶越多，就會獲得更多的新客戶
- 「鎖定」是讓客戶不想更換的商業特性
- 或許你所能做最糟糕的事，就是決定要成為 Amazon 型的公司，後來卻照著 Ben and Jerry 的模式經營（而且還一直否認），Amazon 型的公司一定得盡可能地用金錢換取時間，你可以堅持用市價來聘請程式設計師，還認為自己聰明會省錢，但其實並不聰明，因為這樣會耗費六個月而不是兩個月
- 沒有客戶，就沒有人要為平台寫軟體，沒有軟體的平台，就沒有客戶
- 花錢，提供一個向後相容模式，提供一堆的雞跟蛋
- 當你想讓人們由競爭者的產品改用你的產品時，必須暸解「進入障礙」，而且還要暸解得比你想像中深入，否則大家是不會換過來的
- 所有人都有個理由不買你的東西，你需要類推出你的障礙有哪些，想出解決方案，書中要讓用戶改使用 excel 軟體例子
- 障礙 -> 解決方法
- 他們必須知道 excel，而且認為他比較好 -> 發售展示用磁碟片，全國巡迴到處示範
- 他們必須購買 excel -> 原 lotus 123 用戶轉換為 excel 時能提供特別折扣
- 他們必須購買 windows 才能執行 excel -> 製作一個執行時期 (runtime版，我猜就是簡易版 windows) 的 windows 版本，隨 excel 免費附送
- 他們必須把現有的 lotus 123 (另一個試算表軟體) 轉換到 excel -> 讓 excel 能讀取 lotus 試算表
- 他們必須重寫無法在 excel 執行的鍵盤巨集 -> 讓 excel 能執行 lotus 巨集
- 他們必須學習新的使用者介面 -> 讓 excel 能使用 lotus 的功能鍵，讓你可以用原本的方式作業
- 他們需要記憶體較多而且較快的電腦 ->
- 有些進入障礙不是「切換進去有多難」，而是「切換回去有多難」，例如我使用的 godaady 經營我的網站，有一天網址過期，我想移出我的網站內容，他卻要你直接續約才能進去控制面板存取內容，...
- 短視近利的做法，只會把客戶鎖定在外面，而不是鎖定在你提供的服務中
- 如果你承諾出客戶不高興的話隨時可離開，他們就會消除進入的障礙，且又承諾離開後可以無痛轉接變更到原本使用的服務上，都免費，消除了切換出去的障礙，客戶就會因為障礙越來越少而進入你的服務中，客戶開始使用，你才有機會去鎖定客戶在你的服務之中，而不是外面
- 如果很肥大的程式沒有什麼載入時間問題（現今電腦已進步到有更高處理效能了），不用花很長的時間只為了把它容量縮小
- 新版軟體多等兩個月的損失是看得到的，因為你花時間去減小大小（沒有實質效益）delay 造成的損失是很可怕的
- 80 % 的人只會用 20 %？所以只要實作 20 % 的功能 就能賣出 80 % 的數量？很不幸那 20% （使用者需要的功能）是會變的，為了盡量賣給擁有不同需求的客戶，軟體公司還是會盡量規劃到支援合理範圍內的所有功能
- 替代物品 (互補物品)，通常會跟其他產品一起購買的產品，例如電腦硬體是電腦作業系統的互補物品
- 電腦硬體降價，作業系統需求就會增加（電腦好賣，就會賣掉很多電腦作業系統）
- 理論上能維持最低價格的是「普及價格」，也就是很多競爭者提供相同商品時的價格
- 聰明的公司試圖讓產品的「互補物普及化」，例如微軟的 DirectX 這程式庫能在所有視訊晶片上運行
- 開放原始碼軟體是一種很好的商業策略，開放源碼後的軟體（互補物）會普及，進而使與之相對（公司主打的）產品的需求增加
- 普及化的互補物通常為低價，甚至免費
- 若你是硬體公司，就不該是讓硬體本身普及化
- 普及化後就沒有獨特優勢
- 軟體容易讓硬體普及化，但硬體很難讓軟體普及化，軟體的切換需要成本，使用習慣 excel 的人突然換一套辦公軟體是需要時間（成本）的，硬體卻不是，例如硬碟，你把你主機中的硬碟拔出來插到另一台主機中一樣會動（切換不需要時間成本），而硬體定價越來越普及親民，軟體因為有獨特優勢而不一定能被已經普及化的硬體影響軟體的普及性
- 有點像是：我的硬碟跑 excel 特別穩定，大家都普遍使用 excel 所以我的硬碟銷量會上升（？是什麼讓你產生你的硬碟跑 excel 特別穩的幻覺）
- 反之：我家的 excel 用起來特別方便處理辦公事項，而大家普遍都使用電腦辦公，我的軟體需求就會上升（你說，不見得啊，我換一套你的銷售量就會卡住，真的有這麼容易切換嗎？）
- 略過
- 略過
- 略過
- 略過
- 略過
- 略過