施政源

〈推薦序〉PM必讀的軟體專案管理入門   游舒帆
〈推薦序〉好的專案管理帶來商業價值  Ben Cheng
〈推薦序〉新創時代必讀的軟體專案管理書   黃文怡
〈前言〉軟體正在吃掉這世界
 
第1道難題  團隊管理靠技術或制度？
——懂得掌握人性才是關鍵點
電子商務的模式與類型
將「產品」交給「管理者」有何好處？
PM的核心永遠是管理大過於執行
第一堂課永遠是「產品開發循環」
聊完市場端，PM的難處才開始
 
第2道難題  外包好或內聘優？
——差別就在微妙的信任度
優秀外包人才難尋
外包合作的形式
讓我們來跑Scrum吧！
接案公司的立場與角度
 
第3道難題  PM要夠強勢？工程師就愛擺姿態？
——願意主動溝通與分享最重要
產品開發的「死線」&「溝通」
嘗試「遠端合作」模式
企業內部不可控制的抗力
產品思維VS.功能思維
產品開發就像跑馬拉松
 
第4道難題  情緒是因？風險是果？
——情緒穩定才能看清風險
別輕易種下情緒的因
坦然面對錯誤，推回良性循環
練習「向上反應，向上管理」
「不可數的」價值VS.「可數的」價格
合約規則是「幫助你」？還是「綁住你」？
 
第5道難題  只管開發？不理財務？
——必瞭的潛在風險與成本營收
軟體開發的各項成本
兩種營收比例，決定你對未來的判斷
 
第6道難題  精進個人？優化團隊？
——從六個層面&三道提問切入
了解組織規模與架構
專案管理必學基本功
公司運行的制度
產品開發VS.市場策略
建立良好的技術團隊
技術與UI / UX的整合
 
第7道難題  如何管理一群知識工作者？
——挑選技術領導&放權的學問
每個PM都需要適合自己的Mentor
如何尋找最佳平衡點
別成為團隊中最強的那個人
打造良好的軟體開發生態系

系列緣起

今日沙漠，明日汪洋。自我進化的生存之道！

謝銘元／iFit＆ECFIT雲端CRM 創辦人

　　網路在近數十年快速發展，除了讓資訊以百倍、甚至千倍提速傳遞，更重要的是「加速資金的自由流動」，進而加劇商業環境的更迭。放眼全世界，景氣循環的週期愈來愈短，以股市為例，2000年網路泡沫化，引發了2年多的大空頭；然而，2008年的金融海嘯，空頭市場縮短到僅有1年的時間。金融市場的循環週期縮短，隨之而來的便是商業環境的快速變遷。過去一個商業模式可能帶來10年榮景，現在每兩、三年、甚至年年都有大變動！

　　今日身處在乾涸的沙漠，積極尋求水源；明日可能就面臨汪洋，需要泅水求生。換言之，不管是企業經營者，抑或是孜孜不倦的工作者，生存的關鍵並非在既有環境有多少投入，而是面臨變動環境能在多快的時間完成自我進化，成為適應變遷的新物種，更甚至，設法將自己打造成水陸兩棲的突擊艦，才能夠在短期間調整，因應各種不同的生存環境。

　　以我個人的經驗為例，過去3次創業都處在不同領域，卻很幸運的都能獲利、持續經營；即便是在創業時間最長的「iFit愛瘦身」經驗中，我也不斷嘗試新的商業模式。常有人問我：「這種自我革新、進化的體質從何而來？」我認為有兩大關鍵：

　　（1）不管環境景氣如何變遷，都要持續強化「管理知識和能力」

　　「獲利工具」可能隨著環境紅利有所變革，就像是武功招式，然而「管理能力」卻猶如心法，能夠跨業態、跨產業持續累積。

　　（2）勤讀實戰案例，樂於交流學習

