PMP 免費試做 10 題

「對系統有益」只是工程師的單方判斷；升級可能帶來相容性問題，影響測試與時程，這些都要在整體層面評估，善意不能取代授權。

改在下班時間做，並不改變它是範疇外工作的性質：變更照樣進了產品，卻沒有工時紀錄與測試安排，風險反而更高。

拒絕看似守住了範疇，但一口回絕又警告不要多事，會澆熄成員提出改善的意願；這項升級可能真有價值，應經評估再決定，不該由專案經理當場否決。

技術爭執是團隊日常，直接上報發起人既越級也太早：發起人缺乏技術脈絡，介入只會放大事件，並削弱團隊自行解決問題的能力。

直接拍板看起來能快速止爭，但依年資裁定繞過了論證，資深不代表方案正確；Scrum 主管替團隊做技術決策，也會削弱團隊的自主與承諾。

分開兩人能暫時降溫，但只是迴避衝突：技術方案終究要選定，未解的分歧會在下次協作時再爆發。

加班看起來能讓曲線動起來，但若問題是阻塞或任務切分過大，多投入工時並沒有幫助，還會累積疲勞，不符合可持續的步調。

主動向發起人溝通是好習慣，但還沒查明原因就預告延期，可能只是看板沒更新而誤報；應先診斷、確認影響後再報告。

重新分配假設問題出在負載不均，但這只是眾多可能之一；而且敏捷團隊的任務由成員自行認領，專案經理未經診斷就平均分派，既可能無效，也削弱自組織。

想保住Sprint目標的用心可以理解；但沒有測試過的增量不符合完成定義，等於把品質風險往後推，交出去的並不是可用的成果。

持續跟進本身沒有錯；但已經正式協調三次都沒用，再催也改變不了對方人力不足的事實，只會消耗時間和關係，Sprint目標還是會受影響。

自行破解權限屬於未經授權的存取，違反組織治理與資安規範；用違規手段排除障礙，製造的問題比解決的還多。

把問題歸給法務效率，是把責任推向別人；法務在兩週內就提出疑慮並不慢，問題不在他們回覆多快，而在被通知得太晚。

時程緊確實讓修改更困難，但日期本身不是根因；若法務從啟動就參與，同樣的日期下合規需求早已內建於設計。

團隊做出的是符合已知需求的系統；缺的是沒被提出的合規需求，這是利害關係人辨識的失誤，不是技術能力的問題。

全案採用純Scrum看似一致，但硬體採購與法規送審有實體前置期與固定程序，切成Sprint也不會縮短交期，只是形式上的敏捷。

單一方法便於管控，但凍結多變的軟體需求，容易做出不符需要的產品，後續變更的成本也會很高。

讓各部分用適合的方法是對的方向，但混合式的難點在整合；互不過問進度，介面對不上、時程互相等待的問題會在整合時才爆發。

維護團隊的估算方式出發點沒錯，但拒絕提供任何日期，忽視了主管正當的商業需求；方法論是為目的服務的，不能拿來擋掉溝通。

改回工時制看似最快讓主管滿意，但丟掉相對估算快速、避免精確假象的優點，而且在高不確定的工作上，工時估算同樣容易失準。

這是錯誤的說法:敏捷可以預測，只是用經驗數據(例如速度)持續修正預測；回答「無法預測」不但不正確，也會損害主管對團隊的信任。

想讓團隊自己做決定，方向沒錯；但只禁止發問，卻不說明哪些事可以自己決定，團隊會從不敢決定變成不敢問也不敢決定，事情反而卡住。

故意拖延回覆是消極手段:團隊沒有得到授權，只是被迫等待，交付會受影響，對專案經理的信任也會受損。

用績效懲罰請示，短期內次數也許會下降，但團隊可能改成私下亂做決定或隱匿問題，比過度請示更危險，根因也沒有解決。

高層支持對變革確實重要，下令也能快速推動轉換；但強壓換來的多半是表面服從，使用者消極使用、私下繞路，系統效益大打折扣。

調離抵制者看似除去阻力，實際上是壓制訊號:其他人學會閉嘴，抗拒轉入地下，專案還失去最了解實務痛點的資訊來源。

訓練是變革配套的一環，能解決「不會用」；但抗拒的根源常是流程被改變的失落與未被諮詢的不滿，加開課程解決不了「不想用」。

文件歸檔是收尾的必要工作，值得做好；但它只證明專案按程序結案，回答不了發起人「效率到底有沒有提升」的質疑，不是效益實現管理的主要關注。

釋出團隊成員是收尾時合理的資源管理工作；但人走了之後若沒人接手追蹤效益，正是本題出問題的地方，它本身不是效益實現的關注重點。

驗收簽名確認交付物符合需求，是結案的重要依據，看起來也在「確認成果」；但效益要在營運中才會顯現，簽名再齊全也回答不了效率是否真的提升。