⭐ GitHub: github.com/kaminoikari/product-playbook

📦 立即安裝: npx product-playbook

Part I: 背景

AI 自動化了簡單的部分，困難的留給直覺

GitHub Copilot 突破 1.8M 付費訂閱、Cursor 拿了 $900M 融資、Windsurf、Devin、Replit Agent 接連拿到天價估值。整個產業瘋狂投入一個命題：讓 AI 把規格變成程式碼。但「寫程式之前」的階段呢？決定要做什麼、搞清楚為誰做、理解為什麼值得做 — 這些產品最上游的決策，仍然靠直覺和散裝的 ChatGPT 對話。

最貴的那行程式碼，不是 bug 最多的那行 — 是解決錯誤問題的那行。 CB Insights 經典研究：35% 的新創失敗因為「沒有市場需求」。AI 讓我們能更快地做出沒人要的東西。

一個典型 PM 的工作日：Notion 寫規格、ChatGPT 做腦力激盪、Figma 對原型、Jira 開票、Google Docs 寫 PRD。五個工具、五個斷裂的脈絡、零個一致性引擎。改了 JTBD，PR-FAQ 立刻過時，North Star 需要調整，MVP 範圍要重畫 — 但誰會去更新？每份文件活在自己的宇宙裡，沒有依賴圖、沒有傳播機制。

如果一個 AI Skill 能取代整個拼裝車工具鏈，一路橋接到開發交接？

Part II: 產品介紹

The Product Playbook 是一個 Claude AI Skill — 安裝在本地的結構化指令集，賦予 Claude 系統化產品規劃能力。MIT 開源、支援 6 語言、零訂閱費。

六大執行模式

22 個框架：Lenny’s Podcast 去蕪存菁

我打造這個工具的起點是一個簡單的觀察：PM 不缺框架，缺的是框架之間的連結。

我花了大量時間研究 Lenny’s Podcast — 那些集數邀請了全球最頂尖的 PM：Teresa Torres、Shreyas Doshi、Gibson Biddle、April Dunford、Marty Cagan、Richard Rumelt。我看了數百小時最頂尖 PM 的分享，發現很多框架有重疊和冗餘。於是我去蕪存菁，只留下真正驅動產品決策的 22 個，然後按產品規劃的邏輯順序系統化連結 — 每個框架的產出餵養下一個框架的輸入：

• 理解使用者：JTBD、Persona、User Journey Map、Continuous Discovery Habits、Opportunity Solution Tree
• 定義問題：April Dunford Positioning、HMW
• 解法設計：Working Backwards / PR-FAQ、Pre-mortem、GEM Model、RICE Scoring、MVP Definition
• 策略：Strategy Blocks、Good Strategy Kernel、DHM Model、Empowered Teams
• 度量與交付：North Star Metric、Three-Layer Signal Metrics、Aha Moment、Four-level PMF、Sean Ellis Score、GTM Strategy

這些不是隨機拼湊的清單。它們是被實戰驗證過的方法論，由系統化的依賴關係串起來。

給誰用

Solo PM、indie hacker、startup founder、product-oriented 工程師、一個人扛產品規劃、沒有資深 PM 可以請教的人。

The Product Playbook 就是你的 AI 資深 PM 教練。

Part III: 核心差異化 — TOP 5

這些不是 nice to have，是讓 The Product Playbook 和所有其他工具有根本差異的能力。

1. Change Propagation Engine（變更傳播引擎）

你改了 JTBD，然後呢？在 Notion 和 Google Docs 的世界裡，沒人記得所有依賴關係。The Product Playbook 知道。當你修改任何上游步驟，系統根據完整的依賴圖自動標記所有受影響的下游產出：

修改 Persona / JTBD → 標記：HMW、Positioning、PR-FAQ、North Star、產品規格摘要
修改 PR-FAQ / 解法 → 標記：Pre-mortem、GEM/RICE、MVP、Aha Moment、產品規格摘要
修改 MVP           → 標記：User Story、DB Schema、產品規格摘要

不是全部自動改寫，而是告訴你「這些地方因為上游變更可能需要調整」，讓你做決定。這一個功能就值得整個 Skill 的存在。沒有其他 PM 工具有依賴圖。

2. Dev Handoff Package（開發交接包）

PM 和工程之間的交接不再是「把文件丟過牆」。一個指令生成工程師可以直接開工的結構化開發包：CLAUDE.md（Claude Code 專案上下文）、TASKS.md（分階段交付）、TICKETS.md（Jira/Linear 格式票單）、ARCHITECTURE.md（DB Schema + API + 目錄結構）、PRD.md。安全性內建：OWASP Top 10 清單、.gitignore 範本、認證/CORS/CSP 架構。

3. Quality Hard Gates（品質硬閘門）

每個步驟完成後，AI 執行品質自我審查。

硬規則：至少一項必須標記為失敗。

如果全部通過，系統必須主動指出最薄弱的環節。為什麼？因為沒有這條規則，AI 每次都說「看起來不錯！」 — 就像不敢說實話的 junior PM。Benchmark 中，沒有 Skill 的 Claude 從不批評自己的產出，通過率 0%。

4. Codebase-Aware Planning（程式碼感知規劃）

在現有專案中啟動，系統自動掃描 package.json、schema.sql、api/routes/ 等檔案，偵測技術棧。Pre-mortem 風險不是假設性的「可能有效能問題」，而是「你的 PostgreSQL schema 缺少這個索引」。MVP 範圍引用你的實際模組。開發交接是增量式的，不是 greenfield。產品規劃和技術現實在同一個流程中結合。

5. Decision Consistency Check（決策一致性檢查）

產出最終文件前，系統執行跨步驟驗證。
你的 JTBD 說目標是 freelancer，但 PR-FAQ 在講 agency ，系統抓到矛盾。

PR-FAQ 承諾了「自動生成報告」，但 MVP 把它放在「不做清單」，系統浮出問題。

多數 PM 不是故意讓文件不一致，是在長時間規劃中沒有系統在做交叉檢查。

Part IV: Benchmark 實證

說了這麼多，有效嗎？讓數據來說話。

測試套件（開源在 evals/ 目錄）：9 個測試情境、49 項期望值、同一個 Claude 模型、唯一變數是 Skill 是否安裝。

整體：100% vs. ~27%，三項 +100%
差距代表沒有 Skill 時根本不存在的能力。 不是做得不好，是完全沒有。Skill 不是拐杖 — 它是 GPS 和「我覺得應該左轉」的差別。

Part V: 競品比較

市場上的工具分三類：
1. 廣而淺（Lenny’s 86 個 skill、Dean 46 個，但彼此獨立，沒有連貫工作流）
2. 深而窄（ChatPRD 做 PRD 很好，但不做 JTBD、Pre-mortem、開發交接）
3. 通用型（Notion AI 不知道什麼是 PR-FAQ 格式）。

The Product Playbook 佔據獨特位置：深度 + 連貫 + 整合。

公正地說，ChatPRD 贏在團隊協作，Lenny’s Skills 贏在主題廣度。沒有工具在每個面向都最好，選擇取決於你最需要什麼。

Part VI: 開始使用

步驟 1：安裝

npx product-playbook

步驟 2：打開 Claude Code，輸入：

我想做一個產品

步驟 3：跟隨引導流程。 選擇模式、描述產品、讓系統逐步引導你。

快速模式 30 分鐘有方向，完整模式一個下午有完整企劃。

給 indie hacker：30 分鐘驗證你的想法值不值得投入一個週末。
給 PM：22 個框架系統化連結，Change Propagation Engine 確保整個企劃保持一致。
給工程主管：直接在你的程式碼上做產品規劃，產出工程團隊可以立刻開工的交接包。

⭐ GitHub: github.com/kaminoikari/product-playbook

📦 立即安裝: npx product-playbook

The Product Playbook 以 MIT 授權開源。由 Charles Chen 打造。

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司/產品經理相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

以台灣就業市場為例，由於許多開職缺需求的公司單位不見得了解這兩者的差異，而統稱叫做「產品經理」，造成許多求職者對該職位產生錯誤期待。

因而我建議理解跟認識到職務內容最精準的方式，建議不要看職位名稱，而是要先好好釐清職缺敘述的內容(Job Description)。

以軟體產業的產品經理職缺為例，以下是從人力銀行找到真實的Job Description，大家覺得以下這三間公司哪一個才是真正在做產品經理的事情？

A公司

