風中的承諾wiki的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列免費下載的地點或者是各式教學

正念減壓教學者手冊：給臨床工作者與教育家的實務指引

為了解決風中的承諾wiki的問題，作者唐．麥科恩,黛安．萊伯,馬克．米克茲 這樣論述：

　　《正念減壓教學者手冊》是最早探討正念課程教學法的完整著作，至今仍然是這方面的唯一專門著作，如同正念減壓創始人卡巴金博士在序中所說：「獨一無二。」 　　本書內容納入各種學習人類經驗的方法，包括科學、靜心和哲學傳統的觀點，提供正念教學者需知的後設理論與實用技巧。全書內容分為三大部分：第一部分探討正念課程的背景知識，正念的東、西方源頭和定義，提供初學者入門資訊；第二部分分析正念課程教學者應具備的特質與教學技能；第三部分闡述正念練習的各種教學意向，及其在課程裡實際運用的情況。 　　本書作者群具備在醫療體系教導正念減壓的資深經驗與研究權威，他們共同創作此書，是從事專業正念教學

工作者不可或缺的工具書，同時也是有心了解正念減壓課程的朋友不可錯過的好書。  

專案管理人應該知道的97件事：來自專家的集體智慧

為了解決風中的承諾wiki的問題，作者Barbee Davis 這樣論述：

　　如果管理的專案不如預想般順利進行，《專案管理人應該知道的97件事》將能為你提供無價的知識，書中的珍貴知識是經由多年的嘗試與試誤中所得。本書包含97則簡短又極為實際的小訣竅 － 無論用於軟體或非IT類專案 － 訣竅的提供者是一群世上最有經驗的專案經理人與軟體開發師。讀者將能從中學習專家處理大小諸事的技巧，包括管理團隊與應付專案的利害關係人、超出控制的會議等等。 　　雖然本書以軟體專案為主，但其中所涵蓋的原理可適用於各種產業各類專案的專案管理原則。讀者可逐章閱讀，也可以單獨挑選特別適用於自己的章節。本書既是很有用的參考工具書，也是刺激想法的泉源。 　　在本書的97則訣竅中，各位將可看到的精

闢見解，如： 　　* 精巧的程式碼很難維護（David Wood，Zepheira合伙人） 　　* 每位專案經理人都是契約管理者（Fabio Teixeira de Melo，Construtora Norberto Odebrecht規劃管理師） 　　* 回報內容中可否兼容實獲值與速度？（Barbee Davis，Davis Consulting總裁） 　　* 如何定義「大功告成」？（Brian Sam-Bodden，作家、軟體架構師） 　　* 最佳估計人選：負責工作的人（Joe Zenevitch，ThoughWorks資深專案經理人） 　　* 如何慧眼識出優秀IT開發人員（James G

raham，獨立管理顧問） 　　* 一項交付標的，一個人負責（Alan Greenblatt，Sciova CEO） 　　Barbee Davis，MA、PHR、PMP，為PMI的《Community Post》撰寫半月刊載的專欄。她擁有一間Davis Consulting公司，提供訓練與開發工作室及諮詢服務。 標題分類 前言 盡早引入使用者的參與－ Barbee Davis, MA, PHR, PMP 避免打地鼠式的開發－ Venkat Subramaniam 一個讓人錯過最終期限的字－ Pavel Simsa, PMP 請專案資助方寫出需求－ Miyoko Takey

a, PMP 以簡勝繁－ Scott Davis 清償債務－ Brian Sletten 為團隊增加天份，而不是技能 － Richard Sheridan 保持簡單，Simon － Krishna Kadali, M. Tech 你並不特別－ Jared Richardson 一則關於螢幕捲動與時代的舊事－ Kim MacCormack 節省解決問題的花費－ Randy Loomis, PMP 如何慧眼識出優秀 IT 開發人員－ James Graham, PMP 開發人員的生產力：技術超群與中人之姿的比較－ Neal Ford 尺寸很重要－ Anupam Kundu 書面記錄流程，並確實遵守

