搞定人心，是所有產品開發與領導的底層邏輯，如果你看完上一篇 Health365 的真實故事，一定會發現一件事：
第一篇講 Health365 的混亂、危機、誤解、焦慮。 那不是戲劇效果，而是 PM 生活的現實。但今天，我想談的不是故事，而是方法。是我在第一線擔任產品與專案經理 10 多年，從無數次崩潰之中整理出的：產品做不起來，很少是因為程式碼寫不好。幾乎都是「人心」沒有被照顧好。
T.R.U.S.T — PM 的人性工程模型
它不是一套公式，而是一種能力。 是一種讓複雜專案「活下來、做出來、推起來」的底層邏輯。
而 Health365 之所以能從混亂走向成功，靠的不是幸運，而是完整落實了這五個字母。
T = Transparency（透明）
透明不是告知，而是提供安全感。我們常說 PM 要讓資訊透明，但透明真正的目的是：
降低人心的不確定感，提供心理安全。
這跟馬斯洛需求階層中的「安全需求」完全一致。 只要人沒有安全感，他就無法合作、無法決策、更無法信任你。
在 Health365 初期，資訊不透明造成的混亂像雪球一樣滾大：
- 工程師焦慮：「醫院到底想要什麼？」
- 醫院焦慮：「版本什麼時候會好？」
- 衛生局焦慮：「記者會會不會出包？」
- C 據點焦慮：「阿嬤問我為什麼按鈕不一樣了，我怎麼回答？」
這些焦慮都不是技術問題，全部都是「資訊不對稱」造成的。
所以我立刻做三件事：
- 每週跨單位同步會：建立共同真相，讓所有利害關係人看到一樣的資訊 (目前進度、已知問題、本週優先順序、專案風險點、下週版本內容)。當所有人看到同一片天空，就不會亂猜天氣。
- 需求、Bug、版本排程全面集中管理: 過去需求散落在LINE 截圖、E-mail、口頭約定、醫師的白板筆記、據點阿姨的電話。 集中管理後關於誰提的？需求值不值？何時處理？目前狀態？ 通通一清二楚。大家開始有「掌控感」，焦慮自然下降。
- 誠實比完美更重要: 透明不是「報喜不報憂」，而是「風險要早說」。專案真正會死的不是延期，而是「隱瞞」。 像我們曾經遇到點數系統延期，我坦白告知原因、提供替代方案，最後院方主管反而說：「至少你願意講實話，我們願意一起調整。」
透明是信任的起點。只有安全感，人才願意一起走下去。
R = Reliability（可靠）
承諾，就是 PM 的貨幣。 PM 不是靠權力在工作， PM 的權力其實只有一種：
你說的話，別人信不信。
承諾跳票一次，信任掉一格；跳票三次，你就變成「不可靠的人」。
偶然聽到游舒帆Gipi院長的「ACE 承諾法則」，覺得很好用，分享給大家：
1.Attend — 搞清楚真正的「優先順序」
醫院常說：「這個很重要，我們急需！」 但實際急需的不是「功能」，而是：
- 系統穩定（因為要面對長官）
- 能出報表（因為要寫成果）
- 不要出糗（因為要面對民眾）
Attend 的目的： 拆開對方的言語，看懂背後真正的目的。
2. Commit — 只承諾一定做得到的事
承諾前，我一定問自己三件事：
- 這件事是否與專案目標一致？
- 團隊是否真的有能力在期限內完成？
- 完成這件事是否能換來更高信任？
如果三個答案都不是 YES，我就不承諾。
因為：短期討好，換來的是長期失信。
3.Execute — 一旦承諾，就是「使命必達」
可靠是一種習慣。你每一次做到承諾，信任值就＋1。 做到十次，你就成為「值得託付的人」。而 PM 最需要的，就是讓所有人都願意託付你。
U = Understanding（理解）
理解需求，不是寫規格，而是看懂人心。在 Health365，我學會了一件很殘酷的事情：
使用者永遠講不出真正的需求。但他們會用行為告訴你想要什麼。
- 長輩說「看不懂 App」，實際觀察後發現：是字太小、手抖按到奇怪的地方、面子比操作更重要、他們需要被鼓勵，而不是被糾正。
- 護理師抱怨麻煩，其實：他們只是怕被長輩問、他們害怕要幫忙處理技術問題、他們沒有時間。
- 工程師看起來「難溝通」，其實只是：希望需求不要變、希望評估能被尊重、希望有完成感
在 Health365或任何產品開發現場，每一個人的需求其實都能被拆解成馬斯洛七大類需求。這不是心理學概念，而是「理解人」最強大的 PM 工具。
1 生理 → 2 安全 → 3 社會 → 4 尊重 → 5 認知 → 6 審美 → 7 自我實現
而在專案現場，我把它重新翻譯成：產品開發現場的「七大底層需求」
① 生理需求（Functional Need）＝最基本的「實質需求」
使用者只要能操作與完成任務，就是生理層級。
對 Health365 的長輩、醫護、工程團隊都一樣：按鈕大、字放大、程式不要一直當、數字要準、流程少、步驟少、功能要能完成任務、介面不要難懂。
這些需求最「沒有情感」，但如果連這層做不好，所有更高層需求都不會發生。
這一層做不好，使用者連「活下去」（使用 APP）的動力都沒有。
② 安全需求（Safety Need）＝透明、穩定、沒有風險
這層與 T.R.U.S.T 的「Transparency」「Reliability」完全連動。
- 長輩需要：APP 不會突然變、數據不要亂跳、健康資訊不要錯誤
- 護理師需要：我教出去的操作要穩定、不要被長輩問到爆
- 醫院需要：不要在記者會出包、系統穩定、資安合法
- 工程師需要：需求不要突然換、時程要能掌控
PM 必須創造「心理安全」。這是信任的根基。
③ 社會需求（Belonging Need）＝人際、團隊、歸屬感
這一層最容易被 PM 忽略，但卻是決定專案生死的核心。
- 長輩：想跟其他阿嬤一起走路、想 PK 步數、想被據點記住、想感覺自己是「團體的一份子」
- 護理師：想跟 PM 有良好溝通、想被團隊支援、想感覺自己不是孤軍奮戰
- 工程師：想跟 PM 是「同一隊」、不想被罵、想被理解
- 醫院：想與衛生局、我們三方「是一個團隊」、想一起成功
所有合作問題，幾乎都出在這一層。
④ 尊重需求（Esteem Need）＝形象、面子、成就感
這層涵蓋「形象需求」＋部分的「心理需求」。
- 長輩需要：阿嬤要第一名、要讓孫子看得起她、要覺得自己做得到
- 醫院需要：要績效、要讓長官覺得有成果、要讓新聞上得漂亮
- 衛生局需要：要亮點、要一個能大力宣傳的成功案例
- 工程師需要：想被認可、想被尊重、想有成就感、想變成「可靠工程師」
PM 要懂得「給面子」，這是運作大型專案最重要的技巧。
⑤ 認知需求（Cognitive Need）＝想知道「為什麼這樣做」
這層是專家、醫生、工程師最強烈的一層。
- 工程師會問：「為什麼要這樣做？」「為什麼需求突然來？」
- 護理師會問：「為什麼長輩要用這個？」
- 醫院會問：「這功能對我們有什麼價值？」
- 長輩會問：「為什麼我要每天量？」「為什麼要走步數？」
很多衝突不是能力問題，而是「不知道為什麼」。
PM 的解法：把原因講清楚、把脈絡講清楚、把價值講清楚
「知道理由的人，會走更遠。」
⑥ 審美需求（Aesthetic Need）＝喜歡、漂亮、舒服、愉悅
這層常被忽略，但在高齡場域特別重要。
- 長輩：喜歡畫面簡單舒服、顏色不要太亮眼、喜歡有「鼓勵語」
- 護理師：喜歡畫面整齊、流程清晰
- 工程師：喜歡「寫起來舒服的結構」
審美不只是 UI 設計，審美是「使用過程中的美好感受」。專案也需要審美：簡單的流程、有品質的文件、清楚的報告。這是 PM 少數能「立刻增強信任感」的地方。
⑦ 自我實現需求（Self-Actualization Need）＝使命、影響力、價值成就
這層是所有人最深層的需求，也是最常被忽略的。
- 醫院：想改善長輩健康、想創造社會價值、想改變「慢性病惡化」這個困境
- 衛生局：想打造城市健康政策、想成為示範案例
- 長輩：想讓自己不需要看診、想活得健康、走得出去、想做得到年輕人做得到的事情
- 工程師：想做有影響力的產品、想看到自己的技術改變世界
- PM：想讓一個龐大的醫療產品真正落地、想打造能被社會肯定的成果
自我實現，就是「為什麼我們一起做這件事」。沒有這一層，再大的專案也推不動。
理解需求，就是理解人。理解人，你才能做出人會用的產品。
S = Stakeholder（利害關係人）
沒有管理利害關係人，專案一定會死。
在大型專案中，你最常遇到的不是技術問題，而是：某高層突然插話、醫師突然改想法、據點說這樣不行、衛生局說風險太高、工程師說不合理、護理長說這樣她不能交差。 所有這些，都是利害關係人問題。
管理利害關係人之前要先識別哪些是重要的利害關係人，以下幾點識別方式:
- 依照流程來找出影響範圍重要的人
- 依照組織權力結構來找出可能影響產品結案的人
- *特別留意: 專案過程中提到的人名、會議中有沒有未曾見過的人參與、信件副本是否有陌生的收件人。
沒有管理利害關係人，專案一定不會成功。
管理工具 1：影響力 × 關注度矩陣
繪製出利害關係人(stakeholder)影響力 (橫軸) X 關注度(縱軸)矩陣:
- 重點管理: 影響力大且關注度高的stakeholder。例如:大同醫院院長、衛生局科長
- 盡力滿足: 影響力大但關注度低的stakeholder。例如:護理師、社工、據點志工
- 資訊透通: 關注度高但影響力小的stakeholder。例如:工程師、資料科學家
你要「因人調整策略」，而不是全都一樣處理。
管理工具 2：游舒帆院長的溝通三層階梯法
- 理想解溝通 (Ideal): 最佳的溝通方法，找出共同目標或共同想解決問題的方法。 掌握對方真正想達到什麼？
- 實務解溝通(Practical): 第二項可選擇的溝通方式，搞定現實問題、回應人性需求。我們能做到哪裡? 以下三種常用的手法:
- 妥協: 對需求做出一定讓步，例如: 時程、範疇、資源妥協
- 交換: 資源上的相互交換， 拿出您所擁有的，換你沒有的。
- 排除困難: 協助搞定棘手問題，先解決對方難處。
- 權力解溝通(Power): 最後逼不得已的情況下才使用權力解決，靠制度與組織力量推進，找老闆來扮演黑白臉策略(讓老闆來扮黑臉罵PM，讓團隊皮繃緊一點)。這件事卡在哪個權力節點？
T = Trade（交換）
合作不是請求，是互利。很多 PM 常犯的錯誤是：「拜託他們幫我做這件事。」錯!
真正有效的是： 「你幫我這件事，我給你你想要的那件事。」
這就是「交換」。
1. 跟醫院的交換
- 我們給：儀表板、趨勢分析、風險預測模型
- 他們給：臨床數據、實際場域、臨床驗證
2. 跟商家的交換
- 我們給：長輩的流量、活動曝光
- 他們給：獎品、折扣、宣傳合作
3. 跟 C 據點的交換
- 我們給：遊戲化活動、健康點數、現場支援
- 他們給：長輩參與度、實際使用者回饋、推廣力道
4. 跟工程師的交換
- 我給：清楚不變的需求、合理的排程、給工程師擋需求的權力
- 他們給：穩定高品質產出、良好溝通、高度信任
合作不是施捨，而是交換。能交換的人，才能帶得動專案。
結語：搞定人＝搞定產品
T.R.U.S.T 是 PM 的人性肌肉。產品不是做出來，是「一起做出來」。 而「一起做」的前提，就是信任。
T.R.U.S.T 是 PM 面對所有混亂時的底層操作系統：
- 透明（T）讓人安心
- 可靠（R）讓人相信你說的話
- 理解（U）讓人覺得你站在他那邊
- 利害關係人（S）讓專案不會被卡死
- 交換（T）讓合作能長久
技術可以解決問題，信任才能啟動合作。搞定人，你就能搞定產品。