B公司

C公司

我的答案只有一個，C公司。

那為什麼會有這樣的解讀呢？

就以業界現況來看，PM 的職稱及實際負責的業務範圍，通常會依照各家公司的產業、文化、制度而有所不同，有的公司和前輩甚至認為產品經理及專案經理在做的事情已經很難區分了。

但我不這麼認為，因為兩者的核心目標不同。

根據Marty Cagan早在2007年於SVPG發佈的文章《Product Management vs. Project Management》，有以下的不同之處：

1. 目標不同：

• 產品管理：專注於確保產品能夠解決市場需求，創造價值並達到商業目標。產品經理需要了解市場、用戶需求、競爭態勢，並決定產品策略和路線圖。
• 專案管理：專注於確保專案能夠按時、在預算內且符合規格地完成。專案經理負責專案的計劃、執行、監控和完成，確保專案的每個階段順利進行。

2. 時間範疇不同：

• Product Management 是持續的，產品經理的工作隨著產品的生命週期一直進行，從產品概念到產品下市。
• Project Management是有終點的，專案經理的工作從專案開始到專案結束，然後再接續開啟下一個專案。

為什麼人們會搞混這兩者

• 角色名稱相似：兩者的名稱都包含“管理”，而且在實際工作中也都有管理和協調的職責。
• 工作重疊及缺乏明確定義：在現今許多組織中，產品經理和專案經理的工作範圍會有所重疊，例如在產品開發過程中，若由產品經理負責專案的計劃、執行、監控和完成，其實就表示需要同時兼任專案經理的工作範疇。

比較兩者的Focus以及成功的定義 (Success Metrics)

再回來重新看看上面這三家公司產品經理職務內容，我之所以認為只有C公司符合產品經理定義的主要原因有三個：

1. 前兩間公司的產品經理只執行Product Execution，沒有Product Discovery (另一種說法是完全沒有或幾乎不研究Problem Space)

2. C公司的產品經理需要挖掘商業機會、提出解決方案，同時也須兼顧定義產品的成功指標和後續數據監控，從中推論需對產品成敗負一定責任; 而A和B公司無法從JD明確看得出來。

3. 從Keyword得知產品經理工作驅動力是主動型還是被動型：

• A公司「被分配的功能/需求」=> 被動執行
• B公司「執行產品需求專案」=> 被動執行
• C公司「提出最佳產品解決方案」、「規劃產品Roadmap」=> 需自主發動

不知道看到這邊，大家是否對於如何分辨真・產品經理的JD有更深刻了解了嗎？

必須得說現在大多數產品經理的工作多少都需要混雜一些專案管理的責任，而最大的問題出在產品和專案work的比例是否有達到平衡？你想要產品work多一點還是專案work多一點？你的技能樹想要怎麼點？這些都是想做產品相關工作需要考慮的地方。

若想做100% Product Discovery，那其實像策略部、總經理特助、行銷部門、甚至往Data Team發展都很適合; 想要無腦100% Product Execution絕對就是往專案經理走準沒錯。

在沒有專案經理控專案細節的情況下，我認為保有50% Product Discovery，50% Product Execution的比例還算合理。

若公司另有專案經理負責監控專案進度的話，那我認為70% Product Discovery，30% Product Execution為黃金比例。

若以台灣企業來看，我認為公司願意給10~20%的工作loading給Problem Space/Product Discovery就已經很不錯了。

希望這篇文章有解答一些常見盲點和台灣工作現況，幫助大家找到自己心儀的PM工作，而不是等到進了公司才發現跟自己原本想像不同而後悔。

相較而言，海外的產品開發環境比較成熟，如果你是非常嚮往”Real Product manager”的職涯發展，這邊分享來自Jorge Mazal (former CPO of Duolingo)的文章 “How Duolingo reignited user growth”，詳細介紹了Duolingo 當年產品團隊歷經了哪些關鍵產品決策、失敗和試驗，最終達成350% hypergrowth in DAU，絕對不是只有寫規格、開backlog、控專案時程等工作內容而已。

不知道大家對於產品經理求職有沒有其他想法或經驗呢？有的話歡迎在下面留言與大家分享！

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司/產品經理相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

1. 管理層願意向下賦權
2. 資訊公開透明
3. 徹底坦率的公司文化
4. 員工素質要高，工作動機和能力本身要夠強

我認為同時具備以上四者的企業有較高的機率可以成功地將OKR套用在公司的目標制度當中，並且能夠明顯感受到相較於傳統KPI，OKR幫助公司業務提升的程度到底有多大。

我的公司該用OKR 還是 KPI?

我們知道，現在幾乎大部分的公司都在實行 KPI（Key Performance Indicators，關鍵績效指標）制度，這種制度之所以普遍流行自然是因為它有效果，那為什麼我們還要去試驗新的管理模式呢？

如上所述，OKR 被廣泛應用於各大跨國企業如Google, Twitter, Microsoft, Amazon, Linkedin…etc，一定有它的道理。

KPI 與 OKR 之間有一個最明顯的差異，就是 KPI 是 “別人要我們做的事”，就很像你的老闆分配給你的任務、指標、命令等，是一種被動的行為學習模式。

但 OKR 是 “我們自己想做的事”，是我們主動去實行或學習的行為。

OKR 和 KPI 最大的差別在於：

OKR 是由下而上，由團隊自行擬定目標與做法，再與上級討論，確保每個人的目標與公司目標一致。

KPI 是由上而下，由上級設定好目標，交派下去給團隊成員，重視最後的結果。

其實 KPI 與 OKR 之間並沒有任何衝突，OKR 可以讓團隊與個人的目標更明確，而 KPI 就能直接用於判斷結果成效，若兩者應用得好會有相輔相成的效用。

OKR 到底有哪些優勢呢？

優勢 #1：聚焦（FOCUS）

由於我們在制定目標時總會不自覺地想到太遠、太多，因此在設置 OKR 時，一般建議目標少於三個，關鍵結果則不多於五個，我們需要通過這種自限性來聚焦需關注事物的數量。

在 OKR 中，我們要重點關注實踐的時間週期，如三個月、六個月、一年等，時間限制使得 OKR 不同於其他目標設定系統，因為它可以隨時視情況來調整方針，這樣更有利於關鍵成果的達成。

優勢 #2：一致性（ALIGNMENT）

OKR 可以明確企業與員工 “到底要做什麼事” 的目標，避免無用功，也不再是紙上談兵的空想，而是將每個人的日常工作與企業的終極願景相互聯繫。

由此一來，大家為之努力與前進的方向是一致的，使得團隊得以發揮合作精神，進而取得更高的成就或績效。

優勢 #3：當責（ACCOUNTABILITY）

OKR 不同於 KPI 就是因為 KPI 是固定不變的績效指標，不是每個人都一定能達到或完成，但 OKR 是大家考量每個人各自的能力後所作出的目標設定，期間還能通過調整時間週期與資源分配來確保承諾可以兌現。

每個團隊成員都在互相發出明確努力的信號，所以企業不再是傳統的上對下模式，大家都處於一個平等的位置，這種一致性與透明性就為公司的長遠發展奠定了基礎。

優勢 #4：透明度（TRANSPARENCY）

OKR將資訊透明視為與企業戰略重要性相同，這就是為什麼透明度是OKR方法的一個重要組成部分。 透明度使組織中的每個人都知道為什麼主管會做出這樣的決定，公司正在努力實現什麼，以及工作夥伴正在努力做什麼。

當你了解公司頂層目標時，你可以更清楚地知道設立怎樣的個人目標可以幫助公司達成願景。透明度確保大家都在共同的道路上，同時也可以確認過程中沒有人落後，達到一種督促前進的效果。

優勢 #5：參與（ENGAGEMENT）

OKRs結合了一致性、聚焦、當責和透明度，以推動對現代工作場所至關重要的結果 — — 參與。 憑藉自下而上和雙向目標設定的決策民主化的力量，OKR方法使員工能夠全力以赴地參與這個過程。 OKR強化了員工與公司之間的關係，同時讓大家看到他們的工作如何影響個人、部門和公司目標的進步。

大家必須得記住一件非常重要的事情，OKR重視「由下至上」及「雙向目標設定」的力量。

也就是說，如果今天一家公司說他們引進或開始使用了OKR，卻只是單方面設定公司目標，連帶也幫你決定好個人或部門的KR，這其實只是一般傳統的KPI制度，絕對不是在執行OKR。