－ Monte Davis, MCSE 丟掉習慣－ Naresh Jain 需求規格：矛盾－ Alan Greenblatt 成敗的衡量標準永遠是商業價值－ Barbee Davis, MA, PHR, PMP 別為了專案錯過假期－ Joe Zenevitch 提供規律時間安排以恢復專注力－ James Leigh 專案管理就是問題管理－ Lorin Unger 授權給開發人員：Tim 的故事－ Ken Sipe 精巧的程式碼很難維護－ David Wood 在 IT 專案管理中管理人際因素－ James Graham, PMP 使用 Wiki － Adrian Wible 失落的環節－ Pa

ul Waggoner, MBA, PMP, MCSE, CHP, CHSS 評估、評估、再評估－ Richard Sheridan 開發人員站出來 － PMO 是一種進步－ Angelo Valle 重視成果，而非只看過程－ Venkat Subramaniam 軟體的失敗就是公司的失敗－ Brian Sletten 來自另一端的聲音－ Marty Skomal, MPA 保有自己的洞察力－ James Graham, PMP 如何定義「大功告成」？－ Brian Sam-Bodden 60/60 法則－ David Wood 我們遇到了敵人......就是我們自己－ Barbee Davi

s, MA, PHR, PMP 配合週期來工作－ James Leigh 對自己要實在－ Harry Tucker 光開會寫不了程式碼－ William J. Mills 繪製一條變更的道路－ Kathy MacDougall IT 計畫管理：分享願景－ David Diaz Castillo, MBA, PMP 據現實以規劃－ Craig Letavec, PMP, PgMP, MSP 完美執行之謬論－ David Wood 引入更為敏捷的溝通系統－ Brian Sam-Bodden 別把理論方法當成寶－ Fabio Teixeira de Melo, PMP 別用試算表處理人際問題－ An

upam Kundu 一項交付標的，一個人負責－ Alan Greenblatt 完美知識之謬論－ David Wood 打造能跑馬拉松而不是短跑衝刺的團隊－ Naresh Jain 專案管理的聖三角－ Paul Waggoner, MBA, PMP, MCSE, CHP, CHSS 路線圖：我們最近為您完成的事？－ Kathy MacDougall 專案範疇聲明的重要性－ Kim Heldman, PMP 保持願景與期望成果一致－ David Diaz Castillo, MBA, PMP Alice 不再是這裡的人－ Barbee Davis, MA, PHR, PMP 避免契約爭執－ J

orge Gelabert, PMP 評估的事項就是獲得的事項－ Naresh Jain 別罹患 NIH 症候群－ Dr. Paul Giammalvo, CDT, CCE, MScPM 多用現在，少說馬上－ Scott Davis 速度就是生命、愈快就是愈好－ Matt “Boom” Daniel 打造團隊的士氣－ David Bock 專案要仰賴團隊合作－ Lelio Varella, PMP 為你的團隊服務－ Karen Gillison 完美圓球之謬論－ David Wood 危機反應－ James Graham, PMP 瞭解自己的整合點－ Monte Davis, MCSE 積極促

進分散式專案中的溝通－ Anupam Kundu 開始前就瞭解終點在何方－ Luis E. Torres, PMP 說清楚、講明白，友情才長久！－ Matteo Becchi, PMP 最佳估計人選：負責工作的人－ Joe Zenevitch 溝通是關鍵－ Gennady Mironov, CPM 專案就是對於解決方案的追尋－ Cynthia A. Berg, PhD (ABD), PMP 那都是真人啊！－ Adrian Wible 文件是方法，而不是結果－ Patrick Kua 回報內容中可否兼容實獲值與速度？－ Barbee Davis, MA, PHR, PMP 範疇經常變更；學會習慣

這件事－ Pavel Simsa, PMP 購買現成軟體－ Ernani Marques da Silva, MBA, PMP, PgMP 專案贊助者 － 好、不佳、非常糟－ Jorge Gelabert, PMP 我們應該調低承諾，或是交付多於預期的目標？－ Joe Zenevitch 每位專案經理人都是契約管理者－ Fabio Teixeira de Melo, PMP 重要，但不緊急－ Alex Miller 傳授流程－ Richard Sheridan 狀態之謬論－ Udi Dahan 他們究竟想聽到什麼？－ Martha Legare, MBA, PMP 認識團隊士氣的價值－ Dav