　　多年創業的過程，很幸運加入不少創業輔導組織，也得到許多和台灣實業先進交流討教的經驗，由於討論的都是大家「實際在做的事」，舉凡商業機會判讀、最大門檻、可能誤區等議題，都能夠得到很實際的討論。這樣的互動經驗，也讓我對不同產業、商業模式有更具體的思考脈絡。
　
　　出版這系列書籍的初心，便是源於上述的思考。每位讀者身處的時間、空間條件不同，未必能夠和我一樣，參與這麼多的實戰討論，閱讀書籍仍是多數人自主進修的主流方式。坊間多數的經營管理書籍，大多以歐美等國的公司作為討論案例，這些內容或許可以為大家帶來一些管理概念上的啟發，然而，由於經營環境和文化上與國內仍有本質上的不同，也導致讀者們的思考難以延伸至「這個狀況如果在台灣，我們會怎麼做」的落實層面上。

　　基於這個想法，我開始了這系列書籍的籌畫：「找台灣的經營者，談台灣的案例，論台灣的做法」，透過台灣產業中許多優秀經營、管理者的實戰經驗，讓本地的經營智慧能得以嫁接。

　　此外，相對過去的案例，多數談論已經成功的大型企業，在創業過程中篳路襤褸的艱辛，本系列會更著重在「正在成長中的企業，如何解決正在發生的問題」，或許案例本身的獲利並不算驚人，企業規模也算不上大，但正因為如此，他們所遇見的問題，更像是讀者們每天身處的商業環境中會發生的，以達到傳承「在地實戰智慧」的目的。

　　期望本系列的書籍僅是一個開端，作為拋磚引玉的先行者，讓更多的出版社願意投入台灣商業智慧分享。更重要的是，進一步帶起台灣實業經營者們的討論風氣，讓我們一起將自己打造成為水陸兩棲的突擊艦，因應全球景氣的劇烈變遷。

推薦序

PM必讀的軟體專案管理入門

游舒帆／商業思維傳教士

　　在閱讀本書時，思緒又回到去年與Paul見面時的場景。那一次我們約在台北車站的摩斯漢堡，碰面聊聊他獨到的專案管理方法，在碰面前，其實我並沒有抱持太多的期待，因為過去這些年來，我在專案管理這個領域也算老手了，各種管理方法我大多非常熟悉，所以當天只當是跟學弟碰碰面、聊聊天。

　　坐下沒多久，寒暄了一陣子，我們開始聊他的事業，也就是那獨到的專案管理方法，他告訴我：「我們公司只養PM，開發與測試部分則外包給其他團隊來做。」，我說：「那不就是大包轉小包嗎？有什麼獨特的呢？」緊接著他告訴我：「第一，我們長期合作的工程師有上百位，而且使用了系統在管理，我們熟悉每個工程師的專長以及做事的品質；第二，我們的PM不只是個系統PM，是能從商業面直接與客戶溝通的。」

　　聽到這裡，我的興致來了，因為上述兩點的實現難度並不低，我開始跟他聊起細節，包含流程如何運作，以及人員怎麼養成等，Paul一一回答了我的問題，對於細微之處的說明非常具體，沒有一絲含糊。

　　我所認識的Paul是一位兼具系統性思維，同時也在乎人性的創業家，從Fable的發展中，他除了將專案做好外，也試著將最複雜的人力資源管理進行系統化，大幅降低了人力資源在專案執行過程的變因，而這自然也大幅的降低了專案的失敗率。

　　然而，重視系統化與流程化的同時，Paul也同時在意人與人之間的信任感、領導與賦權、人性與團隊運作。

　　在這本書裡，除了能學習到專案經理應該具備的基本素養外，你還能從Paul身上學習如何理解人性，如何有效溝通，如何忖度時勢做出正確判斷，以及面對兩難選擇時，又該如何沉著冷靜的做出恰當選擇。

　　這本書除了適合新手PM用來扎實專案管理的核心觀念外，我相信資深PM也可以在本書中獲得共鳴，並在思維上有所啟發。