接著回來第一個問題：我的公司該用OKR 還是 KPI?

可以先觀察公司是否具備以下四種條件：

1. 管理層願意向下賦權

這項其實也是最重要的條件，若向下賦權做不到，表示員工無法自己制定自己的OKR，那也不用往下繼續討論。

什麼是向下賦權？

最簡單的解讀方式可以看一線員工自己是否有決策權和行動權 ，不需經過主管或層層批准。

值得注意的是員工獲得賦權不代表不用回報，回報進度給主管是賦權管理重要的一環，主管也能確保員工在執行工作過程中不會偏離軌道。

2. 資訊公開透明

OKR其中一項非常明顯的優勢就是資訊透明度，這邊指的並不是任何公司內部機密都可以公開揭露給員工，而是在公司戰略面、當前及未來重視的商業目標要能夠清晰地傳達給一線員工，最好是由CEO或公司負責人親自向大家說明。

但也必須強調，不是說公司有每季舉辦的 Townhall 或 All-Hands Meeting 就表示資訊透明度是足夠的。

舉例來說，如果高層向員工傳達的資訊是公司年度目標要focus在衝會員人數，但實際執行的卻是集中在提升營收的專案，一線員工反而是無法理解的，所以正確的目標對齊也是非常重要的。

3. 徹底坦率的公司文化

相信很多人都有聽或看過“徹底坦率”這本書，我私心覺得只要是主管都應該去詳讀的一本經典，內容我就不再贅述。

這裡的重點在於要先有員工與主管雙向信任的公司文化，才能減少在執行面上的內部溝通成本。

OKR在初期推行時一定會有非常多的變數導致最終失敗，藉由營造徹底坦率的公司風氣培養員工和主管彼此之間的信任感，是非常重要的。

當然如果有其他更好的方式可以創造信任感，不一定要採取這個approach，但這方式就我所知是最高效也是成本最低的做法。

4. 員工素質要高，工作動機和能力本身要夠強

最後一項，決定OKR是否能夠永續發展作為公司長期目標設定，並有效取代KPI的關鍵因素。

OKR 嚴格來說較適合西方文化使用，東方文化沒有那麼適合，原因是，東方教育比較習慣 Top down（由上而下），從小都是父母、老師告訴我們要做什麼，而不是我們自己想做什麼。

另外若組織已經超過幾萬人，因為沒有 Top down（由上而下）的明確指令，每個人根據大方向在做事，常常造成分工不明確的問題，加上員工人數多，素質也有高有低，每個人對於 OKR 的理解跟使用能力都有落差，造成內部要花很多時間溝通同一件事卻有不同的團隊都在做，讓大家花更多的時間去溝通跟整合，造成組織的不效率。

許多公司執行 OKR 數個月到數年，最後還是回頭使用 KPI 的最主要原因就是忽視人才是最重要的關鍵，如果人員的素質不夠高，OKR 會是一場災難。

舉例來說，員工自己訂定 OKR，有些員工根本設不出來，或是設定的目標不切實際，這時候主管就要花很多時間溝通。執行過程中如果員工偏離了原本的目標，主管還要趕快把他引導回來，管理成本太高了。

原本可以將人力、時間資源投入在產品或專案，卻只能多花時間在內部管理，反而阻礙了公司發展。

如果以上四種條件都未達成，不用多想，乖乖繼續使用KPI。

如果以上四種條件達成 1~3 項，時機尚未成熟，或許公司level可以先導入OKR的概念，部門及個人仍採取KPI制度會比較適合，但距離完全體仍有很長一段路要走。

如果以上四種條件全數達成，恭喜你，導入OKR可以幫助你或公司成就卓越。

OKR 要怎麽寫？

雖然 OKR 鼓勵我們跳出舒適圈去挑戰一些自己能力方位之外的事，但不代表是讓我們去做不可實現的事。

依照個人經驗，Objectives 一般會抓正常可以做到的程度往上加30%。以公司獲利程度來舉例，如果公司今年預計Q4營收為一億，那可以試試將目標營收設為一億三千萬。

OKR的Objectives可被視為”Stretch Goal”或”Moonshots”，設立的目標需要可以突破團隊能力極限，同時保持在可能性的範圍內。

另外OKR強調 “聚焦”，通過目標數量與時間週期自限，工作重點才不會跑偏，我們也能走在正確的道路上。

最後 Objectives 的設定需要與企業的商業策略、願景、或使命有密切的關聯性。

什麼是Key Results?

OKR的Key Results是衡量實現目標進度的量化指標。 Key Results將目標分解為有形的Milestones，並具體定義要實現的結果。

出於這個原因，Key Results一定要有數字，這樣才能明確地回答它是否實現了。 Key Results也充當當責機制，特別是對於時間長且可能容易離軌的目標。

對於每個OKR目標，通常會分配3–5個Key Results。

在制定 OKR 時，第一步是要釐清目標公司整體的目標 (O)。這些會是需要公司內不同部門與團隊間合作才能完成的大方向策略性目標。

再來，各個部門也應該各自存在 3–5 個目標 (O)，太多可能會造成失焦而無法專注在完成真正重要的目標上。如下圖所示，完成設置後各個不同部門都應該有各自的 OKR。

依照個人過往經驗，我認為一家公司要從傳統KPI制度轉變至OKR，能夠最快落地的設定方式是先”Top down”，再”Bottom Up”。

可參考以下季度OKR 設定範例：

步驟1: 先從公司 level OKR出發，且在2023 Q3結束前設定好下一個季度的OKR。

Objective: 2023 Q4推出成功的產品

Key Result 1: 2023年底總註冊人數達到10萬人

Key Result 2: ARR金額達1000萬

Key Result 3: MAU的留存率至少50%

步驟2: 各個部門可以各自依據公司level OKR的Key Results去設定部門level的OKR

以下僅以產品部門為例：

Objective: 2023年底總註冊人數達到10萬人

Key Result 1: 提高每月註冊率至少10％，以確保每月新增用戶數量增加。

Key Result 2: 提升用戶參與度，使每月活躍用戶數達到5萬人。

Key Result 3: 開發並推出至少兩項新功能以吸引用戶加入

步驟3: 個人 level OKR從Bottom Up角度設計以對焦部門 Objectives & Key Results

職位：Product Manager

Objective: 開發並推出至少兩項新功能以吸引用戶加入

Key Result 1: 2023年9月底前完成新功能的市場調查和競爭分析，以確定至少兩個有吸引力的功能點子。

Key Result 2: 在2023 10月底前，成功開發並上線兩個新功能，並獲得至少5,000名用戶的使用反饋。

Key Result 3: 在新功能推出後的30天內，觀察並分析用戶反饋，以確保至少10%的用戶參與並開始使用這些新功能。

每間公司可依據自身風格和習慣去做調整，只要大家有共識且有量化數字基礎，沒有一定要怎麼寫才是對的。

而初期對於每個員工最難理解的地方在於要“如何”自己制定自己的 OKR。所以主管必須要很清楚傳達一個概念：我們設定 OKR 的目的不在於你要完全 100% 達成，而是要學會為自己的成長負責。知道自己還需要加強哪些部分，以設定相對應的目標。

不知道大家對於OKR落地以及目標設定有沒有其他想法或經驗呢？有的話歡迎在下面留言與大家分享！

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司/產品經理相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

對於產品經理來說，始終面臨的問題是，要做什麼產品？

這個問題在剛轉職時常常讓我徹夜難眠，思考著：“我規劃出來的東西是否正確？我該如何傳遞這個功能或產品的價值？”

我一直認為Product Discovery是 PM 成功的關鍵。

正如大家應該都聽到爛掉的Albert Einstine名言：“如果我只有一小時的時間來拯救世界，我會花五十五分鐘來定義問題，然後只用五分鐘來找到解決方案。”

作為一名 PM，理想情況下我希望可以花 60% 的時間來探索要打造什麼產品，20% 的時間幫助RD交付，20% 的時間提供跨部門協助。

我認為日常的產品管理有3個關鍵方面：

1. Discovery — — 探索要打造什麼產品、思考可優化和迭代的地方
2. Delivery — — 與RD合作交付產品和功能、Debugging
3. Enablement — — 與各部門合作確保價值有成功被交付

儘管Product Discovery是產品經理最重要的工作之一，但實務上，產品經理無意識地在Product Delivery 上花費了更多時間，而在Discovery上花費了更少的時間，這最終會影響公司。

