精實執行 ： 精實創業指南這本書是我在逛圖書館時意外發現的，久聞此書大名，所以就順勢借回來讀讀看了。這本書主要在講述關於創業的心法，但其實我自己對創業並沒有太大的興趣，不過有幾個理由讓我有點想讀一讀創業者在想些什麼以及他們究竟怎麼做。
- 做為上班族，有時候實在不太明白老闆到底在想什麼，而且他們又常會用一種「我是用掌握全局的觀點來管理，你們這些當部下的就是要乖乖聽我的指示」這種態度來說話。老實說，雖然也能夠欺騙自己就這樣相信老闆，但是疑惑的事情就是疑惑，無知本身便是一種罪惡，於是我想讀看看。
“There is only one good, knowledge, and one evil, ignorance.”—— Socrates (蘇格拉底)
- 在經營粉絲專頁以及部落格的時候，常常感覺自己在做很不像自己會做的事情。感覺那就像是自己的事業，而默者就是我的公司名稱，而粉絲、讀者就是我的顧客——當然沒有這麼一板一眼，比起公司似乎更接近不認識的網友？只是經營粉專跟部落格需要的不只是作為作者或作為軟體工程師的知識，還需要一些不太一樣的東西，所以我想讀看看。
我沒有打算創業（至少目前沒有），所以這本書在闡述關於創業的部分我比較少有共鳴，所以大概不會描述太多，但我覺得這本書對創業者應該很有用處，就連我這個沒什麼創業概念的人在讀的過程中都能得到不少啟發，我相信對有心創業的人一定更有用。
「 精實執行 」是從計劃Ａ反覆演進至有效計劃的系統化程序，特別是在耗盡資源以前。—— 精實執行 ： 精實創業指南 第二版
下面介紹一些在這本書裡讓我覺得特別印象深刻的地方，我也會試著把我自己的狀況套用到上頭，只是我的狀況並不是創業，所以實際套用起來可能會有點荒腔走板、不倫不類，如果讓您感到不舒服，還請多多包涵！
Lean Canvas：一張用來填寫創業藍圖的畫布
這個表格很精簡但有效地列出創業需要寫好的表格，比起複雜的企畫書，想要發展初創事業，這種可以迅速簡明直指重點的表格更加適合。
我姑且拿自己的狀況來填表格，但由於我沒有創業的念頭，所以應該會有很多填得亂七八糟的地方，還請多包涵。
問題
對我來說，我應該要找出值得解決的問題，而且這問題還必須是我能藉由粉絲專頁與部落格提供解決方案的。
我一開始開粉絲專頁是因為小說即將出版，覺得有個能夠分享心得以及聽聽大家想法的地方似乎不錯。而部落格則純粹是自己想對生活留下紀錄，以及想讓自己能更自由、更多方面地寫文章磨練技藝。似乎都不是在解決讀者或粉絲的問題，反倒更像在解決自己的問題。好吧，那就當作是解決我自己的問題吧XD
所以，問題應該是：
問題一：想要分享心得及聽聽大家想法。
問題二：想要紀錄生活以及磨練寫文章的技藝。
解決方案
- 粉絲專頁：確實分享了很多自己在寫作或生活中的心得，也聽到了許多人（尤其是年輕人）的想法，讓我學到不少東西。
- 部落格：這個才剛開始，不知道效果怎麼樣，但因為是我自己架的網站，文章的格式也比較自由，目前看起來確實可以寫更多不同類型的文章，只是問題在於我能不能持之以恆XD
關鍵指標
- 用來評估目前的執行狀況。
以工作來說應該就是KPI，以粉絲專頁來說可能是按讚數及追蹤數，以部落格來說是流量。
獨特價值主張（UVP: Unique Valued Proposition）
- 陳述你為何與眾不同且值得購買的清晰且具有說服力的單一訊息。
對於這個項目我沒什麼想法，也許我能寫一下為什麼我選擇粉絲專頁以及部落格。
- 粉絲專頁：以分享心得以及快速得到大家的回應這一點來看，我考慮過FB, Plurk跟Twitter，選擇FB的理由也很簡單，因為我雖然有Plurk和Twitter的帳號但幾乎沒在用，也不太會使用，其實就連FB我都很少用，權衡之下就選了相對熟悉的FB。
- 部落格：在FB發文的時候受限於其發文格式，以致於很難按照自己想要的方式來做排版，而且放在FB上的文章感覺有點像是寄託在別人的平臺上，變得好像所有權不太屬於自己，所以最後決定要創造一個屬於自己的園地，也就是部落格。
不公平競爭優勢
- 無法被輕易被複製或達成。
這一點我真的寫不出來XD 不過作者也說過，寫不出來可以先跳過，所以我就跳過～
通道
- 接觸顧客的路徑。
- 粉絲專頁：接觸顧客的方式應該就是透過FB的發文觸及率機制（這機制變來變去，真的很討人厭……）
- 部落格：透過FB宣傳而來、Google Search
顧客區隔
- 就是目標的顧客
- 最大的顧客就是我自己以及小說讀者！
成本結構
- 粉絲專頁：沒有金錢成本，最大的成本是時間XD
- 部落格：因為有租用自己的網域以及代管主機，所以有小小的費用，但可以擁有自己的網站覺得很值得。
收益來源
- 粉絲專頁：如果有提升一點點小說的銷量算是收益來源嗎？
- 部落格：也許未來可以放廣告，但目前只是很任性地放自己想寫的東西，所以沒有抱持什麼收益的期待XD
MVP: Minimum Valued Products, 最小可行產品
找出值得解決的問題（必須是可解決、顧客真的想要且願意掏錢購買解決方案的），並且衍生出解決它的最小功能集合。愈小愈好，聚焦在真正值得解決的問題，快速地學習並改善最佳化，減少資源的耗費。
對我來說，我的最小可行產品應該就是目前的粉絲專頁以及這個部落格。尤其是在建立這個部落格的時候，為了盡可能減少建置所需要的工作，我幾乎都是用現成的東西來套用，好讓我能很快弄出一個還能看的部落格來放文章。
問卷調查對驗證比較有效，而不是對經驗學習，經驗學習要靠親自訪談比較有用
平常其實很常見到有人在做問卷調查，其實我一直蠻納悶這個的作用，不過看了這本書以後我總算明白問卷調查的用處，它並不是為了要從我們的回答中學到什麼，而是為了驗證調查者預先做好的假設。
時間的衝突拉鋸
- 管理者通常將他們的時間組織成以一小時為單位，每一個小時處理不同的工作。
- 在管理者的時間表中，情境切換（context switching）的成本不高（而且是可預期的）。
- 創作者，如程式人員和作家，則需要將他們的時間組織成較長的連續（不被打斷）時間區塊為單位。
- 創作者的時間表中，情境切換的代價則相當昂貴（而且是扼殺生產力的殺手）
關於時間的衝突拉鋸的描述，我深表認同！
- 作為小說家的我：理所當然希望寫小說的時間是較長的連續（不被打斷）時間，不過因為這部分利用的是我自己的私人時間，相對之下比較容易控制。目前幾乎都是晚上睡覺前，因為這麼一來，即使加班太晚也不會影響到寫小說的時間。不過，我一直覺得好像應該把這個時間挪到早上六點鐘比較好，這樣才不會老是太晚睡……
- 作為工程師的我：強烈認同寫程式也需要較長的連續（不被打斷）時間，但實際上真的很容易被各種情況打斷，然後之後又會被老闆質問為什麼給了那麼多時間還無法完成，但實際上就是真的會花這麼長的時間而又很難解釋，這種時候就應該要拿出這本書跟老闆解釋情境切換(context switching)會造成昂貴代價！（雖然我也很懷疑老闆會不會聽就是了XD）下面記錄幾個我在寫程式時常被打斷的狀況：
- 同事丟訊息問問題。
- 老闆突然指派新的任務。
- 最高優先處理的任務：也就是說要你中斷手邊工作先處理的意思。
- 稍微弄一下就能完成的任務：對老闆來說，就是覺得應該不花你什麼時間，你可能立刻（或稍微確認一下）就能完成的任務（或問題），但實際上就是中斷了原本的工作導致情境切換(context switching)
- 高重要性的電子郵件。
- 例如來自顧客的問題……
一般初創事業多會順應客人的要求，傾向於建造更多功能，但那鮮少是正確答案
- 更多的功能會稀釋掉你的獨特價值主張(UVP)
- 功能總是隱含成本
- 你還不知道顧客真正要什麼
關於上面幾點，雖然不確定適不適用於已經穩定的大公司，但我也覺得深有感觸。感覺我們好像總是因為顧客說一句「想要」就不斷增加功能，卻都沒有好好記住自己的獨特價值主張是什麼，而這些隨意增加的功能又包含了多少成本，還有，顧客實際上也很常在我們辛苦把功能實作出來以後覺得不喜歡就拿掉，瞬間就把一大堆人力資源丟進水溝裡，換句話說，我們在根本不知道顧客真正要什麼的情況下去做了一堆不需要的功能。
實施80/20原則
- 發佈產品之後，80%的時間用在評估及改善既有功能上，20%才是開發新功能。
關於這點，我也不知道適不適用於已經穩定的公司。實際上我看到的情況似乎是用80%的時間在開發新的功能/產品，20%的時間在改善既有的功能/產品。關於這個比例我不太確定怎麼樣才是正確的，因為對公司而言，既有的功能/產品已經上線賣錢，要繼續增加收益就應該開發新的功能/產品。然而，改善既有的功能/產品不只能夠專注提升獨特價值主張，也能夠留住顧客。所以這一點讓我再多觀察一些時間。
限制同時間被處理的功能數量
- 可以透過Kanban(看板)來進行，限制同時間被處理的功能/任務數量。一個基本的Kanban包含三個Buckets：
- 待辦清單
- 按照優先順序來條列工作項目。
- 進行中
- 待辦清單佇列通常根據當前產品目標(焦點)的優先順序而被記錄，這讓我們可以輕易地直接挑選清單中最上面的功能來處理。
- Kanban有效限制工作佇列的關鍵原則在於限定任何時刻下能夠被處理的功能數量，這樣令你在最不浪費的情況下讓生產力最大化。
- 建議一開始先讓進行中的工作數量限制成團隊成員的人數，之後若有需要再調整。例如，團隊中有三個人，則同時間可被處理的工作就是三項。
- 在工作上，我覺得同時間可進行的工作數量很不好安排，因為有些工作大多數時間是在等待其他人的回應，所以其實可以同時進行多項任務，然而，這也可能造成一個後果是所有的工作剛好同時被回應，需要我們立刻處理時就會爆炸XD 這時候可能也是得依據優先順序來處理。
- 已完成
- 當功能完成就被移到這裡，但已完成的定義依據不同團隊可能有所不同。以軟體團隊而言，它可能是完成程式碼、已測試、已部署等等都有可能。
- 待辦清單
創造每日活動的流暢性
在這裡，我覺得作者提出了許多工作訣竅可以作為參考，在這裡我只列了三個我特別有共鳴的：
- 工作訣竅 1：為創作者活動建立不被打斷的時間區段
- 建議6:00~8:00
- 不收信、不處理公事、專心創作
- 工作訣竅 2：每天盡早完成創作者目標
- 建議早起，因為這樣白天的工作比較不會因為早上還在睡覺而受到干擾，而且盡早完成某項具體任務會為一整天的其餘時間定下基調。
- 工作訣竅 3：盡量將管理者活動安排在一天當中較晚的時刻。
- 例如下午。因為計劃的管理者活動，例如顧客會面，是比較容易排程的。
其實綜合起來就是早點起床寫小說的意思XD 不過我也覺得早上早點起床比較不會影響到接下來白天的行程，晚起的話很容易因為睡過頭而導致某些原本計畫好的事情（尤其是像我打算讀一小時英文這種不是硬性規定時間的計畫）被耽擱甚至取消。
別容忍任何失敗的測試
- 在作者工作過的一些地方，開發者訓練自己忽略失敗的測試，因為他們知道這些缺陷並不是新發現的。
我在失物咖啡館（上）裡頭也提到過類似現象，我想這點應該許多軟體工程師都有自覺XD
以上是很不像心得的心得，單純只是把我在看這本書的過程中有些感想的地方條列出來，然後再放上一些自己在工作上遇到的狀況（還有抱怨）。不過就像開頭說的，我的狀況不太像創業，而我待過的公司又都屬於相對穩定的公司，所以跟這本書所講的內容可能並不是百分之百適用，但我自己在讀完以後覺得是有不小幫助的，有許多書裡提到的東西，我自己有筆記起來但因為比較瑣碎雜亂，就沒有放進這篇文章裡頭。所以，雖然這本書的目標讀者應該是想創業的人，但我覺得對於了解老闆們在想什麼以及為什麼要這麼做有興趣的人也很值得一讀！
如果對這本書有興趣的話，歡迎從下方連結來購買。本站將獲得部分消費金額作為傭金回報並維持本站營運的開銷，但這不影響您所購買任何商品的價格，本站也不會多收您任何一分一毛。
