神經語言程序學pdf（人類神經語言程序學）

神經語言程序學

NLP（Neuro Linguistic Programming，身心、語法、程序等）語義分析目前在大數(shù)據(jù)領域炙手可熱的話題。任何對語言的理解都可以歸為語義分析的范疇。一段文本通常由詞、句子和段落來構成，根據(jù)理解對象的語言單位不同， 語義分析又可進一步分解為詞匯級語義分析、句子級語義分析以及篇章級語義分析。語義分析目標就是通過建立有效的模型和系統(tǒng)， 實現(xiàn)在各個語言單位的自動語義分析，從而實現(xiàn)理解整個文本表達的真實語義。

最近做的項目需要通過NLP分析用戶評論，根據(jù)用戶評論確定是否商品有質量問題，進而確認是哪類質量問題，更進一步給這條評價打上標簽。項目時間比較緊張，甚至項目的進度安排受到質疑，項目節(jié)奏一旦確認，強力推進，這本是我的工作范疇。但我實在低估了NLP從模型化到準確率提升難度其實挺大。隨著項目進行，風險也在逐步加大，但項目目標經過滾動式規(guī)劃越來越清晰。從外包團隊標記語料，到模型搭建優(yōu)化，到歸類，到BAD CASES分析處理，到關鍵詞規(guī)則全套匯總，一環(huán)扣一環(huán)。數(shù)據(jù)源有兩種，一種是真實用戶記錄的，一種是內部人員記錄的。不確定性在于技術認為這兩種數(shù)據(jù)源可以使用同一套數(shù)據(jù)模型解析。做的過程中才發(fā)現(xiàn)這兩個數(shù)據(jù)源不能通過一種模型實現(xiàn)解析，于是技術就用了四個模型。此時，應該采用原型法介入了。

中期項目風險確實比較大，項目中期產品技術與業(yè)務方進行了一次深入溝通，就項目目標再次重申，明確兩種數(shù)據(jù)類型需要分開處理，準確率目標也不盡相同。本期上線目標是系統(tǒng)流程打通，同時保證一種數(shù)據(jù)源成功率，確保大分類數(shù)據(jù)準確，二級分類可以分迭代執(zhí)行，當然這個與業(yè)務方期望一致。這樣的迭代升級計劃是項目組是需要制訂的，不能光說不能搞定，還得有接下來搞定的計劃怎樣，這才是一種正確的做法。

接入NLP分析，細化工作任務。在前期準確率不能提升的情況下，怎樣驗收，模擬現(xiàn)有人工操作讓流程跑起來同樣重要。有時候開發(fā)說很快其實是個偽命題，做過程序員的朋友都應該知道一個話題，等我?guī)追昼娚踔潦昼?，恐怕一兩個小時都沒有了，項目經理對程序員的“快速承諾”往往會比較謹慎，可以輸出需要做哪些事情，需要哪些外部輸入和內部數(shù)據(jù)準備，臨時抱佛腳其實是比較慘的。這也是項目經理需要留意的地方，可能你面對的是開發(fā)負責人，而開發(fā)負責人不是最終的執(zhí)行開發(fā)人員，這中間的溝通斷層有時候會出問題，溝通討論具體執(zhí)行計劃，與實際對接人溝通顯得尤為重要。

下游系統(tǒng)的對接，接口之間要明確，技術負責人需要仔細評審，項目經理可以抽查，尤其是可能出問題系統(tǒng)之間的交互，從產品技術測試的角度全面出擊，確保上下游數(shù)據(jù)對接好，核心流程經歷過開發(fā)聯(lián)調、測試聯(lián)調等，回歸保證現(xiàn)有流程不受到影響。

安全評審、用例評審、上線評審、發(fā)布時間都還是要對齊，上線后驗收用例也可安排評審，第一時間留下產品經理，和研發(fā)團隊一起驗收，這非常重要。每個人手頭上有很多事情，項目經理就是他們的指示牌，你最了解這個項目的整體計劃和時間緊迫性，而他們則有自己的需求和事情優(yōu)先級，提早進行規(guī)劃，確保大家全力支撐，做到心往一處想和勁往一處使。

跨地區(qū)和跨團隊本來就是溝通中的難題，該溝通一定要第一時間溝通，確保雙方理解一致，充分利用現(xiàn)代高科技，雙方理解一致，深入溝通，而不是“我以為”，這在后期就是借口了。有風險也不必第一時間通過領導傳遞出去，你有自己的思想，有自己的計劃，這個層級全方位考慮已顯得特別重要，不然也挺難更進一步的。