id Bock 讓利害關係人全程參與專案－ Lukeman Lawal, M.ENG, MNSE, R.ENGR. 計劃的價值－ Derry Simmel, PMP, MBA, FLMI 別一直當個「傳聲筒」－ Matt Secoske 有效管理交付標的－ Ernani Marques da Silva, MBA, PMP, PgMP 我們是專案經理人，不是超級英雄－ Angyne J. Schock-Smith, PMP 促進溝通：舉辦經常、立即的會議－ Richard Sheridan 彈性簡化了專案管理－ Krishna Kadali, M. Tech 全球資訊網指出方向，暫時地－ Da

vid Wood 開發人員討厭狀態報告，但管理人員很愛－ Pavel Simsa, PMP 我們無法掌控一切－ Patrick Kua 分享願景－ Jared Richardson 真正的成功伴隨著公司組織的支援而來－ Cynthia A. Berg, PhD (ABD), PMP 打造專案管理行政－ Ernani Marques da Silva, MBA, PMP, PgMP 我討厭貴網站的 9.7 個原因－ Barbee Davis, MA, PHR, PMP 作者群 索引 在 IT 專案管理中 管理人際因素James Graham, PMPTa’ l-Ibrag, Malta身為軟

體專案經理人，我們對於時程表的細節吹毛求疵。我們對著數 據奮戰，試著從分配到的預算中，壓榨出專案交付標的。但我們經常 沒看到、或忽略了造成專案失敗的最普遍因素：人。從錯誤、意外、乃至於完全沒有效能，人為失敗的出現通常能與我們 重複過往行為的傾向聯繫起來；我們有種心態：『如果這個方法成功過， 應該也能再度成功』。有句俗諺：「對於槌子來說，每個問題都是個 釘子。」心理研究證明，人類在壓力的影響下，有可能回復到槌子式 的學習或經驗，因為過去曾透過某種方式取得成功。還有什麼環境比 一個新的軟體專案更有壓力？因為大多數專案的目標都是建立新產品、服務或解決方案，心智與工 作風格的敏捷性與靈活性才是我們鼓勵

的重要積極行為，而不是重複 過去的動作。遵循舊有的程序，在面對新的不同挑戰時，反而可能產 生不良後果。試想有一位產業分析師， 他對某種舊有的軟體專案管理方法很有經 驗。理智上來說，當他的開發人員解釋一種更為敏捷的軟體開發方式 更為合理的原因時，他應該會同意這些解釋。但在他面對危及專案的 時間壓力時，卻可能退縮而改用曾經良好運作的技術；他的依據是一 段與軟體無關的經驗。銀行的主管回報說顛倒數字是種常見的錯誤，尤其在員工因為工作或 私人相關的壓力而無法專心一致時。瞭解人性的傾向後，聰明的專案 管理者將仔細於評估、預算與其他文件中，檢查此類不小心、但反映 人性的錯誤。有哪些事可能對專案團隊形成壓力？

可能是私人的事，例如出門上班 前跟另一半吵架了、 或是家裡有經濟壓力， 又或許是擔心家人的健 康、擔心小孩等等。工作上遇到的事也可能引發壓力。可能是些小事，例如在重大股東會 議時遲到、忘記攜帶重要文件、也可能是對於工作安全性的顧慮，甚 至是憂心專案的編程與測試無法如期完成目標等等。壓力導致行為退縮，使我們不會積極尋求解決問題的行動。身為軟體 專案經理，注意這些導致團隊成員退回過往行為的壓力癥狀，我們責 無旁貸。透過與成員積極對話，仔細經營工作的環境，即可避免壓力 的影響，或有助於把影響降到最低。人都擁有人性，工作場所自然也會看到人性人情。但只有人才能開發 軟體，所以在監控與保護非人的資源時，也