推薦序

好的專案管理帶來商業價值

Ben Cheng／香港知名技術研發公司Oursky創辦人

　　做為軟體技術背景的創業者，當初營運公司時，並沒有認為專案管理很重要。注意力集中在精進軟體工程技術水平，甚至有專案管理員戲稱在公司的職責是「Keep Developers Happy」。

　　直到一次有位好朋友找我的團隊處理一個技術專案，處理Microservices 架構，理應價值在技術經驗。可是半年後他卻告訴我，對他的技術團隊來說，整個案子最珍貴的部分，是我們的專案管理而不是技術，這才讓我第一次考慮到專案管理的重要性。

　　不少工程師輕視了專案管理的需要。但軟體是用戶和工程師之間的交流，沒有好的專案管理，功能需求一團糟，用戶的意見胡亂丟到開發團隊，技術債一直上升，最終工程師和用戶都抱恕。有好的專案管理人員，軟體工程師能專心每天設計、寫代碼、除蟲，用戶能享受高質素、介面友善、更新快速的軟體，創造商業價值。

　　傳統由上而下的專案管理，在21世紀前已被證明不適用於軟體開發。為了讓軟體開發迅速、高質素，興起了各式各樣從Scrum 到 Kanban 等專案管理方法。

　　管理的對象是人，便自然會受文化影響。看過無數Scrum的教材，實際應用時還是會受到不同的企業文化、財務管理需求、團隊的背景等等而需要調節。

　　我第一次認識Paul 及Fable 時，最深印象是他說︰「我們的價值在軟體專案管理，團隊沒有太多工程師，主要合作的工程師都是外包的。」他以此經營 Fable，發展迅速。

　　期間看見 Paul 的團隊一直在學習、微調專案管理的流程，把內部的學習紀錄結集成手冊。能夠把流程及各種情況應對的方法做系統紀錄，相信累積了不少經驗。

　　以Paul 與亞洲各地不同團隊合作，學習到的軟體專案管理在地經驗，結集成書，相信會對不少專案管理人員、創業者，以及在傳統產業數位轉營的經營者，帶來不少益處。

　　也希望透過提昇產業對軟體專案管理的認識，讓亞洲的數碼轉營更成功，更能夠發揮軟體工程師專業的價值。

推薦序

新創時代必讀的軟體專案管理書

黃文怡／PTT創業版版主

　　這是一本你今年必讀的書！因為也許明年書裡的個案就過時或消失了。       作者Paul以實務個案分享及策略思維為經緯撰寫本書，讀起來頗有身歷其境之感。如果你已經身在數位科技產業，閱讀時定會頻頻點頭，或是陷入長考，開始思索自己如何處理這樣的問題。

　　這是一本數位科技產業工作者必讀的書，不論你是產品經理、行銷、設計、業務、工程師等，不論是受僱者或外包SOHO，都能在書中獲得實用資訊。

　　如果你是剛開始接觸或是即將進入這個產業的朋友，這本書可以幫助你少走很多冤枉路。但就如同Paul在書中所寫，「身為一個軟體世代的管理者，會遭遇到的問題是永遠無法預估的，因為軟體開發跟人有關，而人的行為是所有事情裡面最難以預測和計算的。也因此，管理者的思維純熟度決定成敗，打死不退更是必要的心態之一！而這點需要大量的經驗。」        重點是心態和思維，看Paul如何積極面對和解決問題和挑戰，是本書最讓人熱血的部分。

　　這是一本創業者必讀的書，不論是新創還是傳產，數位時代來臨，如何跟上時代腳步的創新管理，調整組織和思維，是每個創業者必須的試煉。本書能讓你取暖，也能讓你思考該如何管理數位時代下成長的年輕人。

