我們都渴望能得到導師的手把手教學，但這在多數(shù)公司里都是一件很奢侈的事情；真實情況大概是導師給了目標和方法，剩下的路自己走。如果遇到不負責任的導師，那就需要主動點去提問（提問也是一門技術(shù)）。

新人剛進入新的團隊或者在接手新的業(yè)務(wù)功能時，都會遇到這樣的情況：

我們要熟悉的資料很多，要了解的人員也很多，但作為新人普遍會存在一個問題：我看完這些資料后要應用到哪項工作，我該重點先了解哪一塊功能的邏輯以及迭代歷程呢？

在這些問題沒有弄清楚之前，我們其實是有點盲目瀏覽資料，并沒有在腦海里留下多少印象，或者短期過后就遺忘了。短期內(nèi)吸收大量內(nèi)容會造成消化不良，初入職場應該根據(jù)目的切分資料去消化。

回顧我的入職經(jīng)歷，才發(fā)現(xiàn)一腳一個印。我的Leader并沒有建立起我的入職規(guī)劃，在入職無任務(wù)的一周后，我終于在看膩需求文檔、數(shù)據(jù)之后發(fā)了一封郵件給她，大意是我把需求文檔都梳理了一遍，接下來我應該做點什么呢，我希望你能給我安排任務(wù)；

之后還是收到一封回件，當然也留給我任務(wù)，但沒有跟我說清楚這個任務(wù)關(guān)聯(lián)的文檔以及對接人，此后我便一路踩坑而上，逐步去熟悉業(yè)務(wù)流程、上線流程、成員情況等。

下面是筆者回顧自身的入職經(jīng)歷，寫下的經(jīng)驗總結(jié)：

第一部分： 熟悉功能框架、迭代歷史、數(shù)據(jù)表現(xiàn)

1）體驗App，了解功能框架，體驗操作流程

體驗一遍App，并產(chǎn)出體驗報告，形式可以是App分析報告或者競品分析報告，當然如果時間充裕，可以兩篇都撰寫出來；我最初是用Axure撰寫了分析報告，將產(chǎn)品主要功能細節(jié)描述了一遍，就發(fā)現(xiàn)問題嘗試提出了解決方法；

2）分析過往版本迭代情況，結(jié)合實際操作明確邊界邏輯

將歷史需求文檔過一遍，并用思維導圖將各版本的主要迭代點梳理出來，這大大方便日后查找；各家公司都應有自己的文檔保存庫，如果沒有或者查看很費勁，那就需要好好優(yōu)化一下。還有一個小渠道，就是通過禪道去了解每個版本的迭代概要，在禪道-版本計劃里可以查看，當然，這些都是看團隊的保存方法和保存平臺。以上思路僅供參考。

查閱過程的邏輯邊界需重點記錄下來，疑問之處一般出現(xiàn)在邊界狀況下的判斷。

3）熟悉核心指標的數(shù)據(jù)表現(xiàn)，盡量分析過去1年的數(shù)據(jù)

將數(shù)據(jù)查看一遍，條件允許最好翻看過去一年的記錄。解釋一下條件允許，平臺導出查看便易或者允許人工導出。為什么取過去一年呢，目的是了解趨勢變化狀況和數(shù)據(jù)的規(guī)律性，從數(shù)據(jù)中發(fā)現(xiàn)問題，一般從峰值處分析和提問。

最后，拿到數(shù)據(jù)后我們可以做一波分析，工具可選擇SQL或Excel，淺則就季度拆解取均值作為一個數(shù)據(jù)健康的標桿值，深則取a/b的值進行指標拆解，制作趨勢圖。

第二部分：熟悉團隊風格、需求上線流程

1）從身邊同事開始切入工作

剛進入新團隊，可能是默默無聞，但僅限1-2天，之后要跟同事打開話匣子。盡快跟自己的產(chǎn)品同事或者運營同事先熟絡(luò)起來，目的是了解清楚團隊內(nèi)部各司其職的人和事。

至于技術(shù)同事這邊的人事對應關(guān)系，能通過產(chǎn)品同事獲知最好，不然也可以通過禪道平臺熟悉各個版本的技術(shù)評審人，進而順藤摸瓜找到某塊細分功能的技術(shù)負責人，以便往后明確一些在文檔上沒有定義或者定義含糊的需求點。

我很幸運，遇到了一位開朗的產(chǎn)品同事，很熱情并樂意解答一些我的困惑；所以遇到一些經(jīng)過思考后仍無解的問題或者不熟悉的對接問題，都會找他問一問；此外，為了對團隊的更了解，我也跟運營的一位新人熟絡(luò)起來，好處當然是多跟她吹水，明確我們運營小伙伴的職責，日后對接需求起來就能準確許多。

2）了解迭代流程、交接流程、驗收流程

這里強調(diào)需求從收集到上線的生命流程，其中每一個環(huán)節(jié)的對接規(guī)則／責任明晰。比如如何提需求、有哪些干系人是需要關(guān)聯(lián)和通知到位。當然，新人多少都會踩幾回坑，才知道其中的流程細節(jié)。

我曾經(jīng)補充過一回需求，在評審通過后，關(guān)聯(lián)進版本并通知干系人，但溝通過程中的確是出了一點理解誤差。我告知了對方該需求已關(guān)聯(lián)到版本里，我以為我通知到位了，但在后續(xù)驗收過程才發(fā)現(xiàn)該需求沒有完成。

后來發(fā)現(xiàn)，技術(shù)同事這邊有另外一個項目文件夾，是跟產(chǎn)品需求文件夾分開的；當然，產(chǎn)品需求計劃是源頭，但過程需求技術(shù)負責人進行關(guān)聯(lián)操作。這樣才能落實到具體的開發(fā)人員身上并流轉(zhuǎn)到測試人員。

事后分析，判斷是需求交接習慣不同，我只是點明了我做了什么，但沒有明確告知技術(shù)他要做什么，而我認為他知道他要做什么，結(jié)果就出現(xiàn)了需求遺漏。所以說，在新人推進需求的過程中，要留意一些細節(jié)，通過多次確認、直接間接的方式去驗證，才能發(fā)現(xiàn)一些超出自身認知的可能性坑。

3）我的技術(shù)同事

這里側(cè)重強調(diào)是針對技術(shù)同事的性格了解，包括Ta對某需求了解的資歷程度、對我表達的內(nèi)容的理解程度等等。作為產(chǎn)品，了解清楚技術(shù)哥哥的性格，是為了進一步判斷其強勢程度、該采用什么樣的溝通方式；

明確其理解能力，能夠在很大程度上促進我們的溝通，便于產(chǎn)品表達時該說明的邏輯層次。最后強調(diào)一點，就是需要清楚其對某需求的認知程度，若果Ta也是新接手某需求，則需要產(chǎn)品理解更深層次的邏輯，明確需求邊界，跟進過程也需要多次確認。