當然，知道各個團隊需求列表，項目資源的情況，了解到關鍵路徑上的排期，整個節(jié)奏按這個對齊，同時跟開發(fā)負責人協(xié)調資源，其實都是要努力爭取的。對于一些申請的特別臨時資源，要關注風險，確保長期關注，周計劃要明確，每日重點要第一時間關注，對于自管理團隊也要看其成熟度，磨合階段的效果一定不會太好，拉群，隨時問候，每日同步都非常重要。

一旦確立目標，全力以赴，一起搞清楚要做的事情，拉上專家一起，勢必在項目初期就識別風險，不要到最后各處救火。滾動式規(guī)劃很重要，公司同事都是愿意做好事情的，這一點非常重要。事因難能，所以可貴，能夠在很短時間里靠集體的力量完成這個難度還蠻高的項目本來就不容易。上線后持續(xù)迭代，上線后回顧都顯得尤其重要，NLP尤其需要重點留意，全力以赴沖刺，上線一個比較好的效果，能夠幫忙公司，這本來就是一件美好的事情，感謝、感激、感恩大家那一個個奮斗的夜晚和周末，一起繼續(xù)加油，爭取早日可運營！

最后要說下個人收獲最大的經驗教訓了，目標一旦確定勢必全力以赴。后續(xù)項目有則改之，無則加勉。從各個緯度：

1. 需求階段即識別最關鍵路徑，包括技術風險，拉主要負責人一起討論應對之策，滾動式規(guī)劃，搞不定也得有計劃。最大的技術風險看其他同事怎樣幫助，充分利用業(yè)務方的期盼和技術同事的主觀能動性。一起感受到業(yè)務的期盼。

2. 大數(shù)據(jù)模型迭代需要一個較長的時間，這一點不僅要讓自己明白，也需要讓產品和技術，尤其是關鍵的業(yè)務明白，有計劃地推進落地。做出來計劃，分解出WBS。不要等上面催促的時候才回復，有計劃，有安排，這也非常重要。

3. 申請到新團隊資源，一定要留意有個磨合的過程。這個需要作為項目的風險，一直觀察，團隊組建到成熟高產出，需要時間。多溝通，各種形式狂轟濫炸。當前，快速申請資源本身還是不錯的，這個值得嘉獎，從上往下得到領導支持非常重要。

4. 遠程團隊需要跟負責人建好，提前溝通加班安排。緊密每周溝通，尤其是在聯(lián)調的關鍵時期，索性本次并沒有掉鏈子。產品和實際開發(fā)要多溝通，避免技術負責人太忙，以至于信息有斷層。

5. 安全評審和上線驗收要提前準備，通知產品經理，同時號召各產品線準備好驗收場景和所需要的數(shù)據(jù)，權限，確保干系人都在場，否則沒法搞了。測試有理由不上線，因為沒有產品經理驗收。

6. 對需要進行數(shù)據(jù)初始化的項目，一定要確認好初始化的數(shù)據(jù)，需要的時間，各下游系統(tǒng)的準備，都需要規(guī)劃好?？梢院蜕暇€并行地搞，這樣才不至于后期被動，這個也是非常重要的。

再次回顧下墨菲定律，你越不想某件事情發(fā)生，某件事情就越會發(fā)生。比如這次半夜上線推遲到第二天中午，進一步推遲到第二天下午，是因為擔心半夜發(fā)布的風險和發(fā)現(xiàn)新問題所致；比如驗收過程中導入數(shù)據(jù)，以為一切就緒，發(fā)現(xiàn)走HIVE的時間也是好幾個小時，手工拼裝數(shù)據(jù)也并非想象中那么容易，一個多小時硬是變成了半天；比如NLP準確率從頭到尾都是一個問題，一開始懵懵懂懂到最后逐步清晰，這其實可以更要讓其發(fā)生，雖然已盡全力，但著實沒有辦法，晚兩周發(fā)布會不會更好。

期望自己能夠繼續(xù)成長，積累心得，下一個項目少走彎路。有并行思維而非串行思維，這同樣重要。項目在每天和每周最重要的事情都需要羅列下，這就是項目周報、項目里程碑的意義，這些內容隨時可供自己參考，也方便干系人了解項目最新的狀態(tài)。