書接上文：新晉總監生存指南三——OKR實踐
如何追到一個女孩、如何進入一家公司、如何面試一個人、如何成為一個幽默的人、如何評價一個人、如何成為老馬那樣的人？
類似這種問題其實都是有迹可循的，不是說我們一定能成為像老馬一樣的人（其實就是不能），但是總有路徑能讓我們接近老馬，比如成為老馬的兒子。
所謂路徑即“方法論”，掌握合适的方法論，能讓你更容易追到這個女孩，如果追不到可能隻是因為你窮。
言歸正傳，今天的目的不是教大家如何去追女孩子，畢竟那是一件非常簡單的事情， 今天的目的是将之前帶項目的一些經驗分享給大家，并且希望這些知識對可以讓大家後面少走一些彎路。
一、項目概述
所謂項目，即為創造獨特的産品、服務或成果，而進行的“臨時性”工作。
所謂項目管理，即通過運用管理的知識、工具、技能和技術于項目上，來解決項目的問題或達到項目的目标。
根據這幾年的經驗，項目管理事實上是一門實踐的學問，正因為是實踐而得來的，面對同樣的場景，不同的人處理的方式會不盡相同，但是其基礎的思維架構是大同小異的，隻有通過不停的實踐，才能真正掌握項目管理的精髓，成為好的項目實踐者。
作為一個全局負責人的話需要特别有節奏感，這個節奏感，如王者榮耀打野一般，需要掌握大龍小龍重新整理的時間點、需要在合适的時間點去推塔，也就是在正确的時間做正确的事情，暴露正确的資訊，不要亂帶節奏，導緻團戰失利，這個就是所謂的意識，這個意識，再說直白一點就是：對一件事的時間點（事件點）的敏感，而後對資訊的正确處理。
着眼于産研的項目（适用于A級項目，更大的項目會更複雜），作為一個技術Owner（技術側負責人）需要知道自己的幾個發力點：
① 産品營運驅動
② 技術Owner驅動
③ 測試驅動
④ 商務營運驅動
⑤ Owner複盤
可以看到，事實上技術Owner的發力主要點應該是第二階段，這個階段也是資訊對齊、需求梳理的重要階段，早一步進介入，需求産出受挫容易白費力；晚一步介入，需求不清，會導緻研發、測試走彎路而項目延期甚至流産，在合适的時間點将推動項目運作的主導權交給對應的隊友，才更容易成功。當然從頭至尾的資訊傳遞、收集都是一個技術Owner需要做好的。
PS：這裡以王者榮耀為例，前期是打野的節奏，因為打野大局觀最好；後期是法師和射手的節奏，因為後期要團戰，就算1V1，刺客也未必打得過射手了；前期刺客不抓邊、後期刺客非要單殺，都是在丢失節奏。
以一張業内草圖做說明是：
技術Owner的職責主要在實施和控制這裡，這裡我們最常見的問題也出來了：
一、需求變更緻項目風險極高，比如：
某次項目由于時間特性，項目截止點早已确定，卻産生了6次大的需求變更（小的修改太多，無法統計）、需求評審7次，所有的這一切極大的加大了項目風險。
從這次項目的實踐資料來說：一階段功能就有84個BUG，二階段功能竟高達210個BUG，曆史罕見而又符合預期
我們要如何應對這種時間點固定，上遊需求不停更改的項目？
二、資源變更緻項目風險高，比如：
某項目在項目開始接手時的優先級很高到最後要為營收類需求讓路，資源被抽調到更高優先級需求，打亂排期而沒有重新訂立新的基線，對項目管理整體而言是緻命的，其風險見：
要如何應對這種資源不足的情況？
項目中會遇到的問題太多，我們在文章中盡可能的覆寫，是以來解決問題吧！
如何立項擷取資源
做項目之前，第一要務是抓人，沒人一切都是空談，不同的團隊擷取資源的規則不同，一般來說有兩個方式可以要到資源：
一、以OKR的方式組織人員
OKR從機制上說強調的是上下左右對齊，隻要你真的了解團隊的痛點，又有解決這些痛點的目标，那麼對這個目标有興趣的同學可以自主加入，這裡的流程是：
① 提出OKR
② 對齊OKR過程中吸引相關OKR人員
③ 形成OKR 項目組
④ 開始執行
二、以立項的方式組織人員
如果目标是獨一份的，沒有人有與你相同的目标，而你的目标又具有戰略性，并且足夠重要，那麼這個時候就可以走申請立項的流程：
① 準備你的方案
② 拉管理層讨論方案
③ 确認項目周期，周期目标以及資源投入
④ 各團隊準備資源
⑤ 形成項目組
⑥ 執行&複盤
三、公司級項目
這類自上而下的工作類項目，一般而言，資源是可保障的。
項目組成立了，但是很多隊友的能力情況，我們并不清楚，這個時候該怎麼辦呢？
一、這個時候建議你先直接聽取其經理的建議，然後持續觀察，了解隊友的真實實力，再做合理的安排！這裡主要考察執行力即可：
二、沒有人能一打五，信任你的隊友，不同的角色有他該有的責任！
三、讓專業的人做專業的事情，不要不懂裝懂瞎指揮。不要去質疑專業同學的内容，因為你看不懂，你需要關注的是他的進度！
二、項目啟動模闆
從執行角度看，一個項目的完整周期是這樣的：
項目是十分複雜的事情，而剛好這件複雜的事，還會涉及非常多的人，本來要做好一件複雜的事情就很難了，然後一件事情涉及的人越多，那麼會更難：
除了事情本身專業度所帶來的困難，一般來說最大難度來源于兩方面：
① 溝通過程中産生的資訊不同步
② 做一件特定的事情（一類事情），總是會出錯
是以我們需要相對完善的方法論降低這種難度，首先我們需要一套【機制】來保證我們多數的資訊的上下文，以便我們要追溯某一段資訊的時候無從下手；其次我們需要一類清單，這種清單記錄了我們之前做某一類事情犯過的錯，清除所有的錯誤可能，那麼我們就會更容易達到成功，是以這裡給出了項目啟動模闆：
标紅的部分是必須提供的，有了項目啟動模闆後，我們會将之前的項目思想打散到這個機制中，讓你不知不覺便掌握我們所謂的節奏感。其中項目月曆大概如此：
三、确認風險
綜上所述，項目旁枝錯節過多，一個技術Owner想要把握每一個細節無異于癡人說夢，這裡便要求相信隊友（PS：王者榮耀再牛逼的英雄也不能一打五！）。
但是相信不是不作為，在我看來，一個技術Owner的80%精力應該放到最重要的風險管理，項目初便需要确認項目的風險點！！！
确認風險點，規避風險點，設計風險已發生的解決方案，是一個項目的重中之重！！！
那麼，如何規避風險呢？首先得找到風險點，于是需要定義什麼是風險點。我們做一個項目，需要窮舉（盡你之能）什麼是我們絕對不能接受的情況，這個可以是：
① 項目延期XX天（會不會延期、資訊不同步等等因素）
② APP崩潰
③ 訂單不能支付
④ 某頁面打不開
⑤ 充值有漏洞
⑥ 結算延遲超過底線
⑦ ......
不同項目會有不同的風險點，首先窮舉這些風險點，然後再看看我們要處理哪些風險點，這裡的規則是：這個事情會不會發生，如果發生你能不能承擔。
一旦确定要處理的風險點後，那麼技術Owner的工作便已經确定下來了：解決掉所有的風險點，其他全部交給隊友（風險點産出時間見上面最複雜那個圖）
這裡擔心各位疑惑，再啰嗦幾句如何确認風險點：
① 項目初期，根據過往經驗（有些項目是周而複始的、有些項目是同一類型的），判斷可能會有什麼問題（技術Owner越高階，此能力越強），開始私下拉人讨論方案
② 技術評審階段，讓所有同學提出風險點，最終确認項目月曆
③ 評審結束後馬上整理所有風險點，并且私下了解細節，再拉風險評估會（技術評審後一天内），與隊友确認風險點，并要求隊友提供對應方案
④ 如果風險點技術側不能繞過，馬上拉營運、産品商量規避方案
⑤ 如果不能完全規避，與對應同學設計如果已經出問題的項目補救方案，和觸發機制
這裡會有很多的案例，都有環境因素不友善提出，大家可以***整理自己公司的案例。
當然，雖然我們期望能前置所有的風險點，但這往往是不可能的，風險可能在項目的任何階段（包括結束階段）爆發，是以項目日會很重要！！！
四、項目日會怎麼開
所謂項目日會，也是執行日志（用以追溯整個項目）重要的内容來源，很多同學常見的問題是：日會時候各自說下你做了什麼，我做了什麼，然後自以為是的拼出了一個“虛假的”項目完成度，這是大錯特錯的！
項目日會的真正意義是用來暴露風險的！或者說項目日會是用來幫助你梳理項目風險點的，這裡真實的流程是：
① 開項目日會，對照項目月曆（時間表）看看今天應該達到什麼進度
② 哪些子產品晚于這個進度，找出為什麼
③ 清理出要幫助那些隊友的清單，并且當天重點幫助解決
④ 如果日會暴露出項目風險點，必須馬上更新
⑤ 不停的處理日會中暴露的清單
其中很關鍵一點是确定誰在什麼時間點達到什麼！并且我們需要記錄項目過程名額資料：
如此一來可以反映出目前真實的項目狀态，大家也知道症結點（風險點）在哪，而技術Owner需要将更多的精力投入到這個風險點，如此下來可以進入項目提測階段，技術Owner需要将節奏點的大棒交給測試同學了。
五、測試階段做什麼
開發聯調結束，終于進入了測試階段，這個時候研發同學很難再自己找出問題，技術Owner同學也不需要對着case一個個過，但是這不代表技術Owner的工作結束了，他需要做的事是：
① 通過測試同學的視角找出目前項目的風險點是什麼，納入日會todolist，然後去解決
② 站在研發的角度協助測試同學補足測試方案（可能不需要），因為測試同學可能會因為環境問題、資料問題、邊界問題無法完整覆寫整個case，技術Owner要帶領研發同學補足測試同學的短闆（可能沒有短闆，那當然最好）
這個階段結束後，便需要進行非常重要的預演環節
六、如何預演
預演是非常重要的環節，很多bug都可以在預演環節被幹掉，這裡不是因為測試同學不努力，不能把那些BUG過掉，是因為：
① 預演環境有真實的龐大資料
② 預演環境的能還原真實的QPS，會覆寫掉很多邊界場景
③ 有些測試必須在生産環境進行
④ 預演需要做方案，不能引起線上髒資料
有了這些東西就可以進行預演了，然後這裡有一個最大原則：預演請務必盡可能還原真實場景，包括時間點的設定！！！
預演前，越是緊張的時候越是容易出錯，是以我們需要準備一個上線清單&執行流程，他大概長這樣，可以設定得更嚴格：
這裡再突出強調下幾個點：
① 盡量還原真實場景，特别是真實還原時間要求，如果一些環節涉及人太多需要重複進行
② 一旦确定執行流程，拒絕任何騷操作，拒絕任何加塞！！！
至此一個項目就接近尾聲了，我們便會進入複盤環節
七、如何複盤
複盤相關的文章網上居多，比如這個很好：
https://www.jianshu.com/p/48a37c310639
這裡而外提一點就是，很多技術Owner的複盤隻是到執行側結束便停止，也許可以将目光看的更遠，除了業務側，也需要知道項目側的複盤。
八、結語
至此，項目執行指南的主要部分介紹就結束了，帶項目如打遊戲，是一個人能力的展現，這個能力包括：
① 實際能力水準
② 個人魅力（勢能），比如夢淚打野輔助就跟願意跟随
③ 環境（團隊）加成
結合之前的文章，我們放出一張圖：
不同的項目需要不同的能力與勢能，要帶好一個項目，大家可以從這方面努力。抛開基礎能力問題，做成一件事最重要的就是持之以恒的認真，而能力的進步也是源于此。
“我隻是個舉人出身，出生于海島蠻夷之地，沒有你譚子理的舉薦，我連區區七品縣令也當不上，最多當滿這屆南平教谕就回家侍候老母了。我不明白，趙中丞、譚大人你們何以把我海瑞看得如此之重！”“無非是我海瑞辦事認真而已。”
——大明王朝
這裡再回顧第一篇中的五維能力模型，持之以恒，這個可能會影響我們走到什麼位置吧。工作中有很多不平事，成為某個關鍵角色後也容易産生很多委屈，事實上我有時候也非常負能量，及時排解即可。
九、QA案例庫
9.1 項目出問題怎麼辦
Q1：想知道面對陌生的環境下，時間緊，人不足，所有人做的事陌生，風險點評估不全，這種怎麼帶，如何把控。
Q2：1.在高壓時如何處理團隊的負面情緒（如何協調好團隊分工）2.如何收集項目資料（次元）3.怎麼感覺風險
多數同學都是王者榮耀玩家，這個問題其實就是在說我們面對逆風怎麼辦？那麼逆風翻盤的常見錯誤是：
一、 任何形式的放棄
包括放棄技術評審、放棄風險預估、放棄技術方案，越是逆風的情況下，關鍵的風險預估越是必不可少，因為所有的必要步驟都是對你項目失敗的兜底方案，隻要你一個個放棄這些兜底，那無異于在裸奔，失敗的風險大大提高。
這裡一個真實案例是之前一次重要項目，由于項目資源緊張，核心開發技術方案遲遲不能給出，一段時間裡面甚至想放棄寫技術方案，直接上手代碼，這裡可能的風險是：
① 項目壓力大的時候容易做錯誤的決定
② 沒有技術方案，就是沒有計劃，沒有計劃的事情失敗的機率會高很多
③ 在極大的壓力下，失敗的第一步會導緻持續的失敗進而引發雪崩
我們當時的處理方式是，與王者榮耀的方式是一樣的，法師死了（該同學時間不夠），打野（技術Owner）補位守中塔（想方案），等他複活（緩過勁來）。是以很多邊界問題、困難的點，已經由技術Owner幫助補齊，不至于讓這條線成為敗因。
在這個案例裡面技術Owner的補位非常關鍵，而技術Owner補位的前提是：
① 提前梳理項目風險點，知道哪裡容易成為突破口
② 技術Owner深入業務，而不是瞎指揮
二、任何形式的團隊内讧（甩鍋）
王者逆風不重要，隊友心态很重要，一旦隊友心态崩了，那麼馬上就會引起吵架，整個團隊散了，失敗也就不遠了：
真實案例抽象，有個項目選取了不是最合适的技術Owner，是以有了這個故事。
小王第一次做技術Owner，十分想做好這個事情，但是他勢能不足，是以團隊的小夥伴有些我行我素，弱小的小王盡力的推進着整體項目，但在執行過程中依舊出了很多問題，于是他跟組員在群裡吵起來了，雙方經理看不下去，也加入了争吵的隊列，這裡的兩個點是：
① 技術Owner認為對應同學對項目不上心
② 一線同學覺得技術Owner不懂瞎指揮
雙方經理也各執一詞，執行情況十分糟糕，最後項目也出了一些事故，大家都收到了慘痛的教訓，回顧這個事情，這裡就出現了幾個關鍵問題：
① 執行不當，沒有提前找到項目風險點，或者說之前的兜底方案不足，也沒人補位，項目進入逆風。
② 逆風時候，整個項目成員開始甩鍋吵架。
③ 技術Owner這裡不出于大局的考慮，穩住團隊心态争取最後的勝利，而是開始抱怨委屈加入戰鬥（我尼瑪4-8的開局被你們這些犢子拖成這樣？）。
④ 雙方隊員教練（經理），沒有去協助穩住局面，而是加入了甩鍋、吵架環節。
有了以上表現後，這個項目多半是做砸了，我們這裡比較好的情況是，更高的leader乃至教練介入，将紛争抹平了，最後項目順利上線，後面雖然出了一些問題，但整體項目成員的心态已經好了很多，是以解決這個問題的方案是：
① 技術Owner決不能參與吵架，更不能甩鍋！！！leader絕不允許加入戰鬥！！！！！！
② 在團隊逆風或者出現沖突時，更多的去發現項目風險點，解決項目風險點
③ 當技術Owner感覺控制不了局面時要及時上抛問題求助
總而言之，敗方MVP無意義！
9.2 團隊逆風怎麼辦
Q1：人的因素，例如如果一個項目有新人該怎麼處理，技術Owner本身節奏有問題該怎麼處理？技術Owner的時間配置設定，技術Owner期間時間是被打算的，不好安排自己的工作。
Q2：1.在高壓時如何處理團隊的負面情緒（如何協調好團隊分工）2.如何收集項目資料（次元）3.怎麼感覺風險。
前面大概回答了一些這些問題，這個問題很典型，為了規避工作敏感性，這裡依舊從王者的角度來說，需要兩個層面的能力：
① 意識能力
② 操作能力
比如如何感覺風險是常見的意識能力的展現；如何做時間管理就是操作能力的展現。這樣說依舊有點虛，這裡做一個類比，意識能力的四個次元是：
① 你知道草叢裡面有人，是以你不進去
② 你知道草叢裡面有人，并且有什麼人，是以你不進去
③ 你知道草叢裡面有什麼人，并且你告訴了你隊友
④ 你知道草叢裡面有人，并且告訴了隊友，并且制定了合适的戰略取得了成功
而操作能力的次元是：
① 隊友告訴草裡有人，但我腦袋一熱非要沖過去，并且死了
② 隊友告訴草裡有2個人，我評估了自己的操作水準，沖了上去并且死了
③ 隊友告訴草裡有3個人，我評估了自己的操作水準，對面的經濟情況，依舊沖了上去，并且拿了三殺！
意識好便不需要以少打多，很難進入逆風；操作好就算進入逆風也能Carry全場，但是任何形式的死扛都是有風險的，沒人能一打五，思維一定要清晰，是以意識 > 操作
而好的技術Owner對意識、操作有一定要求！
上面的回答很簡單，但是提的問題卻很複雜，相當于一個白銀的同學問王者，你為什麼知道草叢裡面有人或者你為什麼能一打三？
回到項目，為什麼有些技術Owner能夠很快發現項目的風險點；又為什麼有些技術Owner能輕松化解項目中的風險點，這裡有兩個答案：
① 第一個很簡單，多帶項目，多看複盤
② 第二個很複雜，需要天賦，提升軟素質
正如一般同學上王者很容易，但上王者百星很難是一個道理，沒有什麼事情能一蹴而就，我的知識，說一次也不能變成你的知識。
可以做的就是提供更多已經實踐的方法論，留給有心的同學去學習，比如這篇文章。
前面是在說一個技術Owner如何不會崩（其實整篇文章都在教大家如何不要把項目帶崩），這裡的主旨依舊隻有一個：提高意識，提高操作，更落地一點的回答是提前找到你項目中的風險點，并且幹掉他。
但不可避免，我們依舊會遇到技術Owner已經崩了的場景，正如上一個大問題所述，這裡事實上我們是有一個機制的，要麼技術Owner自己會上抛風險，要麼我們測試的同學會上升風險，如果我的李白已經不能翻盤了，那麼就讓夢淚來操作我的李白吧，也就是換他的leader給他兜底！
9.3 如何處理三方依賴
Q1：方案設計時遇到問題：A、B兩個方案都可以滿足目标。A：偏一次性方案；B：通用方案。工期都滿足的前提如果選A，後續功能開放，又需要額外的重複工作；選B，執行方不一定有動力，推進阻力大
這個問題看上去很簡單，處理的時候卻很複雜，這裡問題稍微更新就變成了，項目要不要做基礎技術建設？更誇張一點，我要用Word要不要開發作業系統？
PS：這裡YY的一句就是，100個頂尖科學家回答古代也很難産出，原因便是三方基建依賴。
其實答案很明顯，站在技術Owner的角度，任何可能引起風險的因素都應該被幹掉，是以是不做；但是站在更高的角色來說是可以做，隻不過是什麼時候做罷了：
① 項目資源寬松則規劃做起來
② 項目資源緊急，則複盤後規劃做起來
處理的三大原則：
① 你的項目不應該推動“其他項目”建設（例：活動不應該推動基礎能力建設）
② 如果“其他項目”是你項目的關鍵實作路徑，那麼你必須推動其實作。規則二大于規則一
③ 如果“其他項目”一些特性不是你的項目依賴的，那麼不做處理
這個問題再引申一下是，如果第三方項目出了事故怎麼辦，這裡的回答是：
① 如果你依賴的“其他項目”核心路徑出問題，需要你推動處理，如果是因為你的項目而開發的子產品出問題，需要共同承擔
② 如果“其他項目”由于曆史問題出問題，影響你的項目，需要push處理，他們自己承擔後果；如果不影響你的項目，需要善意提醒即可
之前leader有一句話我很贊同：
主責對齊根因，整套懲罰方案看價值導向。前一句是法理，後一句是引導，引導是衆多利害之中，讓群衆關注什麼，前者看曆史，後者顧未來
如果“其他項目”是你項目的核心依賴項目，那麼該項目便是你項目的子項，你對“其他項目”參與配合的同學有絕對的“使用權”，你可以要求他放下其他工作，而專注于你的項目，除非得到你的允許
如果你的項目獲得了什麼榮耀，那麼你核心依賴的項目也應該共享該榮耀
9.4 如何處理事故
雖然學了很多方法論，卻依然出了事故，這個時候大家不要灰心，放平心态即可，因為一個項目越大出事故的機率越高，到一定規模的時候，不出問題反而是奇怪的。要做的是不在同一個地方摔倒（事實上還是容易在一個地方跌倒，原因是那個地方就是容易跌倒......）！
出問題是不可避免的，一定要複盤反思當初哪一步決策走錯了，再給一次機會能不能更好，下次突發了能不能快速carry。
雖然出事故不可怕，可怕的是我不知會出什麼事故，是以事故需要分為兩類：
① 在項目過程中整理出來的項目風險點
② 預料之外的事故
這裡處理的辦法是，如果是預期中的風險點，那麼在【技術評審】後一定會有【風險評估會】來處理這個問題，如果評估不能規避，那麼就需要提供已經成事實的項目補救方案，這個時候出事故便按照補救方案操作即可。
比較難辦的是出現了不可預知的事故，這個時候的處理原則可以是：
① 及時上報
② 及時集合相關同學商量初步方案
③ 以對使用者影響最小的方案執行，技術Owner要敢于背鍋，敢于下決定
④ 收集足夠的資訊，為恢複問題做準備
⑤ 複盤，規避類似問題發生
這裡需要注意一點是：不同公司處理方法論不一樣，切不可生搬硬套！
9.5 複盤做了那麼多，有用麼？
Q：複盤本意是好的，但是怎樣付諸實踐我覺得更重要，希望在文檔裡面列一些比較實際意義的案例，怎麼解決此問題
這個問題是很多同學的疑惑，這個問題其實引申一下就是，我做了那麼多CaseStudy（後續有文章介紹），又有什麼用了呢？
抖機靈的說法是：容易在一個地方跌倒，原因是那個地方就是容易跌倒......
進一步探讨，一線同學的意識形态比較低，會更關注在具體問題本身，或者如何解決特定的問題，這個可能會導緻一個錯覺：CS的會上，有很多大佬們的正确主義，基于正确的道德制高點，提出的絕對正确的廢話，這種東西似乎對一線同學指導意義是有限的。
這種認識一定在我們一線的同學中存在，如果不存在大家都是leader了，比如有多少同學會認為這篇文章是無用的廢話呢？
正是因為我們做了很多複盤、CS，我們才會沉澱更多的方法論。
所有的這些東西，都是需要大家把自己的視角往上提一個層次才會有用，帶有關注的眼光才能發現很多事物真正的價值。
很多一線的同學看到了在一個複盤、CS中的一個具體的問題沒有去解決，但是大家沒有意識到，這裡主要的原因是解決事件層面的問題多數時候是無效的，比如此圖：
規則如此，一旦有外部刺激就一定會出事件，正如紅燈停，做項目就一定有BUG一般。
這裡的點是，管理不會解決你看到的這一個問題，管理會設法去解決這一類問題，或者是大家都忘了，需要提醒，是以重複的CaseStudy才會不停的上演，因為大家還需要努力，CS以及複盤todo也确實為部門宏觀建設提供了資訊輸入，而這一切中很大一部分其實是偏自律、個人問題導緻的部分，當事人自身應盡的責任或義務或規範或标準，不能完全期待管理給出解決方案，這也是為什麼會有上文中的OKR：
OKR的意義是幫助團隊培育目标導向與結果意識，并且加強我們的跨部門合作，進一步幫我們識别團隊中隐藏的潛力股（人才），并且給他們塑造表現自己的舞台
于是在以人為本的前提下，這句話就是團隊中核心的人才會提出幫助團隊前進的目标并擷取資源執行，而比較功利的說法是提出好的OKR并且成功獲得資源執行的人會成為團隊核心人才，這裡的需要我們思考的點是：
① 好的OKR需要善于思考并且真實了解團隊痛點的人提出
② 團隊資源是有限的，是以隻有好的OKR才會擷取資源并執行下去
9.6 需求頻繁變化怎麼辦
需求變更，在每一個項目中不停的上演，這個是上遊項目把控不力的表現，而所有的這一切被技術Owner給C點了，事實上是技術Owner在補位
雖說如此，正如不會出現不出事故的項目一樣，也沒有需求能做到100%完整。
我們要如何應對這種時間點固定，上遊需求不停更改的項目？
解決這個問題的方案其實更簡單，兩個字足以：加班
如果加班不足以解決問題，那麼需要向上申請資源，如果項目足夠重要，那麼上遊會給予你足夠的資源。當然，加班也是不可避免的
原則很簡單（上遊并不是不講道理的）：
① 你影響我項目的總體目标就做二期
② 如果不是核心功能，我不會給你加
凡是預則立，不預則廢，可以有一次項目頻繁變更需求，如果這個是常态的話，就需要複盤，那麼這個團隊往往就會出問題或者出現變革。
另外，要提前切入業務方，做一個研發接下來的季度乃至半年規劃，前置準備，包括技術、流程群組織結構的準備，不要到業務來時潰不成軍。