前言
2021年沒怎麼寫文章，狀態很是不太對，包括現在狀態也是不太對，寫這篇文章，開啟了typora，發現竟然新版本要收費了，看來確實是好久沒開啟這個軟體了。可能是因為之前在國企，事情沒那麼多，除了趕專案的時候要加班，其他時間都還好，工作上也沒有很強的績效壓力。空閒時間一多，每天學學技術、寫寫文章，都還算是比較愜意，唯一的缺點，可能就是技術挑戰不大，錢也比較少，日子緊緊巴巴的。
2021年在鵝廠幹了滿滿一年，說實話，還是比較累的，而且，累的方式不太一樣，手上做的事情，用到的技術倒是沒多大挑戰，主要是心累，手裡的事情做得並不好，沒有拿什麼獎，績效也相當一般，組內沒有影響力，感覺就是，瞎忙了一年，班加得不少，但好像沒什麼效果，沒得到外界認同。
一年兩次績效，半年一次，上半年是組長A打的績效，然後年中的時候，組長A離職了，出去朋友公司當cto去了；下半年，換了一位組長，組長B打了下半年績效。兩次績效的結果都一般，先不扯什麼pua之類的，那基本還是能說明一些問題的，至少還是要反思下，怎麼去適應大廠的這種職場環境，怎麼在這種環境下活得好。
所在小組的職責介紹
我們組呢，是做運維平臺的，使用者呢，是研發人員，比如開發、運維，我們這邊是偏向於管控：對線上環境進行的各種變更。
線上環境的變更，有很多種類，比如網路、儲存、防火牆、作業系統、中介軟體、業務應用程式，部分由運維負責，如網路、防火牆、部分中介軟體；部分由開發負責，如業務應用版本迭代。
最簡單直接的變更方式，那自然是ssh登入上去一頓操作，經常還是root登入；這樣的風險無疑是比較大的，小公司還能忍，大公司是肯定接受不了的，要是來個刪庫跑路，影響巨大，所以，自然需要做成各種內部網站、工具、指令碼，去把這些工作安全、高效地進行。
既然是做給內部同事用的，那可以想象，內部同事和外部客戶是不一樣的，資源投入少得多；比如，微信這種程式，服務外部客戶，那基本上人力資源非常充分，各類工種非常齊全，比如產品經理負責需求收集、分析、原型圖設計；UI負責如何讓介面美觀大方；前端負責將UI設計的介面，轉化為實實在在的系統介面；後端負責提供介面。
我們這邊不一樣，我們一個人 = 產品 + UI + 前端 + 後端，產品這塊，有些需求靠自己想，領導就是很抽象的幾句話：“我希望達到xxx效果”，“我想xxx”，意思就是，領導可能也不知道具體要怎麼做，只有一個目標/指標；有些需求，來自於周邊合作團隊；有些需求，來自於使用者投訴吐槽、客服系統。抽象需求拿到後，接下來，你還要轉化為具體需求（至少要讓UI/前端/後端能夠明確知道要幹啥），具體需求的承載形式，一般是原型圖。原型圖ok後，UI這一步，我們這邊基本是沒有的；前端、後端階段，需要根據原型圖去做實現方案，實現方案也不是我們自己就定了，還需要拉會，讓大家評審。評審通過了才開始去具體開發程式。
2021上半年--新員工的我為啥總在返工
過程
上面花了好多篇幅，去介紹小組的現狀，是有必要的，可以看看我下面的經歷。
我們組這邊，對於新員工，一般是給一大塊的新的事情，比如3個月試用期內，自己一個人做一個新系統、新模組，由於是新系統，此時還沒人用這個系統，不涉及維護，不需要當客服去處理使用者使用中的各種問題；我猜測，領導的考慮是，這樣方便考核成績，也方便考察這個員工自己一個人做事、獨當一面的能力。
我進來就分了這樣一個新系統，完全全新的東西，這中間就涉及我上面說的，一個人要充當好幾個角色：產品 + UI（內部系統好像不需要這個）+ 前端 + 後端。
一個全新的東西，自然是長什麼樣子都不知道，剛開始，瞭解了大概的需求文件後，知道了要做啥事情，但是，介面/流程怎麼設計，這個是沒有的，要靠我自己去解決。
那時候就是開會。組長，導師，在白板上面畫，講要做成什麼樣子，但是呢，白板又能承載多少東西，很多東西都漏了，等到具體去做的時候，發現自由發揮的空間非常大（比如是點了一個按鈕後，是直接彈框，還是新開啟一個介面；展示幾個並列的東西時，是用tab元件，還是用步驟條上一步下一步這樣串起來）。
就是因為自由發揮空間很大，一開始呢，我就和導師（鵝廠制度，導師就是組內同事，前面會有導師帶你幾個月）確認要做成啥樣子，比如用彈框而不用新節目，設計成這樣而不是那樣。
做了一個月，一小塊功能基本成型後，拿去給組長看，結果組長提了好多問題，覺得和他設想的很多不一樣，然後組長一般喜歡用筆記本，我們的網站是基於大螢幕設計的，基本沒考慮筆記本（適配筆記本很難搞，而且我們基本都是業餘前端工程師），組長筆記本開啟網站一看，那叫慘不忍睹。
於是，開始按照組長的意見改，改了之後又拿去看，總之就是這樣反反覆覆。加班加得飛起，全是在返工。
然後中間做著做著又有各種新問題，新問題出來後，就拉會議，會議就說：那再加個這個功能進去，反正這個沒上線，就趁著這次做新系統，把這個問題一起解決了。 總之，中途就臨時又收穫了不少需求，然後就做，依然是做--檢查--返工，只是慢慢地，系統穩定了，返工會少一些了。
最終呢，3個月轉正的時候，系統還沒開發完；到半年的時候，系統也才勉強上線。
最終半年度績效非常一般。
該階段的總結
其實這中間暴露了很多問題。
返工的問題主要是溝通問題，包括溝通形式。人的記憶是不怎麼可靠的，光靠說，聽的那一方，能吸收多少呢？ 尤其是，這中間還涉及到了3個人，我、導師、組長。剛開始，看組長非常忙，就和導師溝通，確認要做成什麼樣子，等到功能做完了，才去找組長驗收，組長自然有自己的想法，比如掌握的外部資訊更多，知道使用者到底需要什麼，使用者的核心痛點等等。於是，組長覺得這個設計有問題，自然就要返工。
所以，這裡的問題確實是我自己的問題，我在上家公司，只需要做後端，沒有做過需求分析這類工作，需求都是有產品經理弄好了給我們，只需要照著做即可。這裡的問題，就是需求分析工作沒做好，如果是我現在來做的話，肯定是要學習畫原型圖的，在2021年下半年的工作中，我也確實吸取了教訓，開始畫原型圖，然後拿著原型圖和前端後端方案，拉會議，讓大家評審。
其次的問題是，需求管理的問題。這個系統，剛開始是預期3個月，但是做著做著發現了一些沒考慮到的問題，然後相當於臨時加了需求，導致整體的時間大幅度往後了。當時也沒有需求優先順序管理的概念，組長這麼說，那就這麼幹唄。其實，當時也可以先上線一個版本，再逐步迭代，至少，最終說起來不會是，一個系統，搞了大半年沒上線，對外部也會有個交代。
2021下半年
過程
經過上半年的事情後，下半年感覺做事好了很多，在快打績效的前一個月，甚至自己感覺應該績效還可以，結果沒想到又是個悲劇。
手裡的系統其實是兩個子系統，上半年搞得是子系統B，子系統A是同事做的，但是做完子系統B後，組長讓我把子系統A也接手過了，因此，就同時維護A、B兩個子系統。
同事做的那個子系統，在我接手過來後，下半年又來了好多需求，我就去做這些需求去了；而我原來手裡的系統，雖然說上線了，但其實用起來還是有點磕磕絆絆的，有些小bug和使用者體驗上的問題。
同事那個子系統，下半年接了好多需求，都是外部團隊的，外部團隊動不動就讓你確定個日期，類似於deadline那種，就是讓你承諾啥時候可以搞定。ok，比如我基於6月份當時的工作量，估一個時間，假設是7月中旬交付需求；但是，你發現，6月又來了一些緊急需求，導致你時間被極大壓縮了，你就只能加班加點地趕在7月中旬把那個需求搞定。下半年基本就是這個子系統的需求就沒停過，我也是一直忙著滅火一樣，去搞定各個需求。
由於需求多，又時不時插入緊急需求，其實有些需求的交付質量也一般，因為我趕著把手裡積壓的需求做完。
到績效考核的時候，結果，組長的意思是，我上半年那個子系統，收到了不少使用者投訴，評價不高，因此績效就一般。
我當然可以說，你看我做了那麼多需求（都是同事那個子系統的），接手的那個子系統，評價很好啊，沒多少使用者投訴啊。但是，組長說的問題也確實存在，兩個子系統，一個投訴多，一個投訴少，那重點到底是哪個呢？
該階段的總結
下半年的問題在於，需求的優先順序管理很有問題，對於自己的核心目標（okr裡寫的核心目標是要保證我自己那個子系統）沒有做好。
需求優先順序管理，不只是我存在，在組內其他同事那裡也廣泛存在，大家事情都很多，那要怎麼去決定精力分配呢？
-
放棄“把事情做完”的想法；我算看明白了，大廠的事情那是真的多，這啊那啊的，事情是做不完的
-
既然做不完，那應該怎麼辦呢？在外部需求這塊，要仔細去了解需求背景，有時候一個人給你提出的需求，不是他真實的需求，你挖出他背後的真實原因後，你也許可以提出更簡單的做法，或者是發現這個需求，放在別人那裡做，更合適；如果發現需求確實是應該在自己這裡，那也不能一口答應一個準確的日期，而需要綜合自己手裡的所有事情後（可以在組內的週會上，提出來，讓組長和其他核心成員去判斷這個事情的優先順序），再去對外溝通，同時也要避免太絕對的承諾，萬一有臨時緊急需求，可能就會導致承諾未兌現；給承諾的時候，也儘量不要給對方過高的預期，儘量不要用那種“絕對”，“完全沒問題”這樣的話，但是，一旦我們給了承諾，我們就要做到，同時，還可以比他預期中的，做得多一點。
這個也是組內大佬教我的，低承諾，超預期。
-
再說一下優先順序的問題，一定要確保先完成自己的核心目標，其他需求，可以往後排，拿不準的，可以找組長溝通
其他感悟--拿資料說話
在做一個需求時，通常不止有一種解決方案。每種解決方案，有其自身的優缺點，對於我們一線開發來說，有時候可能明顯感覺某個方案更好。
但是，拿這個方案去會議上討論的時候，大佬們一般思維很發散，通常會問你：現線上上的xxx現狀是怎麼樣的，有沒有相關的資料。
這時候，如果沒有提前做準備，基本是答不出來的；所以就要求我們，在提出我們的方案時，儘量要有資料支撐，而不是空談，比如，為啥用快速排序而不用氣泡排序。你可以說，快排就是好。這時候大佬問你：有沒有拿線上資料做個測試，看看各自花了多少時間？你可能直接懵了。
這也是鵝廠鼓勵的一點吧：拿資料說話。
其他感悟--做產品的思路
這個也是組內高績效大佬教我的，非常感謝。
做產品，一般是提供某個服務，一般會有個主流程。比如之前用滴滴單車，當時有個活動，領騎行卡之類的，我就跟著流程走，大概是要綁卡還是幹嘛來著，走著走著還要我手持身份證拍照啥的，我嫌麻煩，就沒弄了。
這個就是主流程不順的一個體現。
大佬給我分享的是：
- 主流程要順，要快
- 每天自己去用一下這個流程，自己發現問題，看看自己願不願意用；而不是等到使用者投訴了再來改。可以看看相關錯誤碼、耗時等
- 針對發現的問題，不斷去優化
- 找一些使用該系統的使用者，和他們溝通，聽聽他們的想法。如果負面反饋較多，可以安排個優化專項，優先順序可以和組長商量
只是，這些觀點，我現在好像也還沒去實施，依然忙著手裡的各種需求，這可能就是績效差距的原因吧。
2022年，準備按照這個流程試試。
總結
我也畢業好些年了，前些年，喜歡看小說+文學，最近幾年基本只看技術+少量歷史，而現在，我覺得，我們也要看一些書：關於做產品、關於個人管理（如時間分配）等，入職鵝廠的時候，公司發了一本：《卓有成效的管理者》，之前我在想，我一個大頭兵，懶得看你這些雞湯，最近思想改變後，看了下，裡面就有需求優先順序管理相關的觀點--要事優先。 所以我覺得如果有人和我一樣，以前從不看這些雞湯的話，也可以考慮看兩眼。
上半年，組長走的時候，已經是12級專家的他（鵝廠幹了16年還是17年），送了幾句話給我們：
最後送上我理解我們這型別職場上的9字方針，“多想事、幹好事、會呈現”。
逐日於2022年2月12日，於寶安圖書館