　　書裡面有很多有趣的個案，像是藉由炫耀GOOGLE來找合作的過程，來分享尋找自我價值的歷程，還有不斷接別人爛攤子，承接開發到一半，或是開發已經做好，但是因為沒程式碼要從頭開發的產品後，領悟出「人」是產品開發最大的成本和風險。每一篇都是血淚交織的寶貴經驗，單看就能能心有所感。

　　認識Paul的人都知道，他是一個熱情和樂觀過頭的人，十分有感染力，他的文字也是。和Paul認識是因為他來參加我舉辦的PTT創業版版聚，那時寓意科技還沒成立。寓意科技是Paul創辦的公司，公司的名字「Fable」還是我取的，他在書裡面有一直置入，大家看完就會發現，哈！看到他能寫出這麼言之有物的書，我真是十分感動，想到他在網路上認真開始發表的第一篇文章，我客串編輯修改並大罵他文筆有夠爛，現在文筆能變得這麼好，在《數位時代》寫專欄到出書不斷的練習和修正，就是把事做好的不二法則。

　　最後節錄這本書我最喜歡的一段話，「歷經這幾年的創業磨練，才發覺作為一個成熟的管理者， 除了情緒不能太過激動外，很快的找出問題關鍵點，更是重要的技能。」

　　不論是工作還是人生的道路上，我們都會遇到很多磨練，能夠精確的發現問題所在，以穩定的情緒，積極解決問題，讓他人放心，自己安心，是我們都該學習的事情，與大家共勉之。

前言

軟體正在吃掉這世界

　　2011年，網景公司的創辦人Marc Andreessen在《華盛頓郵報》發表一篇文章——軟體正在吃掉這個世界（Software is eating the world），他從1990年後期的網路泡沫化，一直發展到2011年的角度，看到臉書、推特等大型社群網路公司相繼成長，成為全球舉足輕重的企業，並眼見我們的生活被軟體大量占據，預測這個趨勢只會越來越劇烈，不會停止。

　　同年，台灣的花博剛結束，嶄新的場地吸引了大量人潮前往，但整個過程中沒有見到太多特別的軟體服務，硬體的成就倒是相當厲害，像是用寶特瓶蓋起來的遠東館，就是一個相當不容易的事蹟。

　　也是同一年，我第一次踏入創業領域，以IOT的議題做為開始，看到許多硬體與軟體嘗試合作的歷程，對於從中央大學資訊管理學系畢業的我來說，以前接觸的大多是網路、軟體、伺服器運用、ERP等等，是一個相當不同的領域，但這也造就了接下來幾年，我們走上軟體技術開發管理的研究這條不歸路。

　　硬體與軟體，思維大不同

　　為何提及上述這幾件事？因為硬體的製造，讓台灣在1990年代創造了經濟奇蹟，卻也成為2000年後、世界邁入軟體與網路時代時，台灣最大的包袱。這中間的差異有多大？如果以管理學的角度來看，生產、銷售、人資、研發、財務，每個環節都是不同的；其中差異最大者，莫過於銷售與研發生產。

　　以銷售面來說，台灣多數硬體公司思考的是賣量，訂單大多是以量來計算；有量就有錢，但多數銷售硬體的公司不會直接思考終端服務。到了軟體時代，思考變得多元了，除了像Google一樣的用戶免費，企業付廣告費的模式，或像Netflix的用戶月費機制，或者是Airbnb、Uber從中抽取服務費的模式，軟體的銷售模式變得相當靈活，甚至有很多中國、美國的企業開始重視使用者數據更大過於收入的現象，在近十年的市場案例屢見不鮮。

　　有了使用者數據，可以開拓更多面向的服務，微信就是最典型的案例，這些在台灣過去的十年，都是相對少見的。反之，台灣近十年舉足輕重的企業，仍舊是1990年代一躍而起的硬體產業，因為沒有了市場的支持，台灣軟體開發管理的思維隨之落後，也沒有足夠資金去創造案例與故事，致使身處在軟體時代的我們出發點便落於人後。