請小心培育與管理手邊的 人性資本。保有自己的洞察力James Graham, PMPTa’ l-Ibrag, Malta向使用者收集業務需求時，經常聽他們反應「系統太慢」、「應用程 式不可靠而且會當掉」、「程式做的都是我不需要的事，都不做我需 要的事」、「明明是個簡單任務卻要按好幾個鍵」。大部分軟體專案經理人都會同情使用者。我們試著提出似乎能消除痛 苦的方案，試著讓使用者覺得好過一點。但我覺得，雖然出發點可能 是基於好意，本質上卻是錯誤的；更糟的是，還會進一步降低專案成 功結束的可能性。有些人說，收集業務需求的重點，在於提供量身訂做的解決方案，據 以減輕終端使用者的失望感。我同意這是個值得奮鬥

的目標；不過， 專案經理人如果基於「想讓使用者覺得好過一點」的心情來決定最佳 方案，將會出現致命的缺陷。實際上，這樣的專案經理人可能缺乏保 持洞察力（perspective）及不偏不倚的自我訓練。洞察力，表示要尋找最佳方案，而不是「感覺上對使用者好」的修正 方式。請記得，使用者對於自己的產業領域有著深刻的瞭解，藉由分 享這些知識也能對專案做出極大的貢獻；但我們該如何運用使用者提 供的知識？當我在一家倫敦的管理顧問公司工作時，經驗豐富的同事們曾指導過 拒絕的重要性。他們的智慧建議是根據老套的事實：大多數專家喜歡 炫耀自己的聰明，但其實應該花時間有技巧地詢問正確問題，以解決 根本的病源。如果不揭開

真正的病因，所有嘗試解決的方式只會更加 刺激症狀。我們都處在趨從於這種錯誤的危險中。最近，我接到為一家大公司設 計一個管理開發程式的需求。我當時的衝動就是趕快動手處理造成問 題的地方，並建議客戶先看一個我做好的程式。我知道那個程式可以 輕易調整，從而治療讓客戶痛苦不已的問題。幸好，自我克制及時發揮作用。我跟資深經理深談一個小時，瞭解真 正的挑戰。當我後退一步，傾聽業務上的問題，而不只是終端使用者 的抱怨（這指向不恰當的問題），我推薦的是完全不同的解決方式。 這樣更能切合他們的需要，並解決核心的問題。下次遇到沮喪失望的使用者，深呼吸一口氣。先讓他們宣洩對於日常 遭遇的表面症狀的不滿 － 這些惱人

的事情都真實存在。然後對使用 者詢問一連串問題，找出沮喪下的真正根源。請迴避提供快速修正方 式、快速滿足使用者的誘惑。只有在規劃專案的解決軌跡前，先確定 瞄準了正確的目標，才是對使用者最好的做法。

消費者使用線上購買到店取貨關鍵因素之研究—以化妝品為例

為了解決風中的承諾wiki的問題，作者何淑君 這樣論述：

全通路時代的來臨，在疫情的驅動下，使得消費行為快速從線下走到線上，進而加速實體零售業進行數位化轉型，打破線上線下的分野為消費者提供一條虛實整合的新通路，以消費者使用便利及需求為核心，讓消費者在任何一個通路皆可獲得一致且完整的資訊及服務，透過數位化技術的運用優化了消費者的消費體驗。線上購買到店取貨(Buy Online and Pickup in Store, BOPS)是發展「全通路」零售的一項新嘗試，它結合了線上虛擬空間及貨架和線下實際場域替消費者打造一種無縫的消費體驗，同時也讓消費者享受無壓力與便捷購物的理想方式。零售商該如何刺激消費者選擇在線上購買，最後走入線下實體店取貨，把人流從線上

再帶回線下，是各實體通路零售業者所需考量的問題。過去諸多的研究中，大部分都以業者的角度來探討BOPS，較少從消費者的觀點出發，本研究採用層級分析法（AHP）來進行分析，探討消費者使用BOPS之關鍵因素，並以化妝品為例，瞭解哪些因素是消費者使用線上購買到店取貨所重視的，以提供給已導入或未來將導入BOPS服務模式之相關業者建議。本論文首先進行文獻資料整理，歸納出四個構面及十五項評估準則關鍵因素，再以層級分析法（AHP）進行分析。最終研究結果顯示，消費者使用線上購買到店取貨之關鍵因素中，最重視的構面為「商店魅力」，其次為「平臺系統」，最後則為「消費體驗」與「顧客互動」。