本篇文章通過對高德地圖的紅綠燈倒計時提示，引發(fā)作者對此方案設(shè)計的猜測。作者以方案分析、功能梳理兩個方面為主要論述內(nèi)容，分析他對其的思考猜測，希望能對你有所幫助。
作為一個產(chǎn)品經(jīng)理，尤其是有好奇心的產(chǎn)品經(jīng)理，分析拆解已發(fā)布的產(chǎn)品功能是必不可少的事兒。
(相關(guān)資料圖)
而最近對高德紅綠燈預(yù)測的方案分析就是其中之一。
一、起因
一天下午和我們的技術(shù)同學一同出差，路上在十字路口等著漫長的紅燈讀秒。而此時高德導航上也在顯示紅綠燈倒計時，第一反應(yīng)是這個功能有意思且有用，解決因前方大車遮擋而看不到紅綠燈的問題能提高通行效率（可以讓司機提前準備駕駛，從抖音、朋友圈的娛樂中回到駕駛中）。
我在感嘆這個功能不錯同時，也在想它是如何實現(xiàn)。
而我們的技術(shù)同學強烈表示這是個硬件方案，要不咋能這么準確哪？
雖然在接下來的路口我們認真核對APP倒計時和燈桿上倒計時的差距，大概有2到3秒的誤差。但是其仍認為是硬件的IOT方案，在保持沒有深入思考就沒有發(fā)言權(quán)的原則同時，我選擇回來想想到底要如實現(xiàn)。
二、方案分析
1. 硬件IOT方案
如果想知道是不是硬件IOT方案，首先要想：如果是這個方案，那么需要和誰合作？有什么成本？
合作方：需要和各個地方的交管部門合作，同時涉及到硬件的采買、定制改造、安裝等，而且紅綠燈的硬件和家用燈硬件標準不同。紅綠燈需要在高溫、大雨等各種惡劣環(huán)境都能長時間正常運行，而家用燈很多時候根本無需考慮雨雪高溫等情況。那么這個硬件成本的上升和各種合規(guī)測試，由誰來負責？成本：除了我們上面的說的硬件本身，還有后續(xù)的安裝等成本，還有一條潛在成本：如何協(xié)調(diào)各個地方的交管部門在同一個時間前，都能上線？這個成本是無形的，但是很大，如果大家做過To B業(yè)務(wù)就能夠理解。就比方你在公司內(nèi)部做一個跨部門的合作，都不一定能順暢，那么跨地域、跨部門哪？畢竟高德的紅綠燈預(yù)測在上線初期就有了好幾十個城市，和這些城市的幾萬個核心路口。
通過以上看，硬件IOT的方案是理論上可行，但是成本太大，大概率不會是這個方案。
2. 平臺接入
如果有硬件且需要多方協(xié)調(diào)的成本如此大，是否可以純軟件平臺介入哪？比如直接拿各個地方交管平臺的數(shù)據(jù)哪？
我理解這個也不行，除了數(shù)據(jù)安全的角度外，最大的一個悖論是：如果我拿到了交管平臺的數(shù)據(jù)，我為啥不把所有路口的倒計時都做了哪？為啥只有一部分路口數(shù)據(jù)，而另一部分沒有哪？
因為從交管平臺的角度看，各個紅路燈的倒計時數(shù)據(jù)是沒有本質(zhì)差別的。
而這個矛盾點的存在，證明現(xiàn)有的方案也不是交管平臺接入。
3. 數(shù)據(jù)挖掘
如果既不是硬件也不是平臺，還能是什么？大數(shù)據(jù)挖掘。這個方案的好處是：
不依賴公司外部，只需要組織（項目組）內(nèi)部協(xié)調(diào)，周期自控?，F(xiàn)有的核心數(shù)據(jù)在移動端都可以獲得，且DAU足夠大，畢竟國內(nèi)導航top2就是百度和高德。針對路口車流量數(shù)據(jù)（數(shù)量、質(zhì)量、置信度等）來區(qū)分是否需要挖掘該位置信息，非核心路口的車流量小，那么對應(yīng)數(shù)據(jù)就少，經(jīng)過數(shù)據(jù)清洗后可用的數(shù)據(jù)、能提高/達到的置信度都會比較難，所以才導致車流量小的非核心路口，沒有上線該能力。
三、功能梳理
我們分析完，發(fā)現(xiàn)最可能得是組織內(nèi)部的純軟件方案， 那么結(jié)合一個case，我們嘗試梳理下需要哪些數(shù)據(jù)，及如何實現(xiàn)。
我們以一個十字路口要識別直行的紅燈、綠燈時長為例子來考慮。
基于如上的信息，先看司機是否在導航中，再看要識別的這個路口是否在用戶當前的規(guī)劃路線中。如果是，我們再看當前車輛在紅綠燈前后的表現(xiàn)，也就是關(guān)注速度的變化。
當考慮如下圖的一個十字路口時，我們先看不同車道的通行限制。其中只有中間車道可以直行，所以可以忽略后續(xù)左轉(zhuǎn)和右轉(zhuǎn)的車輛，僅僅看那些車輛從當前俯視圖路口的左側(cè)到達了右側(cè)。
比如圖中的轎車和跑車的行駛數(shù)據(jù)，而其中右轉(zhuǎn)的皮卡則無需關(guān)注，因為他的數(shù)據(jù)對當前直行紅綠燈時間判斷幾乎沒有影響。
然后再看不同車輛在這個路口附近（附近這個概念可以是上一個路口到這個路口，或者限定多遠的距離內(nèi)，或者兩者結(jié)合取最小值）速度的變化。
如果我們以當前路口為例，將一天內(nèi)各個時段經(jīng)過該路口的不同車輛速度都畫在一個二維坐標系中，會是怎么樣哪？
我們以三臺車和一個紅綠燈周期為例子還嘗試畫出來：
因為不同車輛在到達該紅綠燈附近的速度不同，而且在該紅綠燈前方停止的車輛數(shù)量不同，會導致其剎車時的加速度不同。也就是影響了曲線斜率（為了簡單，假設(shè)加速度都是線性變化），同時會導致其停止的時間不同。
如果考慮這三輛車的速度變化，綠色停的最晚、起步也最晚；而紅色停的最早，起步也最早。
大概率是紅色排在第一，藍色第二，綠色第三，而他們?nèi)齻€的停車時長所占用的是時間段，就是該紅綠燈的紅燈時段。
我們可以把這個例子再擴充下，考慮兩輛車遇到紅綠燈需要停車再起步，另一輛車遇到綠燈直接開過去的情況。
紅車和綠車符合剛才說的規(guī)律，在其起步并且速度起來后的時段中，藍色車以一定速度駛?cè)耄⑶易隽藴p速（過路口一般要減速），然后在提速。
那么可以看到在藍色車的這個時間段內(nèi)就是緊接著剛才紅燈時段的綠燈時段，然后再會進入下一個紅綠燈時段的循環(huán)。
再接著如上的例子，我們將右轉(zhuǎn)擴展為右轉(zhuǎn)加直行，那么這種情況會比剛才復雜。當直行紅燈時，在最右側(cè)車道上需直行的車輛依然會停車，從速度減為零，再從零起步這個過程與剛才類似。
但是如果此時是綠燈，一部分行人和電瓶車的直行導致右轉(zhuǎn)車輛停車等待，而此時在右側(cè)車道要直行的車輛，必然也需要等待。
如圖中需要直行的藍色車輛和需要右轉(zhuǎn)的灰色車輛（用對應(yīng)顏色線表示其即將走的軌跡），此時與已經(jīng)直行的車輛數(shù)據(jù)要如何處理？
筆者大膽猜測，當有一定數(shù)量的直行數(shù)據(jù)時候，這部分為零的數(shù)據(jù)，可以不要?；蛘呶覀兛紤]使用該數(shù)據(jù)，但是需要如下思考：
司機是理性人，當中間車道沒有車或者車輛明顯少于右側(cè)車道時，其不會駛?cè)胗覀?cè)車道來直行。所以司機在右側(cè)車道直行時，中間車道的直行車輛必然多于右側(cè)車道的直行車。而考慮到數(shù)據(jù)的置信區(qū)間，當數(shù)據(jù)通過多次累計后，便可以知道紅燈時長。如圖，藍色車輛速度為0的時間明顯更長，但是在多次數(shù)據(jù)積累下，還是可以確信紅色和綠色車輛的零速時間段為紅燈時間段。
上面所有信息都沒有基于導航的地理位置數(shù)據(jù)來分析，如果考慮可以精確到車道級別的數(shù)據(jù)來分析，就回更加簡單。
比如剛才右側(cè)車道允許直行的例子就好處理，可以將所有右側(cè)車道的數(shù)據(jù)單獨處理，或者作為輔助判斷即可，也可以用同一個時刻右轉(zhuǎn)車輛的等待時間結(jié)合起來計算。
相對簡單的辦法就是用中間直行車道數(shù)據(jù)來計算，因為數(shù)據(jù)量足夠大，所以暫時剔除一部分應(yīng)該對預(yù)測準確性影響不大。
當一個簡單情況分析后（類似我們學數(shù)學的特例），我們再擴展條件，比如上文提到的右轉(zhuǎn)車道上允許直行。
在考慮這個擴展后，我們還可以考慮如下更多因素：
考慮N天的同一時段的數(shù)據(jù)，紅綠燈循環(huán)有穩(wěn)定性的周期性，再結(jié)合工作日和休息日考慮（有部分紅綠燈在休息日是黃燈閃爍）。考慮天氣異常對車輛行駛速度的影響?？紤]司機臨時改變路線（可能是開錯了數(shù)據(jù)如何處理）。在考慮非導航內(nèi)數(shù)據(jù)如何使用（此處可以截個行車軌跡圖，高德有的）。
當模型已經(jīng)有了一個版本，如何更新迭代？
此時建立一個數(shù)據(jù)模型循環(huán)飛輪即可。筆者認為該功能在最初上線前，除了通過原始數(shù)據(jù)中部分未參與模型訓練數(shù)據(jù)進行模式測試，同時可結(jié)合實際線上的、實時的車輛行駛數(shù)據(jù)進行測試。
比如模型預(yù)測該紅綠燈現(xiàn)在司機需要停車，當然此時用戶側(cè)無感知，然后看車輛接下來的速度變化是否符合預(yù)期。比如模型預(yù)測該司機保持現(xiàn)有速度可以綠波通過接下來的四個紅綠燈，但是在第三個卻停車，這便不符合預(yù)期，那就結(jié)合前段時間（天）該路口的數(shù)據(jù)從新分析。比如模型預(yù)測該司機此時可以行駛過該路口但是卻停下來了，而且接下來的周期中經(jīng)常出現(xiàn)該情況，就要考慮是否此處紅燈時間或者周期已經(jīng)進行調(diào)整，然后從新更改模型。
四、寫在最后
專欄作家
代成龍，人人都是產(chǎn)品經(jīng)理專欄作家，智能硬件創(chuàng)業(yè)公司產(chǎn)品狗，從視頻巨頭公司到玩智能硬件的公司，繼續(xù)產(chǎn)品設(shè)計工作。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
標簽：
