書接上文：新晉總監生存指南三——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%完整。
我們要如何應對這種時間點固定，上游需求不停更改的專案？
解決這個問題的方案其實更簡單，兩個字足以：加班
如果加班不足以解決問題，那麼需要向上申請資源，如果專案足夠重要，那麼上游會給予你足夠的資源。當然，加班也是不可避免的
原則很簡單（上游並不是不講道理的）：
① 你影響我專案的總體目標就做二期
② 如果不是核心功能，我不會給你加
凡是預則立，不預則廢，可以有一次專案頻繁變更需求，如果這個是常態的話，就需要覆盤，那麼這個團隊往往就會出問題或者出現變革。
另外，要提前切入業務方，做一個研發接下來的季度乃至半年規劃，前置準備，包括技術、流程和組織結構的準備，不要到業務來時潰不成軍。