　　當軟體無法創造價值時，自然市場就不夠開展，也沒有資源去學習與成長，更無法針對軟體做更多的研發、研究。當我們這幾年投入研究軟體的技術管理時，發覺硬體與軟體的研發與生產方式，更是天差地遠。

　　軟體的產線都跟人有關，不同於硬體產業部分跟機器有關。就因為都是人，所以可能性如同銷售一樣，變得更多元了。從2007年蘋果開展iPhone至今，軟體開展的面向變得太過廣泛，從以前只有網頁服務，到有了App，甚至接下來像Chrome的擴充程式、維信小程序或是LineBot等。之後，金流支付也一再精進，甚至有了區塊鏈的技術。網頁近十年來沒停止，框架的更新速度，其實不輸其他任何平台，只能說軟體創造的生態系在過去十來年中，恐怕沒小於硬體所創造的生態系，甚至有過之而無不及，這也是為什麼我們需要研究怎麼管理的原因，因為早期的PM知識，在軟體世界已經大幅改變了！

　　最大的改變有以下幾點：

　　一、專案管理結構大翻轉

　　開需求、管時程、控成本，這些都是專案管理不變的範疇。但時至今日，軟體開發的專案管理範疇確實越來越廣泛，原因很簡單，因為軟體的使用者是人，開發者也是人，產線中的每個流程，都與人有關。從市場端到需求的開出，到軟體的研發，最短可以是一人全包，有些遊戲或軟體工具，甚至是兩、三個工程師自己做完就上線，進而取得成功。

　　但有許多動輒數十人、數百人的平台也不在少數，如何讓所有聰明的腦袋結合在一起作業，絕對是這個時代最大的挑戰！畢竟不是每間公司都是Google、Facebook，但每間公司確實都需要工程師的協助，因此現在的專案 / 產品經理（統稱管理者），需要懂的不只是開需求，更要懂市場端在想什麼；需要懂的不只是控成本，甚至要懂得每一個專職不同語言或不同領域的軟體工程師，如何有效合作。不只是前端、後端，未來鐵定遇到的包含資料分析、大量與三方工具的串接、動態調配的外包人力等等議題，都會是管理者的重要課題。

　　二、銷售方式帶動研發方式改變

　　很多人都覺得軟體不是做好之後，讓它自行運作，負擔一些維護成本就好。大約十多年前，或許很多軟體服務都是類似的，那時很多軟體服務還是Client-server架構，不像現在是網頁跟App當道，每次更新都是一大工程，那時候確實很多軟體一套打天下。

　　現在的用戶被一些大型網路服務公司養大胃口，除了功能要持續更新外，隨著App系統更新而被迫跟著更新產品的工作也不少。只要發展一套產品，就像是挖了一個黑洞，錢只會越燒越多，從來不會有做完一次就沒工作的狀況。

　　如果你的產品是向用戶收取月費，或是跟企業持續性的收錢，那維持產品的完整性，甚至為了滿足客戶服務的開發成本都是不會少的。更別說近幾年，許多服務的迭代速度是以月或雙週為單位，不更新的服務會被使用者認為沒有未來，這時候做產品的研發方法，自然跟以往大大的不同。如今要跳入軟體世界做競爭，更是需要一些心理準備，因為從硬體時代以年為單位在打造產品的思維，在軟體時代是完全不適用的。

　　三、新工具發展速度超快，副作用也不容小覷

　　現在有許多三方工具可以讓開發者自由運用，甚至有許多開源計畫，貢獻的開發者可能比你自己的產品開發團隊更大，更新速度更是超越你的開發速度，在這種狀況下，開發的文化跟以前相比，也是大幅改變。

　　我最喜歡的比喻方式就是積木。以前寫程式開發產品，每個積木都要自己去打造，做出不同積木後，再把自己要的房子形狀蓋起來。而現在，大多是用人家已經量產好的積木去打造房子，時間跟速度變快了，但隨著每個積木的生產者不同，要能拼湊不同形狀的積木變成一個好房子，也變成一門學問。

