從土法煉鋼到預測式、Scrum、Kanban…上了數萬起跳的各種專案管理方法拓展了管理思維，但得到更多的是難以推行的挫折，你精心為團隊設想的方法很好，但你需要加上「發酵式管理學」，讓你真的能推動轉變。
標籤: 目標管理
成功的專案都是從一團亂開始，「做麵團」是最能具體體會這「從充滿懷疑到專案完成」的演進，讓我們來場「可以吃的專案管理Workshop」吧！
非常聰明才能成功嗎?史丹佛大學的65年長期研究顯示並非如此！讓平凡人成功的關鍵其實有更多因素。
大家都知道只要放棄就一定不會成功，但你可能不知道放棄的原因通常不是因為太困難，反而無聊、沒看到成效才是放棄的最大原因。
有足夠成效通常就有動力堅持，因此重點還是能不能看到成效，但大家可能更好奇的是「要多聰明才能夠成功」?
成功不用超聰明-臨界點理論 Threshold Theory
史丹佛大學心理學教授推孟(Lewis Terman)是 20 世紀教育心理學的先驅，在1921年開啟了<天才的遺傳研究>計畫，之後的65年追蹤結果證明：
高成果 = 高於門檻的水準 + 持續實踐
簡單說就是不用極度聰明，只要能跨過該項目的基本門檻，剩下的關鍵就是執行的夠不夠熟練。
成效總在突破臨界點後
高成果的要素之一是「高於門檻的水準」 但這裡並非狹隘的指智商，假設要追求的是健康人生，相信不用太高的智商，要考量的因素還有：
- 可以做的活動
- 時間
- 強度
- 飲食
- 休息
不同項目會有不同的標準，重點不在有哪些共通項目，而在「達到臨界點的量」，也可以稱為「推動改變的動能」，更簡單說「做多少才有成效」。
看到高成效才繼續，讓你無法成功
只要有努力，改變在看到成效前其實已經開始，只是通常「沒有察覺」或「沒法流暢使用」。
以要流暢用英文Email溝通為例：
- 學習英文沒學完26個字母，就無法拼出所有常用的單字。
- 不知道常用的單字，就很難了解英文使用者書面的意思。
- 無法了解意思，就不可能流暢的用email溝通。
因此一個英文字母沒背好的人，以「流暢使用英文做Email溝通」為目標，是難以看到成效的。
成效=成功的臨界點
成效強力驅動我們堅持，因此我們可以把「成效視為成功臨界點」或直白說就是「可觀察點」。
在達到臨界點前，怎麼累積都不會有明確的效果，而這是因為我們「累積的改變動能還未超過臨界點」，自然看起來沒有前進。
此狀態一久人自然就會想放棄，畢竟總是有其他的選擇，但頻繁轉換就不會成功，越來越沒自信淪為失敗主義者。
秘密在於適當的目標
笨蛋才只把目標訂在改變世界！我們可以改變世界，但改變世界是史詩級的目標沒法一步達到，中間要有階段，越明確的階段，你就越容易完成目標。
假設我們要改變世界拆分可能像：
改變世界->1000萬人被影響->…省略…->30個學生->社區大學教課->主動去投課->準備課程->列課綱->少看部影片
但常見的失敗點在於，一開始規畫得太細，花太多時間規劃沒去執行，執行後才發現很多計畫都會需要調整。
目標的正確拆分方法
正確目標的拆分方法，我在Youtube影片「科學化改變人生」中有詳細說明，想知道的朋友可觀看下面影片連結，從90秒開始直達拆分必須了解的部分，讓你10分鐘就能掌握正確的觀念。
成功關鍵就是正確拆分與堅持執行
我們都會遇到一面「無形的牆」，讓我們懷疑自己是否聰明到能成功，但從65年的長期科學研究知道「聰明到可以達到平均水準」，後面就是堅持的問題了。
正確的拆分目標，讓你看的到成效但又不至於沒挑戰性失去興趣，只要掌握好這點，堅持就容易多了。
獻給一直努力付出但沒有看到成效想放棄的朋友，加油！成功有臨界點，你的努力並沒有白費，我們堅持累積下去，總有突破的一天。
===========
如果對您有幫助，歡迎請信賢喝杯咖啡
https://ko-fi.com/hsinken
Hsinken吳信賢
FB專頁 https://www.facebook.com/hsinkenfans
Youtube頻道
https://www.youtube.com/channel/UCgxttCHEA4-El2x3tMcjnFg
Apple Podcast
https://podcasts.apple.com/podcast/id1530132764
分類
用程式邏輯了解OKR
OKR是Ｇoogle和Linkedin使用的管理方法論，由 Intel的「葛洛夫」提出，經「杜爾」帶入Google後廣為使用。
OKR = Objectives & Key Results
本篇的重點在於OKR與程式建構的關係。
系統在進行開發語言選擇(C#、Php…)、範型選擇(paradigm)與物件化規劃(Object Oriented )後，會開始設計函式。
函式是程式間重要溝通單位，決定功能是否能完成的關鍵！
系統是團隊共同打造的成果，由每位程式分工後依特定流程呼叫彼此函式組成而來，類別名稱亂取會造成維護上的一些問題，但函式不能正確運作，那系統是絕對會停擺，因此非常重要。
我怎麼設計一個複雜的函式?
1. 我會了解函式的目的，通常那代表產出(output)。
2. 思考用什麼方式來獲得要產出的內容?
3. 依據採用的方式，我會評估呼叫函式時參數給的夠不夠?
4. 輸入不夠的參數是否能在函式運行中取得?例如:從DB或設定檔取得。
5. 若無法取得足夠參數視情況選擇其中一種解法：
A.解法1：選擇新方法，重新2~4流程。
B.解法2：與其他工程師協調，讓傳入時有此參數。
C.解法3：功能無法達成，重新規劃。
6. 分析重要檢核點，例如：電子簽章
A.資料、格式、順序是否正確？
B.簽章用Key否能取用與是否正確？
C.執行簽章中是否出錯?
D.檢查簽章值與範例值是否相同?
最後我就能開始執行、並在執行中提早確定能否完成與最後交付正確產出。
程式邏輯與OKR關係
聰明的你一定已經發現，OKR(Objectives & Key Results)的：
1.O就像我們函式的產出。
2.KR則像建構函式的第六步-分析重要檢核點。
一個大系統或目標都可以經過比較小的OKR去逐步建構與檢核，只要檢核點都能完成那基本上功能80%都能完成，不行的話也能提早檢視問題做出求助或修正。
因此檢核點的設置非常重要，務必做到正確的分析並優先完成，如此你將更容易從容地完成目標。
延伸閱讀
若你有興趣更進一步了解，可參考：
OKR：做最重要的事 – 約翰．杜爾
<博客來介紹與購買連結>
一次讀懂 Google、Linkedin 都在用的 OKR 目標管理法
<想快速了解OKR，請參考 經理人雜誌 專題>
——
喜歡這篇文章有什麼想法或進一步討論或想看看我創作的其他內容
請點擊我的FB討論區連結
HSINKEN 信賢粉絲頁
https://www.facebook.com/hsinkenfans