書接上文：
繼續整理技術團隊最近的年終盤點，【採用我問他答的形式】主要是聆聽，這裡是跟第三位同學質效負責人脫敏後的交流。
公司是兩地辦公，技術管理團隊多是3周北京1周成都的節奏，在北京會很情況，所以多數同學不願意過來，這位同學是公司的老同事，也是主動要求來北京，我們先來看看他一年以來自我認知的變化（美女看手相嗎，我們聊聊管理玄學？）：
可以說沒有什麼變化，是「保持初心」的經典案例了，那麼這是為什麼呢，我們一起來看看。
你是什麼樣的人
我是一個接受「變化」的人
「變」這兩個字，應該是貫穿我 2021 全年的一個關鍵詞。
在這一年裡，發生了太多的變化:
- 組織架構在變化
- 參與的業務在變化
- 在團隊中的角色在不斷變化
- 工作的時間和空間在變化
- 自己的視野也發生了變化。
這裡首先說下業務上我做的一些事情。
業務開發
AB Test
常規的業務開發已經難以提升我們的技能，技術對業務一般來說也不會有什麼感知，不過今年有變化的是產品同學一起開發了幾期通過「AB test」來驗證設計方案的需求還是很有意思，也收到的很好的效果。
整個業務大約持續了三期，主要針對的是使用者購買的流程優化，希望通過產品上的改動來提高使用者在購買流程上的便捷性，進而提升患者購藥的轉化率。
業務本身其實不復雜，不一樣的點在於這個需求會跟資料有比較強的關聯關係，如果要對比不同的方案哪個效果更好，肯定要先拿到準確的資料才能支撐最終的結論。
之前雖然我們的產品裡也有埋點，但更多的是把資料記錄下來，至於怎麼用，其實並沒有很好的方案或者體系。
調研下來雖然接入了GIO，但是卻一直沒有利用起來，於是正好利用這個機會好好研究了一下GIO。研究完發現，我們還真是連皮毛功能都沒怎麼用。
學習完GIO提供的課程再思考業務的需求，最終建立出了下面這個看板，裡面包含了大約30-40張單圖，有漏斗轉化，也有資料對比（全圖過於敏感不能放出來）：
有了資料看板，剩下的事情就簡單多了，只要資料採集正常，AB方案的結果就會很直觀的反映出各自的效果，最終我們也收到了很可喜的效果，復購率有明顯提升：
這個事情有2個點比較有感觸 ：
- 資料的魅力
資料能夠直觀的反映我們所做事情帶來的效果是否符合預期，合理利用資料
- 有時候不是工具不夠好，而是工具沒用好
GIO 本身提供的功能還是比較多的，雖然我們不是尊貴的 VIP 使用者，但是合理利用的話還是能夠幫助我們看到很多業務上的問題和癥結。
你有什麼心得
Owner意識
今年組織架構進行了多次調整，自己所在團隊的人數也在起起伏伏，在這個過程中，自己也一直在摸索怎麼才能讓團隊更加凝聚，怎麼才能讓團隊更有活力。
在下半年的時候開始讓組內每一個同學都去owner一次A級以上的專案，並且要求自己只觀察，不插手。
開始還有點放不開，總擔心比如 xx 同學剛來，對其他部門同事不熟悉，yy 同學對某塊業務不熟，可能會踩到很多坑，但其實一直這樣下去，既阻礙了組內小夥伴的成長，同時自己也揹負了過多的壓力。
某個月底在和組內一個小夥伴做 one one的時候，問他 owner A 級專案的感受，他說最大的感受是資訊量很大，關注的點也會變的很多，之前只需要管好自己的一畝三分地，owner 了以後需要對整個需求都瞭如指掌才能更好的管控專案的進度和質量。
其實當 owner 還有其他的好處，比如可以提高自己的大局觀，會從更高的維度去觀察這個需求，有時候侷限在自己範圍內的問題，如果能站在更高層次去尋找解法，往往能取得意想不到的效果。
OKR
今年我作為執行者和組織者共計參與了兩個季度的OKR，在執行過程中，體驗了OKR管理方法的完整流程，也在過程中體驗了OKR是如何指導大家推進和跟蹤整個專案的。
在組織過程中，從另一個視角去感受了如何協調一個組織完成OKR的規劃和制定。但這2次 OKR 更多的只是有形，但是沒神。
我們每次都是從下往上開始收集 OKR 的內容，經過篩選後就開始執行，其實大家並沒有完全朝著一個共同的目標去前進。
我覺得 OKR 的精髓應該是幫助參與的人們目標一致，當做的事情與目標發生偏離的時候能夠快速暴露並校正，這樣才能發揮 OKR 的功效。
而這一切，我並不知道如何處理。
專案管理
之前做技術Owner時一直有個感受，覺得這個角色侷限性很大，因為對於一個專案而言，研發和測試其實只是這個專案中的一部分環節，有些時候甚至只是一小部分，它既不是最開端，也不是最終局。
在一個專案中，限制你的因素就會很多，比如整個專案的上線時間會限制你的 deadline，但是你又沒法去限制上游給你提供內容的時間（產品，UI），所以一旦遇到待排期的專案，往往下游就變的苦不堪言。
9月份的時候開始參與公司 PMO 的一部分工作，期間突然接到一個任務，需要做集團子公司 ERP 切換的專案經理，雖然之前有一些理論知識儲備，但一直也沒機會實戰一把，正好有機會可以實戰，在大致瞭解了專案背景後就走馬上任了。
這個專案有幾個挑戰
- ERP 之前完全沒有接觸過，對專案內容本身不熟悉
- 專案干係人多為子公司的業務人員，之前完全沒有打過交道，對專案成員不熟悉
- ERP 切換會有哪些風險，在不同階段需要注意哪些內容並不清楚，這個相當於對專案流程不熟悉
- 對 ERP 中的業務不熟悉，在和廠商對接需求的過程中可能會被“忽悠”
在這個過程中有幾個環節印象深刻，也學習到了很多東西：
專案延期
首先是專案延期了，專案沒有按計劃上線，延期了一個月。
專案延期並不代表專案是失敗，因為最初「盲拍」的上線時間有問題的，這是我犯的一個大忌：
沒有對這個專案關鍵里程碑較真
我默許了這個時間是合理的，直到進入靜態資料整理階段才發現工作量之大，就算是全員9-12-7這樣工作也無法按時上線。
專案進行到這裡，我發起了變更，重新梳理了專案流程以及上線時間。
好在這個專案相對獨立，因此沒有造成太大損失，這裡得到的經驗是「不要盲目信任接受到的資訊」。
作為專案經理，要對專案中的關鍵節點負責，所以需要對所有獲取到的資訊進行獨立思考，儘早識別專案風險並制定應對措施。
後來發現一些其他問題，比如
A 部門就是幫忙的，還有自己的業務，沒法按照預期完成；
B 部門該對事情負責，但人力不足，進度肯定不能保障；
在來回拉扯後，身心俱疲，因為總有這樣那樣的理由等著我。
雖然我頂著專案經理的頭銜，並沒有很好的人脈基礎，所在前期推行進度異常緩慢。此時我調整策略，由管人轉變為管事：
- 任務拆解，把需要整理的資料進行分類並根據重要程度劃分優先等級；在表格中體現資料整理進度，一來可以統一大家的協作模式，二來可以通過進度體現每天的工作進展是否符合預期
- 開全員大會，在會上宣講合作模式並強調這個事情的嚴重性，然後在會上對所有任務進行攤派，由於子公司最大的領導也參與了會議，所以相當於每個參與的人員都當場做出了承諾
做完上面幾個調整後，效果還是立竿見影。幾個核心點是：
- 有一個大家都看得到的專案資訊視窗
- 有良好的風險預案
- 日會todo能夠落到人頭上
過程中還有一個事情令我映像深刻，作為專案經理，不能一味靠妥協來維持專案的運轉，需要軟硬兼施，在關鍵的節點採取合理的方式來確保專案風險被有效控制，舉個例子：
在跟乙方拉扯中，因為前期表現的過於和善，導致後來我們的需求不斷被延後，資源上的安排（比如研發支援）也很不及時。
此時我意識到必須改變這種現狀，於是再有一次沒有得到預期解決的晚上，我憤怒的撥通了乙方總部的投訴電話，對方承諾會在第二天給我滿意的答覆。
結果之前申請不到的研發資源在第二天協調到位，最終趕在 deadline 前一天完成了所有除錯和改造。
總體來說，ERP 切換這個專案還是有很多收穫，除了點亮了專案經理實戰經驗這個技能外，還獲取了批發業務進銷存的業務知識。
小釵總結
該同學的語文水平不高，交流過程中存在不少冗餘，結構也不太清晰，總結裡面反思部分太少，確實沒有太多認知躍升的點，算是一步一個腳印的擴充套件能力邊界，今年我們需要想辦法帶給該同學認知上的改變