　　最常見的故事，很多發生在電商網站。許多人用了套件去做電商網站，比較常見的像是Shopify、woocommerce；蓋了之後，在改版時，想要改些功能遇到很大的障礙，想要重新打造網頁又有很多資料轉移的問題，搞得不上不下。我甚至遇過一些woocommerce許久沒更新的平台，這些都是技術模組盛行下的副作用。

　　四、一個PM所需承擔的資訊，速度與量都超乎想像

　　由前述幾點不難得知，速度與資訊量都對現今管理者造成極大的壓力。以前資訊不發達，競爭者大都是一些資訊來源比較多的人，但現在並非如此，很多2、30歲的年輕人懂的資訊不見得比40歲的人少，雖然很多事情還是需要經驗來做判斷，然而有價值的經驗也確實越來越少了。

　　年紀大時要持續跟進這麼多新的技術，這兩年甚至有種每半年多一個新的技術議題，從早期的雲端，到大數據、人工智慧、區塊鏈、Deep Learning、Reinforcement Learning，一大堆新技術多數人都不知道怎麼運用，哪些適合自己，哪些不合適，大部分的PM根本不了解，因此形成市場上一堆亂槍打鳥的技術管理者，做一個產品每個東西都要沾一點，看起來好像很厲害，但是怎麼導入卻一頭霧水，搞到最後連團隊都霧煞煞。

　　只能說這年頭的軟體環境，工程師的好壞差距固然很大，但好的產品開發管理者，跟不及格的產品開發管理者，其間的差距可說是天跟地的距離。

　　專案經理與產品經理的差別在哪裡？

　　在培育PM的幾年經驗當中，有很多人喜歡問我一個問題：你說的PM到底是專案經理，還是產品經理？幾年下來，我還是不喜歡定義專案跟產品的差異，但我漸漸搞懂一個思維的差異，而這差異我以一個很有趣的比喻記錄如下——打造產品從零到一，在產品上線的那一刻覺得自己完工了的就是專案經理（Project Manager）；而覺得自己準備開工的，就是產品經理（Product Manager）。

　　兩者誰比較重要呢？說實話，兩者同樣重要，而且兩者對彼此都要有深入了解，才能互相合作。作為一個專案經理，最重要的就是帶領團隊達成目標，如果目標是設定做好一個產品上線，那怎麼將資源整合後、將產品做上線，就是他的重點；如果他的目標是設定把一個更新做好，同樣的，他也要根據原本系統架構，判斷怎麼做最好，然後達成任務，這就是專案經理最重要的責任。相對的，產品經理的任務，就是將產品發揮出該有的價值，所以很多人覺得產品經理大多需要從客服、業務出身，這樣才能將服務發揮得淋漓盡致。

　　以前有位好友對產品經理這角色寫下很好的形容——在新創公司，產品經理有點類似是CEO的角色；簡單來說，管理產品所有的議題就對了。

　　但其實我很不喜歡定義這兩者的差異，因為作為一個產品經理，不可能不理會專案經理設定的目標無法達成怎麼辦；而作為一個專案經理，如果不了解產品未來的動向或產品的價值走向，怎麼知道設定一個最重要的目標、或是我們稱做需求計畫（Spec），作為團隊發揮的方向。

　　若真能區分這兩種角色，只有一種狀態，就是當產品經理很清楚自己要的，專案經理也很清楚自己該做的，彼此溝通順暢，那麼彼此的分工明確，很好做事；但實際狀況大多事與願違，甚至很多企業能找到一個真正懂產業、懂得規畫產品價值走向的產品經理都相當不容易，又何來專業分工呢？

　　當你看完這本書，如果真的想踏入軟體PM這個領域，我絕對不會叫你思考：適合專案經理還是產品經理？相反的，你要有心理準備在這領域繞個兩、三年，漸漸搞懂產業生態或產品生態，然後再花個兩、三年，找出自己在這全部過程中能發揮的最大價值。相信過了五、六年，所有失敗的路子都看得差不多，你的PM道路自然就打開了。