對於一般人來說，有形或可被觀測的事物在世界上總是顯得特別重要，而我們卻忘記了無形的事物，軟體產業也不例外。

我們不關注無形事物例如機會成本、顧客口碑、決策品質、Lesson Learned等等的重要性。在這種情況下，軟體或產品的交付變得有形，而產品探索流程則變得無關緊要。

舉Amazon的一個例子：Amazon於 2014 年推出了 Amazon Fire Phone，但很快意識到自己完全無法與 iPhone 或Samsung Galaxy 競爭，很快地於次年停產。

這是一次商業上的重大失敗，在這種情況下，Amazon並沒有做好產品探索，他們推出這款產品單單只是為了與蘋果競爭，並期望能佔領一定的市場份額。如果亞馬遜能夠驗證這個問題，他們就可以輕鬆避免這次失敗。不過這次他們並沒有投入任何精力在problem space，他們參考了競爭對手的解決方案，並只專注於完成交付以盡快在市場上推出產品。

想作為一名成功的產品經理，重點應放在如何在交付產品之前就能獲得足夠的洞見，以便可以提前了解客戶問題並且對提出的解決方案更有自信。

沒有人願意花費數年或數月的時間來製作一款產品，結果最後發現沒有人想要使用它。

幾乎所有成功的產品團隊都特別強調Discovery，從最一開始他們就充分理解它的重要性，產品探索的目標一直都是快速學習和理解: 這個Solution是否滿足了用戶需求、是否為公司業務帶來了正確的結果、以及是否以正確的順序解決了問題？

(如果大家知道有哪家公司完全不在乎他們要解決什麼問題並且只專注在把產品做出來，最後還能成為市場領導者的實際案例，歡迎底下留言讓我知道)

最後，正如 Marty Cagan 在《INSPIRED》一書中所強調的那樣，“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build。

“Product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.”

― Marty Cagan

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司/產品經理相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

一眨眼離上次寫blog又過了3個月，這段期間經歷了無數對我個人很重大的事件：決定改轉職為產品經理、修改履歷、瘋狂面試、惡補許多PM技能樹還缺乏的技能、一直到成功拿到還不錯的新公司offer。 （之後有時間會再補上為何會決定選擇當PM以及從6月到8月這兩個月近30家科技公司的面試心得）

在即將入職滿一個月前夕以及趁颱風來臨前趕快來補一下反思系列 XD

在台灣對許多人來說，領導力等同於權威，尤其是在傳統產業的觀念中，老闆或直屬主管手握生殺大權，無論個人意願喜不喜歡或願不願意，不照著做很有可能就意味著失去了飯碗。

但真正領導力遠不僅僅只是權威。這種類型的領導或許可以產生短期的結果。但從長遠來看，它不會幫助領導者取得同事或下屬的信任和尊重。

從長遠來看，往往被公司老闆或高層忽略的同儕影響力其實更重要。

就我個人觀點，我認為兩者都是創造高效領導力缺一不可的特質。

但歸根結底，擁有authority和influence有什麼區別？讓我們探討它們有何不同，以及如何學會在職場中建立自己的影響力而不是僅僅依靠權威策略。

首先，讓我們分解什麼定義了權威和什麼定義了影響力。

什麼是權威？

簡單來說，權威是任何人從職位或地位中自然獲得的合法性力量，擁有足以強加於人的意志或讓別人按照你想要的方式行事的能力。

人們可能不認為你是對的，或者相信你所做的事情。但是，他們會照實執行，因為他們相信如果不這樣做，會遭受懲罰，或者如果他們這樣做，就會得到回報。

例如，假設你有權決定誰加薪、誰被開除，員工很有可能會聽從你任何的要求或命令，因為他們想賺更多錢或保住飯碗。

什麼是影響力？

影響力是一種基於說服而不是權威來改變他人行為或思維方式的能力。

與權威不同，影響力不允許僅通過命令做某事來直接影響某人的行為或想法。

相反地，影響力是透過利用個人技能或特質影響他人改變他們的行為、思考或行為方式，例如像是說服、啟發等方式。

人際關係也會對影響力產生影響。當你與同齡人建立基於信任的積極正向關係時，你的行為和想法更有可能影響這些人。

權威和影響力有什麼區別？

權威和影響力都可以幫助您改變其他人的行為和想法。然而，他們這樣做的方式截然不同。

權威使用強迫性手段說服某人執行某項行動。然而，當你使用影響力影響某人做某件事時，他通常不會感到有壓力或被迫做任何事情。影響力不是鐵腕統治，更多的是在決策過程中用引導的方式促成行為或想法的改變。

通常一般員工傾向怨恨權威或僅僅因為“不得不”而感到自己違背自己的信念行事時，對企業來說這往往會造成各種負面影響。

另一方面，影響力可以幫助提高員工在組織中的retention。當人們受到積極影響時，他們會覺得自己正在以他們認為正確的方式行事。

為什麼應該要同時掌握權威和影響力？

基本上掌握權威的重要性毋庸置疑，而建立影響力需要大量時間和比獲得權威需要更多努力，但研究數據指出這是值得的。

只有 44% 的人力資源專業人士認為員工在工作中付出了可自由支配的努力，而不僅僅只是完成JD本身要求的工作內容。可自由支配的努力是員工額外付出，權威本身很少能激勵員工做出這種自由裁量的努力。

此外， 71% 的領導者高度重視提高員工的敬業度。但是，出於權威壓力而採取某種方式行事的員工不一定會參與這些行動。

當團隊的表現只是由外部力量（權威）驅動，他們不會自發地付出不必要的努力。

另一方面，當有同儕對如何執行一項任務有發言權時，他們就可以開始發展對該任務或項目的所有權。這種所有權可以發展為提升更多人的參與度。

他們會看到表現更好的理由，因為他們知道自己有能力讓事情變得更好。

以下是主管和團隊可以從建立影響力取得的優點：

• 影響力是持久的，即使沒有恐懼或權威來源，也會繼續產生影響。
• 過度依賴權威會吸引志同道合的人，過度同質化的團隊會失去彈性並且造成效率低落。 多元化的團隊將產生更多不同的想法 ，並有助於提高整個團隊的解決問題的能力。

當您需要立即採取行動時，單獨使用權力可能在短期內效果很好。然而，影響力往往是一種更積極、更持久的動力。

使用權威和影響力做決策的差別

場景一：週末需要做額外的工作

權威： 使用強制且合法的權力，你選擇兩位下屬並告訴他們這週末需要進公司加班，否則不只他們考績會受影響、而且還指責他們不合群、沒有團隊精神。

影響： 你決定以身作則，自願在這週末自己進公司加班。你也可以用說服的方式來解釋為什麼在這週末加班對目前專案產生的幫助並使團隊工作更愉快。

場景 2：在一個特別困難的專案中團隊士氣低落，且進度延遲

權威： 你決定舉辦一個下午茶派對來鼓舞團隊士氣，但前提是你的團隊能在deadline結束前完成預設的milestone。

影響力： 不是通過無關的獎勵，而是通過在專案中提供適當幫助，例如提供建設性的意見，說明如果是你的話將會如何做，​​並詢問他們認為下一步應該做什麼。

場景 3：團隊在過去幾週表現不佳

權威： 你與團隊成員做一對一談話並告訴他們他們表現需要加強，否則你必須把他們列入PIP。

影響：與其譴責他們，不如問你可以做什麼來協助他們表現更好。讓他們知道他們對團隊很重要，每個人都依賴他們取得成功。

通過平衡權力和影響力成為積極的領導者

權威是將自己的意志強加於他人的能力，而影響力則是深刻影響行為和信念的能力。

作為領導者，需要不時使用權威的力量來駕駛這艘船。但是當你用影響力來領導時，你會與你的團隊建立更深的信任和忠誠度。

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

這篇想跟大家分享一下我的畢業專案心路歷程，我最早從 2019 年 10 月開始 AC 學期一的課程，到現在 2022 年 6月，終於走到了這個階段，過程比大多數學員來得更加艱辛。

因為當初是有正職的狀態下邊學習，到學期二時剛好升任為主管，工作量暴增後便中斷了學業。這樣一中斷就過了2年，一直到了2022年2月底離職後才能好好全職上課，學習的時間比自己最初預想的久了許多。

為何要轉職

