在做項目過程中，我們常常會遇到各種各樣的問題，不僅僅需要管事情，還需要管理好人的問題。作者結合自己做的車路協(xié)同&智能網(wǎng)聯(lián)的項目經(jīng)驗，與你談談在項目落地過程中需要注意的一些事情。
從南到北，從沈陽到廣西，從東到西，從山東到甘肅，車路協(xié)同&智能網(wǎng)聯(lián)的項目也做了幾個，寫點這過程中的心得體會，聊以自慰，全當記錄～
01 預期管理
(資料圖)
項目開始時，我們要先解決“人”的問題。
如何讓眾多的利益相關方，不同的團隊，部門上級、項目負責人，乃至大老板，在項目推進中能夠“可控”，能夠目標一致，甚至歡天喜地的配合你完成項目上線。
做好“預期管理”。
最開始時作為產(chǎn)品經(jīng)理只關心自己負責的業(yè)務部分如何更快的上線，至多關心自己的上級及團隊，不太會想到項目里的其他團隊。
但角色上調(diào)之后，開始逐漸關心整個項目的落地如何更絲滑，如何讓所有人“滿意”，要對不同的角色，實行不同的預期管理。
針對產(chǎn)品部門領導，要如實告知產(chǎn)品的能力范圍和邊界，90%對上解決方案和售前，必須承認他們的嘴太厲害了，我們要給他們收一收，你給他們收80%，他們能給客戶吹成100%，所以要給自己和團隊留個buffer。
過程中給自己團隊80%的交付滿意度，產(chǎn)品質(zhì)量定120%的目標。
02 降低人效的預期
兵馬未動，糧草先行。開始之前總得先盤一盤這攤子活需要多少人力投入。
預估人力資源，會決定投入多少人力成本，項目是否能保證不延期，這里有個問題，把人從辦公室拉到現(xiàn)場，人效是正常辦公的多少？
我的感覺是 75%。
搞過車路協(xié)同項目落地的都知道，這個過程鏈路太長。大面上來說，車、路、云是不同的團隊負責，拿路側來說，路側設備的電路、燈桿、掛臂、頂管、相機、雷達等設備需要普通工人頂管架線，需要協(xié)調(diào)城市管理部門安裝燈桿、掛臂，需要運維團隊對設備激活，維護、需要技術團隊標定相機雷達、需要研發(fā)團隊跑算法，分析性能等等。
此外現(xiàn)場還會有你意想不到的各種問題，外部依賴項比如：頂管設備壞了，頻繁下雨，市領導檢查不讓施工了，溝通上的效率也會低很多。
遠不如辦公室來一嗓子。我在天南他在地北，再加上信號不好，說半天都是 啥，啥，啥。
為了避免對人力效率的錯誤評估，導致項目的延期，建議默認每個人的效率是75%。
03 任務包拆解到人
這也是自己吃過的很大的一個虧，項目開始時就一個人在現(xiàn)場上躥下跳，腳不離地，心里還有種指點他人的怪癖爽感，但下來冷靜往回看，其實很多事情都沒跟到位，很多臨時決策也并不是最優(yōu)解。
因此核心事項、關鍵任務包一定要有具體負責人，項目尤其是現(xiàn)場要盯緊的環(huán)節(jié)太多了，每個環(huán)節(jié)都應有負責人。
這樣每個節(jié)點都有關鍵人來負責，更多跟關鍵節(jié)點的人匯總消息，降低溝通成本，更能降低出錯的成本。
另外全鏈路需要1-2個人來熟悉整個項目概況，能給自己找個替身。
相信我，這個動作一定要做，你不是每天都要盯現(xiàn)場，不是每個決策都需要你下，要給自己抽身出來的機會。
04 盡早確定版本邊界
在項目交付中，要給交付方明確的版本概念，交付的版本號是一方面，另外還代表著這個項目交付的軟硬件系統(tǒng)能力邊界，盡可能前置明確、對齊好系統(tǒng)能力范圍。
不要到現(xiàn)場了或鄰近交付了再來過多的增調(diào)需求，不可否認車路協(xié)同項目確實很難做到不改需求，但作為產(chǎn)品經(jīng)理應負責在過程中逐漸與大家對齊產(chǎn)品最終效果，并敢于控制迭代節(jié)奏，敢于說不，那些不重要的需求要敢于后置，要控制版本的邊界和迭代節(jié)奏。
05 注意現(xiàn)場“好奇寶寶”
雖然不會總用惡意來揣度別人，但多一些防備總是好的。項目進場后你會發(fā)現(xiàn)真的有很多雙眼睛在盯著你，看你的進展，學習你的流程和實施情況。
對一家公司的產(chǎn)品方案，行業(yè)人一打眼，問兩個關鍵問題也就大概知道了七七八八。另外這個市場現(xiàn)在都在互相學習，一家的項目落地肯定是有多個同行在學習探底。
一家公司的交付標準及能力，是需要保密的，但競爭對手的窺私欲是沒辦法制止的，
現(xiàn)場一般會做3個動作：工牌表明身份，留意閑散人員，建立信息保密機制。
就舉個簡單的例子，你在現(xiàn)場跟技術討論項目卡點及解決方案，結果轉(zhuǎn)身在抖音看到了這段視頻，還有很多免費小心心，嗯，你說多崩潰。
另外我們希望別人看到的，是我們希望他們看到的那些。這里涉及的信息分發(fā)，輿情的控制，不應被不受管理的發(fā)出去，不然就需要太大的解釋成本了。
06 有效問題反饋機制
在現(xiàn)場需要充分“放權”或是能有效收集民意，這些聲音都將是收獲。
搞過項目落地的，一定懂“墨菲定律”的痛，覺得不會出問題的，一定會出問題。
很需要提前把這些問題暴露出來，盡可能壓低風險造成的影響。
鼓勵大家多對項目發(fā)表意見，要能有效收集匯總，并給到問題提出者反饋！
見微，知曉項目一線風險、需要哪些資源，覺得不OK的事情，哪些是阻礙項、哪些需要協(xié)調(diào)
能夠根據(jù)這些問題提前評估依賴項，要么多要資源，要么提前爆出風險，且應對現(xiàn)場發(fā)現(xiàn)的問題找到的解決技巧或tips，留存記錄。
鼓勵大家寫SOP，并沉淀成項目經(jīng)驗。
07 解決問題要結果
給判斷。應明確問題出現(xiàn)反饋時，要附上自己的判斷依據(jù)。
2小時原則。2小時不能自行解決，則需要暴露出來，讓問題升級或協(xié)調(diào)資源。
鼓勵補位。每個人多做一點，每個部門多承擔一點，產(chǎn)品可以測試，運維也可以配合現(xiàn)場抓日志。
專項團隊。支持組建現(xiàn)場小組，快速專項攻破難點問題，并表揚出來。有時候現(xiàn)場的人真的只是缺這句鼓勵。
08 消息同步機制
在項目一線，每個人都在忙自己的任務事項，這時候一定要關注消息同步的及時性和到達率，能不能通知到每一位人，什么樣的消息該同步給誰。
什么樣的消息同步：需求變更，時間調(diào)整，任務優(yōu)先級變更。
這里涉及到2點，不同的內(nèi)容在不同的群里同步。每個人對于信息的消化不一樣，需要經(jīng)過翻譯處理后再給到自己下游，舉個，我們要臨時對交付內(nèi)容做一個修改，這種修改是向善的且有價值的，但可能具體執(zhí)行層的人只看到了要改，不清楚這樣改的好處。
就很容易讓團隊里的人挑戰(zhàn)或質(zhì)疑，潛在影響產(chǎn)出。
09 對于工作節(jié)奏的把控
前松后緊，還是前緊后松，還是一個節(jié)奏走完全程？
真正搞過落地的，心里應該只有一個答案：不管前邊緊不緊，越到交付越緊。
越往后各種意想不到的問題越會出現(xiàn)，前邊埋的雷也該被趟出來了，結合實際來看，我們能做的一件事是：讓項目能盡早正向的滾動起來，到后期最影響節(jié)奏的是定位-跟進-解決問題，盡可能降低問題復現(xiàn)的成本，很多現(xiàn)場的問題就是偶現(xiàn)，等統(tǒng)一反饋了，環(huán)境變了也很難復現(xiàn)，反而是給現(xiàn)場埋了雷，提升問題解決效率，現(xiàn)場的人一般都是一人多崗，很容易由于其他任務導致這個問題就卡在這里。
10 決策權要逐步收口
前期鼓勵每個人來發(fā)言發(fā)現(xiàn)問題，越往后時間、交付越緊張，信息越來越透明，更需要人來拍版；越臨近項目，整個項目的進度和風險更加透明化和保證已知。
因為我們要開始準備向外輸出的工作了，準備跟解決方案，售前的同事合作來應對第三方和監(jiān)理的驗收，這時候要保證大家知道系統(tǒng)的能力邊界在哪里，別砸了。
越往后，每個決定就需要承擔越來越多的風險和責任，敢拍板的人也會越來越少。
那誰來拍版那，原則上是誰負責，誰拍版。
過程中的幾點感受～
要相信團隊。沒有人可以面面俱到，沒有人。要相信團隊里的每個人，團隊是可以互相支撐的。
要學會求助。不一定要所有事情自己扛，學會跟老板跟同事求助，磨合磨合才會更好。
凡事盡可能簡單。要擁有超凡化簡的能力，先盯緊目標，先想全局實現(xiàn)路徑。
要有自己的堅持和節(jié)奏。要有自己的堅持和節(jié)奏，要有自己的堅持和節(jié)奏。
散會～
本文由 @張廣岐^_^ 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于 CC0 協(xié)議