　　五、六年很久嗎？如果你能在這過程中學會所有管理產品開發團隊與營運團隊的能力與心法，這樣的時間投資絕對是划算的。如果你已做好心理準備，那就別閒晃，頭洗下去就是了。

　　管理的思維需要與時俱進

　　在軟體開發領域工作將近十個年頭，這對很多人的工作經驗來說，只是不到三分之一的份量。但這十年當中，我看到軟體的快速演進，對很多人來說，這十年工作習性的改變，恐怕也是前所未見的快速，舉一個最簡單的例子，十年前我們透過電子郵件做訊息傳輸，常常一封郵件來回就是兩、三天，而且郵件一定要用電腦才能開啟，手機在當時只是用來打電話、傳簡訊的工具而已。

　　十年過去了，手機訊息軟體已安裝快十個，每每會議結束，就多了一個群組。訊息的來回傳遞，往往在三十分鐘內就發生了，而且不同的案子、不同的事件，在群組內交叉來回，所有的管理節奏、資訊傳輸速度，硬是比過去快了數十倍。此外，網路上的工具也是前所未見的多，這就是我們目前面對的世界，也呼應了Marc Andreessen所提的——軟體正在吃掉這世界！吃掉的過程還帶來許多我們從沒想到的副作用。

　　除了看到速度的改變，還包括產業結構的改變。以往許多事業，一定要大公司具有龐大資金才能操作。直播產業就是一個最典型的案例，它需要的視頻技術、網路技術、支付技術，在這幾年已經逐漸模組化，若是十年前，恐怕得用個數十位工程師，分別在機器、頻寬、網路傳輸，甚至服務端花上不少功夫。

　　因此近幾年許多新創公司的崛起，大多拜技術越來越成熟所賜。相對的，大公司過去的技術包袱，反而成了這個時代的累贅，不管是公司技術團隊的問題，或是原本用的技術留下的技術債也好，都造成了許多問題。

　　舉一個我看過不下十次的案例——我曾經去過幾家公司擔任顧問，原本的後端技術架構，有的是用ASP.NET，有的是用PHP，整個後端沒有框架，或用的是原有團隊成員自己寫的框架，卻沒留下文件，導致新成員加入後，衍生各種水土不服狀況，甚至有新成員排斥用這些框架來做學習的楷模，造成新舊團隊之間的隔閡，這些都是典型的問題，而這也是我為什麼想寫這本書的初衷——管理的思維，需要隨著時代的進步做出調整，希望能留下一些有用的經驗給大家參考。

　　在這本書裡，能力絕對不是我想提到的重點。坊間已經有許多講專案管理、講成長駭客，也有講怎麼導入Scrum，怎麼寫程式、能力思維的書，應有盡有。如果身為一個PM，懂得所有技能，卻不懂在不同情境中做出判斷，不懂得因為失敗學習到新的視野，不懂得面對未知的未來世界，不懂得建立自己的觀點，不懂得了解人，或者學會與人合作，不懂得面對自己的情緒與失敗的壓力，那麼就算懂得再多，我想都是白搭。

　　對於一個PM來說，重要的是見招拆招，心法比一招二式來得更重要，如果能一再琢磨，成長速度絕對比經驗更重要，因為在軟體世界發展神速的這個時代，經驗有時候反而成為一種包袱也說不定。

　　所以這本書留下的，是這十年來，碰過所有的產品開發經驗，沒有分專案還是產品，也沒有分大企業還是新創，各有各的不同情境，也有不同思維角度，但思考的根本，不外乎就是在解決問題，並且在解決問題後留下制度，讓問題不會一再發生，看似簡單，但自己真的做下去，就會發覺當所有問題混在一起時，很多事情就變得沒那麼容易了。