軟體開發有「敏捷模式」，考校長的筆試、口試是否也可套用？
有位夥伴這次校長甄試，筆試四題只寫完三題，因為有一題剛好是專長，寫得太多太久，結果時間失控，以些微差距落榜，令人扼腕。
一題一題接著寫，就是傳統的「瀑布式」，有如「接力賽」，一棒接一棒，很好操作；但如有一棒翻車，全隊可能被淘汰。
「敏捷式」則是四棒一起跑，時間會大幅縮短，但需要的設計與管理成本也會更高，嘗試轉譯一下給大家參考：
一、先把全卷試題看完，不急著寫第一題（通盤了解顧客需求）。
二、每一題答案都設定一頁，分配好空間及時間（分工與期程）。
三、構思每題的答案架構，大概都分三層（工作清單）：
第一層：大略論述整體的Why（意義價值）、How（策略方法）、What（行動方案）
第二層：進一步論述Why（核心價值）&How（方法策略）
第三層：大書特書What(行動方案)
其實就是新聞稿「金字塔式」的寫法：第一段先讓受眾掌握相關的人事時地物；想進一步了解的再看第二段；想全盤了解的，則看完第三段。
四、先寫各題的第一層，每題都先有保底分數（第一輪Sprint衝刺）。
五、逐次迭代，再寫各題第二層，拿到及格分數（第二輪Sprint衝刺）。
六、迭代完善，寫完各題第三層，拿到達標分（第三輪Sprint衝刺）。
這是基本原則，人不是機器，當然不可能這樣機械化動作，現場需要彈性變通。
至於口試，更需要敏捷式，因為口委不知何時會「咖」考生的時間，所以答案也要分三層：第一層等於先出菜單，讓客戶（口委）了解你將做出什麼樣的產品（答案），了解全貌。
因為委員聽跟看不一樣：看是馬上知道考生答案寫多長、大概寫什麼；聽則不知考生會講什麼，講多長！
有時委員只聽完第一層，就會覺得這位考生很有系統思考，就錄取了！
以上僅供參考，如有不良後果，必屬巧合！