在即將畢業時免不了要回想一下初衷，一開始會加入AC算是靠著一股衝動，在之前的部落格有簡單分享過想轉職的原因，過了2年半後算是對自己有了更深的認識，基本上除了想要擁有一技之長、追求更好的生活品質之外，最大的原因是因為我・不・喜・歡！

我不排斥跟人頻繁地交流溝通，但我不喜歡我工作的內容、不喜歡R&D或技術主管常以「因為你不是理工科出身」、「沒有冒犯的意思，但是你不懂技術」等原因來作為敷衍或搪塞的藉口、不喜歡專業不被尊重的感覺。我想要真正的用技術說話，不是靠辦公室政治去達到我的目的。最後經過工程師同事幫忙篩選數個不同課程後，就決定加入AC囉～

加入AC後的轉變

從學期一到學期三，AC一直不斷傳遞一個很重要觀念給我們，那就是不要只把問題丟出來等別人接球，要自己先理解問題、動手摸索嘗試並且盡可能有條理地論述問題。

課程不僅僅只是培養我們工程師所應具備的技能，更是訓練我們如何具備真正工程師的思維，在訓練過程中很多時候在想辦法描述問題就找到問題的解法了。

也正是因為這樣，有許多作業的要求都是要用我們自己能夠理解的語言來解釋某個程式概念，就像Richard Feynman曾說過的名言：

如果你不能向其他人簡單地解釋一件事，那麼你就是還沒有真正弄懂它。

從學期一或學期二不知道自己在寫什麼、漫無目的地解決問題，一直到後來學會不要立即開始動手幹活，要讓大腦有充分的時間分析問題，並對訊息進行整合。

然後開始懂得如何除錯、逐步嘗試不同的解決方案，花時間把自己腦袋的東西抽離，退一步從另一個角度看問題，看是否有任何東西可以抽象為更一般的方法，或者乾脆從頭來過，刪除所有內容，然後重新開始。

學期三作為 AC 最後一個學期，真的是相當精實，尤其在 Simple Twitter 協作專案結束後，還有許多協助回顧開發過程的作業如：工具的選擇、解決問題的過程、同儕互評程式碼品質、360 Review、部落格反思等等。

這些看似繁複的文字作業，讓我可以更深入挖掘、紀錄自己在協作專案中的點點滴滴，反覆去咀嚼兩週內密集開發的每個時刻，對於內化學習的成果很有幫助；不僅僅只是完成專案的程式碼，然後網頁會動而已。

AC的畢業只是整個學習之旅的起點而已，以往都是看著教案以及影片，就算真的不懂，還有助教可以再次詢問，但未來當你需要學習一個新的東西，或是看文件等等，這都要靠自己去努力跟練習了。

最後感謝AC一路上所有幫助過我的助教、導師團隊以及同學們，不論是好的或壞的經歷都會成為我未來成長的養分，也讓我更堅定的往下一個里程碑前進。

當你成功跨越一個障礙的時候，另一個障礙出現了。生活因此而豐富多彩。

生命是一個不斷突破這些障礙的過程，我們必須突破一系列的障礙，走出一條踏實的路。

每一次，你都會學到一些東西。

每一次，你都會積蓄力量、開啟智慧並形成觀點。

每一次，壓力和競爭都會一點點消失。最後只剩下你自己：你得到了最好版本的你。

— The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph

如果喜歡這篇文章，請幫我拍手1–10下。 
如果覺得文章對你有點幫助，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

緣起
Simple Twitter 為 Alpha Camp 畢業前的一個多人協作專案，總共為期兩周的時間內實作復刻基本推特功能。

本文架構
⇢ 專案概覽
 ⇢ 團隊初期的準備工作和心得
  ⇢ 過程的經驗和省思
    ⇢ 成果紀錄和結語

專案概覽⇢

團隊成員
Frontend: Zoe Chen, 曉榆
Backend: Charles, Angela
專案連結 📘
・Live Demo Github Page
(可直接註冊新帳號 or 使用 user1@example.com / 12345678)

・Frontend Repo
・Backend Repo

・元件架構
・頁面與API資料分析

基本功能 
- 使用者能登入、登出 
- 使用者能新增推文 
- 使用者能進行互動(Reply、Following、Like) 
- 使用者能編輯個人與帳戶資訊 
- 管理者可瀏覽社群狀況(所有貼文、用戶概覽) 
- 管理者可以瀏覽站內所有的使用者清單
- 管理者可以瀏覽站內所有的使用者的資訊 (推文數、關注數、跟隨者人數、like 數)
- 管理者無法登入前台

本專案我們選擇以前後端分離的方式開發，前後端各兩位依照教案所提供的User story 與 UI / UX 設計稿進行開發，後端主要是採用 Node.js、Express 框架及 MySQL 資料庫等技術進行開發，並採取 RESTFul API 風格規劃及開發網站資料所需的 API ，前端則由其他兩位夥伴 Zoe Chen和 曉榆以 Vue.js 進行畫面開發。

個人主要負責項目

1. 建置專案初期環境
2. 規劃user、tweet、reply種子資料
3. 使用 passport-jwt、jsonwebtoken 進行使用者身分驗證
4. 使用者 CRUD 相關的 API
5. 跟隨功能、人氣排行以及跟隨清單
6. 使用 multer 實作圖片上傳功能

團隊初期的準備工作和心得⇢

在進入到Simple Twitter專案之前，幾乎所有的學習體驗、專案和小練習都是個人自行完成。

所以為了確保後續的開發流程順利，我們在專案初期將各自工作分工明確定義好，而我是負責彙整每日小組進度回報並tag助教與導師，值得一提的是我們小組在這次專案中並沒有特別指派組長或PM的角色，因為過往在前公司的專案管理和產品開發經驗都會有PO或PM在主導，這對我來說算是蠻特別的挑戰。

User Story / Acceptance Criteria/ Defintion of Done
我們採用教案提供的使用者故事，先一條一條核對是否有需要修改及刪減的項目，後續夥伴們也各自分工將使用者故事拆分成規格更明確的 Acceptance Criteria，避免開發和驗收時失焦。

DoD的部分由於先前沒有自定義的經驗，經過討論後決定採用教案提供的範例就足夠，避免設定太過嚴謹或鬆懈，影響整體專案進度。

資料庫 ERD & Entity關係整理

根據測試檔內的 Models 和 Requests，定義出 ERD 和設計出基本路由。

團隊協作工具

Discord: 團隊即時討論、開發交流和開會

Discord 上可以創建多個文字頻道，也有多個語音頻道可以進行開會溝通甚至分享螢幕。我們創建了共同的頻道以方便前端和後端進行討論。

Notion: 作業繳交、資料彙整、會議紀錄

為了方便隊友們對齊各方面的資料並快速取得共識，我創立了一個 Notion 工作區，裡面含有前後端各自需要準備的資料、會議紀錄、前後端共享的檔案以及Trello進度看板的連結。

Trello: 專案進度管理

我們專案進度管理採用 Trello 來協助管理，把版面分為前後端，再細項分為待開發、開發中、Code Review、Done等區塊，並配合TeamGantt甘特圖套件可以很清楚知道大家現在各自在做什麼，功能開發到哪一個階段，卡片還可以串接 Github、Slack（雖然這次沒有用到） ，開發上哪個功能遇到困難也可以立刻讓隊友知道。

GIT協作:

後端以Angela開的 github repo進行協作。根據當下負責的功能以feat/***為前綴命名分支在本地進行開發，完成功能推至遠端並發Pull Request 交由對方審核，審核完成先合併到 development，後續要做正式部署時再合併到master。

中間其實有遇到一點麻煩，因為一開始對該怎麼上傳分支以及整體流程的概念不是很清楚，初期雙方對於開分支的命名方式和合併後是否刪除分支並沒有為此建立共同的共識，導致遠端分支顯得有點雜亂。

另外對於處理merge衝突也沒有相關經驗，導致專案中期要嘗試merge至master做部署時，PR跳出錯誤提示：these conflicts are too complex to resolve in the web editor

Git官方只有提供兩種解法：下載Github Desktop或者使用command line解決conflict，後續採用了command line的方式暫時解決，但又引出更大的問題也就是分支太過混亂以及分支順序出現問題。

最後感謝助教Duncan提出的以下建議和解決方式才解決這個問題並且在專案中期這個階段達成團隊的Git協作流程共識。

1. 將目前的 development 改動命名為其他名稱，從 master 開出一個新的 development , 再從新 development 該出 feat 分支，將最新的檔案挑出來 commit ，push 上 github
2. 透過PR 將 feat 分支 merge 的 development , 然後再透過 PR development merge master ，這樣應該可以修正 master 目前問題。
3. 分支盡可能乾淨和保持單一功能，避免改動太多有不容易解的衝突
4. 多人開發時，盡可能有統一模式跟命名規則，例如： development 開出 feat/xxx 分支，透過 PR merge development ， 要發版時透過 PR 到 master
5. 可以多研究一下 rebase，會有助於解衝突
   https://backlog.com/git-tutorial/tw/stepup/stepup2_8.html

API規劃:

在規劃 API 時思考了該如何將所有的 API 統整，讓協作的人可以一目了然，於是參考了學長姐經驗我去利用swagger工具撰寫Simple Twitter API文件，明確定義各項路由的功能、使用方法以及回傳資料的格式並且把所有規劃中的 API 統整出一個初版API文件，可以在專案初期就先串接假資料 Mock server做測試。

後續因為專案時間較急迫以及缺乏團隊共識，雖然有完成API mock server文件，但並沒有正式將swagger UI引入此專案的程式碼當中，這是比較可惜的地方，不過對於整體文件該如何打包和下註解已有一些基本的觀念。

最後正式的API文件是以記錄在Notion的方式，讓前端方便做串接：

過程的經驗與省思⇢

1. 協作的過程中應優化自己的 coding style，並和協作夥伴統一習慣
   coding style其實在專案一開始就有討論並決定統一使用promise…then的寫法，隊友也有按照說好的風格撰寫，主要是我這邊針對部分API除錯時想說先用async await的方式可以通過自動測試，方便前端先做串接，但後續優化時忘記改回promise語法，這是我需要警惕和改進的地方。另外後端的程式碼都有經由 VS code Eslint Extention將風格統一化（單引號、不使用結尾分號、使用一致的indentation等等），保持程式碼的易讀性。
2. 從PR Review 過程，檢查並觀摩對方的程式碼
   從PR中學習和培養不同程式碼撰寫風格和思路，也從隊友提供的建議修改自己負責部分的程式碼。這個環節大概是推特專案經驗幫助自己成長的最重要要素之一。
3. PM在專案管理的重要性
   由於我們小組初期決議是不指派組長和PM，所以在實際遇到狀況時很吃每個隊友的自主性和靈活度，以及在凝聚團隊共識部分其實還有很多不足的地方。
   在小組發生些許的爭執摩擦時，較強勢的一方往往會壓過另一邊的聲音，為了保持團隊和諧以及不影響專案進度，會傾向跟著強勢的隊友意見走，個人觀點認為這樣的團隊文化不是很理想，因為以過往經驗來看這會造成組員避免被批評而不願意分享自己真實的意見和想法。
   在過去個人經歷過的專案管理或產品開發時往往是由PM來擔任團隊協調和溝通的角色，但在本次只有兩週的專案裡我們小組缺乏領導者角色，所以專案進行到尾聲時，團隊階段僅停留在風暴期就結束了，沒有磨合的非常理想，這也讓我體悟到PM以及良好團隊氛圍對專案執行可以帶來非常顯著的影響。
4. 即使是面對未知的嘗試也要保持穩定
   之前在有限時間探索階段或遇到新的工具時，程式碼品質通常會直線往下。有了這次專案經驗:每天超過12小時不間斷的嘗試和熟悉工具，發現在開始coding前有著良好規劃和構思以及好的程式碼品質才能穩定的維持輸出。
5. 從debugging過程中發現應再加強對細節的掌握度
   在這次專案最常犯的三大bug: 忘記放seeder、Postman沒放raw參數、路由/變數眼殘打錯。
   以及最慘的其中一個路由沒放authenticated導致getfollowings和getfollowers API一直無法正確顯示isFollowed狀態，花了很久嘗試不同的workaround寫法，最後才發現是路由的問題。
   這算是印象非常深刻的一次經驗，也是未來我需要省思加強對細節掌握的地方。
6. COVID-19陽性確診
   其實在專案前期就開始出現咳嗽、頭暈等不舒服的症狀，最後在Sprint #3時快篩出陽性，當下的情況並沒有辦法很好地思考以及造成debugging的效率低落，雖然這是無法預料的事情但發生在專案過程中導致表現沒有發揮到最好還是有小小遺憾。

成果小記⇢

考核結果

結語

能在AC學期的結尾完成團隊協作專案實屬難得可貴，感謝這兩週以來陪我一起奮戰的三位夥伴們，還有這段時間不斷給予鼓勵和支持的助教Duncan和AC導師團隊，是因為有大家的幫助才能在有限的時間內專注開發並於期限內完成所有指定功能，很多時候想破頭的問題往往就在神隊友的助攻下迎刃而解。

另外也深刻體會到前期準備的重要性，不論是團隊撰寫風格、小組分工、進度規劃或是規格確認都超級重要，我們大約花了4–5天在做前期準備，比起其他小組的進度來說應該有多耗費了一點時間，但在後期收尾階段就體現出前期充分準備的好處，不管是程式碼優化或除錯的部分都相對比較不會手忙腳亂。

如果喜歡這篇文章，請幫我拍手1–10下。 
如果覺得文章對你有點幫助，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

Github: https://github.com/Kaminoikari/S3A3_expense_tracker

專案連結：https://enigmatic-castle-29058.herokuapp.com/

專案簡介：

此專案提供新增、修改與刪除「支出紀錄」的功能，可以藉由登入與註冊功能來建立個人專屬的記帳本。

功能列表

• 可依類別、年份與月份搜尋
• 新增、編輯和刪除支出項目
• 可使用電子信箱註冊及登入
• 可使用 Facebook 帳號登入

專案目的

• 實作CRUD基礎資料操作功能
• 依照「使用者功能：User Story」、「Wireframe」、「規格」從零打造專案
• 驗證機制實作：建立登入、第三方驗證如Facebook登入及註冊功能

使用到的技術

• 此專案環境為Node.js，搭配Express框架來快速建立基礎架構。
• 資料庫：MongoDB (NoSQL資料庫），透過Mongoose 用物件導向語法操作MongoDB 資料庫。
• 模板引擎：express-handlebars，並搭配客製helper加強邏輯處理。
• 驗證機制：使用passport.js套件做驗證，搭配express-session記錄user在一段時間內的狀態，本專案使用了 local 以及 Facebook的驗證策略。
• 加密演算機制：使用bcryptjs套件運用雜湊演算法將使用者密碼加密，在要加密的字串中插入特定字符（加鹽），打亂原始的字符串，使其生成的散列結果產生變化，其參數越高加鹽次數多越安全相對的加密時間就越長。
• 基本html和css撰寫，搭配bootstrap, jquery及popper等函式庫。
• 透過method-override套件重構程式碼，以Restful API和關注點分離（separation of concerns，SOC）方式重新設計路由，將所有路由模組化。
• 使用Heroku和MongoDB Atlas遠端部署網頁伺服器。
• Git與GitHub版本控制

哪部分相對能掌握？哪裡花了最多時間？

較有把握：專案環境建置、基本路由設計、種子資料建立、遠端部署伺服器

花較多時間：

• view版型設定：雖然很喜歡看到美美的版面，但是實作起來真的好花時間啊，研究了很多網路上的template但結果還是決定回歸最原始純樸的感動。
• 客製helper：在檢查string(字符串)是否等同於另一個string，如果相同的話後續想做一些執行動作時，查了資料發現handlebars本身似乎無法達成，必須透過自訂helper才能執行。但對語法感到實在陌生，console一直跳出 `Missing helper: “ifEquals` 的錯誤訊息，最後靠著前人在stackoverflow的分享才解決。
• 對Promise和 async/await語法還是很不熟悉，有些路由用promise、有些用async/await顯得比較混亂，而且不確定自己是否真的有搞懂這些用法，感覺這個專案或許可以work，但要套用到別的專案可能還是要花一些時間重新研究。

碰到什麼困難？又如何克服？

• 感謝同學Angela協助幫忙抓錯，發現了很多小bug，提示文字效果有出來但是訊息關不掉，最後發現popper檔名寫錯字寫成pepper、忘記導jquery進來（使用的bootstrap為4.x版本)才導致無法關閉，有夠蠢。
• Heroku第一次部署上去出現error，心中當下一片平和，若一次就上傳成功反而才覺得奇怪（咦？），用 `heroku logs — tail` 查詢發現原來是seeder還沒讓他跑，現在看log真的是越來越有心得，跑完後順利上線。

對哪個技術有特別深刻的學習？

在思考資料庫數據之間的關聯關係時，觀摩同學作業及討論發現mongoose 有populate 的用法，雖然本專案不需要用到太過複雜的關聯邏輯，但自己想嘗試使用aggregate看看，主要是在查資料時看到這篇文章提到Avoid running a populate/$lookup on a large number of documents，若之後職場說不定也會遇到大量的動態條件查詢，熟悉一下語法也好。

基本上除了查看MDN之外，

Mongoose v6.2.10:

還參考了以下個人覺得比較容易理解的文章：

30–14之聚合(1) — -Aggregate Framework的哩哩扣扣

Day 3 — MongoDB 的 Aggregation 教學

MongoDB 聚合

最後專案再用trial & error的方式達到目的，感覺還有很多語法需要花時間消化。

接下來想鍛鍊的重點

• 對語法的理解有比之前進步，但真的需要靠重複練習來變得更熟練
• 有空想嘗試其他不同的的第三方驗證方式如Google, GitHub, Twitter..etc.
• 盡量按原本想法的順序去寫code，有時候為了趕時間一窩蜂把相同的code從上一個專案複製到下一個，資料夾也全部都先建立好，結果在routing時直接打結，還要每個檔案去看變數名稱是否都有改到，相當悲劇。
• 盡量在同一專案保持同一撰寫風格，增加可讀性和易維護性。

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

所謂的CRUD，通常指在資料庫或數據儲存的執行操作，如：

新增 Create
查看 Read
更新 Update
刪除 Delete

所謂的MVC，指的是將網頁程式架構區分為：

Model(資料邏輯)
View(視圖)
Controller(控制器)

程式碼不應該全都寫在一個單一檔案裡面，而是要根據其工作和性質移到 MVC 這三塊的對應檔案內。

Model 和 View 不會單獨運作而是配合 Controller 來提供服務。

所謂的RESTful API，指的是運用 HTTP 來表達語義的路由設計風格

RESTful 風格的網址設計強調從路由結構就能看出要對什麼資料、進行什麼操作。

狀況/緣起

當初想做的那件事是什麼？為什麼需要做這件事？

想要將專案佈署到 Heroku 上，並成功啟用網站

部署準備

最初依照AC的教案說明,操作步驟如下：

建立Heroku 帳號

1. 在官方網站上面點選「註冊 (Sign up)」並填寫個人資料。
   「職業 (Role)」我選擇了「業餘愛好者 (hobbyist) 」
   「主要開發語言 (Primary Development Language)」選擇 Node.js
2. 進行 E-mail 驗證
3. 設定完密碼，就建立好帳號了！

安裝 Heroku CLI

1. 按照Heroku CLI 的官方文件執行，由於我是使用macOS，在終端機輸入brew tap heroku/brew && brew install heroku
2. 一開始安裝就遇到了問題

3. 研究了好一陣子，原來是software版本太舊，於是使出

softwareupdate --all --install --force

sudo xcode-select --install

把作業系統Big Sur更新到11.6.4，xcode也更新到13.2.1的版本

更新完後在終端機輸入heroku ，終於成功跳出系統訊息，表示Heroku CLI已安裝成功。

在MongoDB Atlas 創建帳號

1. 官方網站建立帳號，並依序設定完成
   Organization: 取名ALPHA Camp，Cloud Service選擇MongoDB Atlas
   Project: 取名TodoList
   Cluster: 選擇Share Clusters (免費版)，Cloud Provider選地理位置最接近的可降低延遲，我選Google Cloud的台灣伺服器，Cluster Tier選M0 Sandbox (免費版)，Cluster Name因為本專案只需要開一個cluster，命名就用預設的Cluster0。
2. 選擇Connect your application，IP位置輸入0.0.0.0/0 （所有未知的主機和目的網絡，也就是允許所有IP的請求都可以連接到此cluster)

3. 創建username和password

4. Driver選Node.js，Version選擇3.6 or later，複製connection string後，MongoDB的部分即設定完成。

接下來是部署到Heroku的部分：

新增遠端應用程式伺服器

首先在 Heroku 上建立一個 app，之後才能把專案程式碼上傳到這個 app 裡。

在終端機輸入heroku create ，Heroku CLI自動幫忙生成隨機名稱。

或者也可以在 heroku create 後面指定 app 的名稱

打開 Heroku 生成的 URL，會看到在這個網址上已經有一個臨時頁面了：

這時候到heroku dashboard，也可以看到應用程式出現在列表裡。

新增遠端資料庫伺服器

接著要在 Heroku 設定與 MongoDB Atlas 的連線資訊，將先前準備好的 MongoDB Atlas 連線資訊加到 Heroku 的 MONGODB_URI 環境變數中。

進入Heroku 專案的 Settings後，點選Reveal Config Vars。

key 值輸入 MONGODB_URI

value值輸入剛剛在MongoDB複製的connection string

帳號密碼和 db 名稱自行帶入

修改專案環境設定

定義啟動腳本：Procfile

指令是在告訴 Heroku 這個專案該如何啟動。

建立 port

// app.js
// 如果在 Heroku 環境則使用 process.env.PORT
// 否則為本地環境，使用 3000 
const PORT = process.env.PORT || 3000
// 設定應用程式監聽的埠號
app.listen(PORT, () => {
  console.log(`App is running on http://localhost:${PORT}`)
})

建立Mongoose資料庫連線

// config/mongoose.js
// 如果在 Heroku 環境則使用 process.env.MONGODB_URI
// 否則為本地環境，使用 mongodb://localhost/todo-list
const MONGODB_URI = process.env.MONGODB_URI || 'mongodb://localhost/todo-list'
mongoose.connect(MONGODB_URI, { useNewUrlParser: true, useUnifiedTopology: true })

建立 Git Commit

git add .
git commit -m "chore: heroku init"

專案上傳 Heroku

先確認localhost和遠端清單是否已加入位址

git remote -v

確認沒問題後，把專案推到 heroku。

git push heroku master

Heroku 開始一連串的初始化流程，要等待指令全部跑完。

用以下指令打開網站，看看是否成功

heroku open

專案上傳失敗

定義問題

初步判斷問題可能是出在code有錯字，或者MongoDB資料庫哪裡設定有誤。

尋找與嘗試

打開 Heroku 上的 console 來查看伺服器紀錄 (server log)

heroku logs --tail

當下看不出一個所以然，所以回去看code跟資料庫設定。

發現key值原本應該要填MONGODB_URI，但手滑寫成MONGODB_URL，不知道有沒有影響，但順手修正。

發現以下語法沒有改到：

app.listen(3000, () => {
  console.log(‘App is running on http://localhost:3000')
})

應該要改寫為：

app.listen(PORT, () => {
  console.log(`App is running on http://localhost:${PORT}`)
})

另外還有確認連接資料庫伺服器的value欄位如密碼前後不需要<>、重新設定git遠端資料庫位置等等…etc.

確認code全部都已修正，並且資料庫設定正確後，重新將專案推到heroku看看，但最後仍跳出application error的畫面。

掌握關鍵，撥雲見月

此時因為大概已花了兩小時在debugging上，決定刪掉heroku，重新建立新網址。

git remote rm heroku

手動新增app名稱為todolist-alpha

這邊重新試著push專案看看，結果莫名其妙成功了？！！！

把本地種子資料(seeder)帶進去

heroku run npm run seed

最後用heroku open打開瀏覽器，看看呈現的畫面如何：

回顧與發現

在抓錯過程中有發現到不少bug，很多都是語法的一些細節或者typo的部分，感覺自己細心程度還可以再加強。

下次若再遇到類似抓不到問題點的情況，會比較果斷地直接重新跑一次流程，順便加強對於流程的掌握度。

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！

這系列計劃會寫三篇文章，如果寫到一半有想到更多主題再追加囉。

美國蘭德公司決策執行顧問馬利奧曾說：

「世界上每1000家倒閉的企業當中，85%是因為企業決策者決策不慎造成的。一人一事繫於整體，每招每策關乎全局。」

談到組織少不了人的因素，本篇主要探討組織策略通常是如何被決策圈的認知偏誤影響而導致失敗。

再往下討論之前，以下幾個並非認知偏誤相關影響決策失敗的因素，本篇文章不會多做探討：

1. 並非所有決策錯誤都源自偏誤，還有無能、輕率和欺騙等因素
2. 人並非絕對理性而是有限理性，因此決策者天生厭惡風險，傾向選擇現有的可行方案中風險較小、足夠滿意的方案
3. 大部分決策者會根據資源、時間等限制只求滿意或足夠好結果，而非最佳解

大多數的決策失敗不代表企業會馬上破產倒閉，畢竟產品本身若客群市場夠大、product life cycle尚未進入衰退階段、產品線還很完整，多半還能夠撐好一段日子，短期內業績基本上不一定會表現出任何衰退跡象（甚至可能還會正成長）。

這種情況表面上看不出來，一切都和平常沒什麼兩樣，這就像慢性中毒一般會不知不覺侵入到骨髓，等到開始出現明顯症狀時就像癌症末期，已經很難再扭轉回來。

其實網路上或書局隨便找都可以翻到為何會失敗的相關文章，每篇看似理由不同，但基本上殊路同歸，這邊簡單列出幾個原因如下：

1. 只從最近的經驗學習 (假設最近發生的事，是對未來最準確的預測指標，而更早之前發生的事，是相對不重要或不相關的)
2. 過度依賴成功的公式 (公式謬誤、認為模式是可複製的…etc. )
3. 錯誤解讀或疏遠顧客 (忽略核心客群、以為自己就是顧客…etc.)
4. 被某種狂熱所害 (成功之後的傲慢自滿、不知節制、罔顧危險…etc.)
5. 無法順應產業結構的轉變 (技術變革、破壞式創新、創新者窘境…etc.)
6. 在實體或情感上與公司經營疏遠 (只看報表，不關心員工…etc.)
7. 企業的重大戰略、經營決策、內部治理出現問題 (關鍵決策失誤、盲目多元化導致財務惡化、過度追求短期利潤，盲目擴大規模，管理失控、產品品質下降、管理層矛盾…etc.)
8. 價值觀偏離正道 (財務造假、貪污腐敗…etc.)

再來認識一下什麼是認知偏誤？

簡單來說指的是人們以主觀感受而非客觀資訊，而對他人作出判斷，從而出現判斷失誤或判斷本身與判斷對象的真實情況不相符合的錯誤。

不查還好，一查列表發現「天阿！也太多不同類型的偏差」，人類大腦真的不可信，有興趣的人可以自己上去wikipedia 查看看😂

如果要我用一句話來形容，可能是這樣：『我以為你以為的跟你以為我以為的認知相同，但這不是事實』

再回過頭來比對以上企業或組織失敗的原因，Wow! 似乎一切都能解釋了。

1. 我很了解客戶的需求，所以我們應該出這樣規格的產品！

2. 我和各部門主管已經充分溝通過了，我相信這個案子一定沒問題！

3. PVT時程已經delay，以往產品研發沒出過什麼太大問題，這次縮短測試時間我覺得ok，趕上launch date比較重要！

4. 來料良率這麼低一定都是因為供應商不用心，趕快來找廠商算帳要求懲罰性賠償！

5. 最近業績MoM, YoY都有持續正成長20%以上，需要趕緊增加產能和擴編！

以上這些當下看似合理的解釋及決策，但最後實際結果是什麼呢？

1. 新推出產品乏人問津，開賣5個月後國內銷量不到20台
2. 專案嚴重延遲，各部門連連抱怨跨部門溝通不良、產生極大的資訊落差
3. 產品上市趕上了launch date，但內部零件發生嚴重磁性干擾，須重新改機構並且需延遲至少三個月後出貨
4. 跟廠商多次開會討論及分析，原來是我方R&D未將公差定義清楚並記錄在圖面和承認書、驗收標準也未事先取得雙方共識
5. 業績迅速下滑導致產能過剩，工廠連續兩個月裁員

這些都是過去發生過、血淋淋的實際案例，高層決策圈不乏來自頂尖學校如台清交成等背景，但仍一再犯下這類的失誤，而且未來很有可能會繼續發生。

犯了這些錯，對公司營運是否會產生立即性影響呢？

其實不會到傷筋動骨的地步，但看不到的隱形成本和傷害這時都已經發生了，而且這些無形成本往往會被決策圈視為無關緊要的小問題或者是優先順序排很後面的事項，不夠重視的結果往往意味著這類事件會不斷重複發生。

對公司氛圍和內部文化來說，會使得人與人之間不再溝通、對決策圈一再失敗而產生的不信任感、對註定會失敗的產品無法激起熱情、大家只想著做好自己份內工作領薪水、不說話不主動扛事情就沒事反正老闆也不會聽…etc.

長久下來容易造成工作倦怠，日複一日耗損了原本對工作和生命的熱情，最終只能走向離開一途。

在現今企業紛紛追求轉型的道路上更是時常深受認知偏誤的影響，不論是想要數位轉型或者是試圖追求BPR，業界早有統計失敗率高達70%甚至還逐年提高，接觸過的顧問也一再苦口婆心，相信有經驗的讀者一定多少聽過：

『推動轉型或優化流程，需動員全公司之力才有可能辦到』

『抗拒變化是人的本性，公司內部一定會有極大的反彈，所以高層一定要親自出馬帶領大家』

但數據證明失敗率始終居高不下，很顯然地一樣是認知偏誤作祟。組織追求轉型成功與否，其實就我觀察，從老闆和高層的態度就看得出來。

在商業策略高度上的決策是否成功，個人認為最大責任無庸置疑在老闆或最高決策者身上，列舉所有可能失敗的原因包括部門間的隔閡與對立（本位主義/ silos effect）、部門之間並未訂定共同的KPI或OKR、只追求表面功夫（大外宣）、指派能力不足的人員擔任負責人等等，這些只要高層理解這些問題的嚴重性、priority放在第一順位並且願意躬先士卒作為全體表率，絕對是top-down方式就可以解決的問題。

我認識的大部分同仁都很單純，誰付我薪水就聽誰的，很理所當然地除了老闆還有誰？若老闆第一個當頭衝在前面，有誰敢不跟著衝？但這樣還遠遠不夠。

任何型態的專案包括產品開發、數位轉型等等，是一個『絕對』需要所有人一起動起來的團體文化運動，老闆和中高階主管先在前面處理好策略、資源與權責問題，後面靠全體員工配合一起協助，增進自身技能和發展，才有機會成功。

策略規劃上或許很簡單，但執行面要考量到人的複雜度，大多數領導者通常在技術方面或者在商業決策上非常有經驗和具有高超能力，但往往缺乏洞悉人心或辨識認知偏誤的能力，或者可以說是lack of empathy，我認為才是大部分企業轉型不順或失敗的主要原因。

每家公司成功的方式都不一樣，我認為學會成功之前，先學習怎樣失敗，至少可以從失敗中學習成長。

以上都是我個人觀察和心得，不代表100%我說的都是正確，但至少希望可以帶給讀者一些不同的角度去思考，世界上所有的問題都是人的問題，同樣問題在不同的環境和人身上是無法適用相同的解決方案的，有時真正的解決方法並不一定要直接針對問題本身，而是找出具有真正影響力的人去推動才會更加省事。

不過呢，認知偏誤這東西是這樣的，會犯這些錯誤的人即使看到這篇文章，並不會覺得他們有犯了這些毛病，也就是客觀事實和主觀認知產生的落差，大部分的人是難以克服認知偏誤的，畢竟這些偏誤是演化來讓我們在荒野和社群中求生的，所以基本上成功還是屬於懂得自省的極少數人唷！（至少我知道我中了好幾個 😅)

下一篇會分享在企業營運上關於有效溝通的小小心得～

Reference:

Dead Companies Walking: how a hedge fund manager finds opportunity in unexpected places

商業策略企業是如何失敗的？公司的三大死因

人類思維並不理性：談心理學3種認知偏誤

洞察企業衰敗的五個階段，是避免重蹈覆轍的關鍵

Leading Change: Why Transformation Efforts Fail

1 Reason Why Most Change Management Efforts Fail

如果喜歡這篇文章，請幫我拍手1–10下。 
如果喜歡閱讀關於新創公司相關主題的話，請幫我拍手10–30下。 
如果希望看到更多的話，請幫我大力拍手30–50下。也請記得 Follow 我 Charles Chen，讓我與你分享更多好知識😊 
非常歡迎你在文章底下留言，我很樂意也很期待跟你討論或聊天！