編輯導語：作為產品經(jīng)理，做需求是本職工作，但如果在打造產品的過程中，產品本身某一類功能存有不健全結構時，即存在所謂“隱患”問題，該如何調整狀態(tài)面對并解決呢？本文將對其進行方法的分享，值得閱讀學習。

我是一個產品經(jīng)理，做需求是我的本職，但有一類功能我真的是不想做但又不能不做——技術實現(xiàn)不復雜，用起來容易有很多小問題，存在“隱患”。這種功能做了就很麻煩，弄不好就未必能夠有正面評價。

今天之所以談這個，自然是因為最近又遇到了這類功能。

最近，我收到一個需求：后臺的某個城市選擇功能，除了單獨勾選外，需要新增批量上傳的功能，允許直接導入excel表格，批量勾選城市。

經(jīng)過進一步了解后這個需求可以翻譯為：新增批量上傳的功能，操作的時候使用的同事直接上傳excel表格，上傳后通過技術手段從表格中讀取出城市，將這些城市和數(shù)據(jù)庫中的城市自動匹配，然后自動勾選匹配上的城市，由于上傳的時候表格里面的城市是中文名稱，所以需要使用中文進行匹配，不預設上傳模板。

如果是技術的同事看到應該就知道這個功能其實不好處理，不是指技術不好實現(xiàn)，而是說實際用起來會有很多問題。

我們展開聊一下這個功能。

需求的起源是什么呢？是因為在實際操作的過程中，一個個勾選城市很麻煩。

大家可以想象一下，類似在app上的城市選擇組件，如果要多選，就需要先選擇省份再選擇市一級單位。如果是整個省都選就還行，如果是這個省里面只有部分城市，那就必須先進入這個省，然后再選擇對應的城市，確實麻煩。

尤其是如果參照的城市列表城市不是按照省份來列的，那就更麻煩，每次都得看這個城市是哪個省份的，然后進去勾選，然后到下一個省份勾選，如果這個省份有十個城市，搞不好就得進十次，非常麻煩。

這還是你知道所有的城市歸屬到哪個省份，如果不知道你還需要百度，然后再勾選。

活雖然不復雜，但是操作起來是很麻煩的，如果還需要多次重復操作的話簡直可以說是噩夢般的體驗，分分鐘眼睛就花了。

所以才有了批量上傳匹配這種需求，需求是十分合理的。

雖然合理但是不意味著這個需求不麻煩，問題就出在這個【按照中文名匹配，不預設模板】上面。

我們先說說如果是技術來處理一般是怎么處理的：

在技術實現(xiàn)層面，一般來說數(shù)據(jù)庫里面預存的城市是同時包含了城市名和code的，code可以理解為城市的唯一編碼，是一串數(shù)字，技術部門在內部使用這些城市數(shù)據(jù)的時候實際上是以code為準的，因為精準不會出錯。

所以如果是技術做處理的話一般是讓使用的同事導入城市名+code兩列，技術根據(jù)code進行匹配，城市名是給使用的同事識別用的。

而且這些城市名和code是技術會預先給模板數(shù)據(jù)的，需要在模板數(shù)據(jù)里面選取對應的城市然后導入。

操作上就是使用的同事拿著要勾選的城市名單，然后從模板數(shù)據(jù)里面選出這些城市，最后導入數(shù)據(jù)庫。

操作起來的確是不那么方便的，如果說多次重復操作的話也能節(jié)省時間。

但是在使用的同事的層面來說，使用code顯然是不合適的，最便捷肯定是有名單就可以直接導入。

使用的同事的城市名單來源可能是多樣的，可能是第三方給的，或者自己從某個地方導出的，或者從頁面上復制的，無法預判，換句話說很可能是不符合規(guī)范的。

注意我說的這句話——很可能是不符合規(guī)范的，雖然使用的同事使用的表格在人工使用上沒有問題，但是技術層面要識別的話必須符合特定的技術規(guī)范，而使用中文名進行匹配就很容易識別失敗。

譬如表格里面的內容有空格/符號，內容里面還有隱藏字符，數(shù)據(jù)庫預存的城市帶有市/州但是上傳的時候沒有，上傳的表格有其他格式設置等等，雖然人工使用沒有問題，但是技術層面就會匹配失敗。

所以這個功能技術實現(xiàn)不復雜，讀取表格的城市名匹配一遍，匹配成功的勾選，匹配失敗的不勾選。

對于匹配失敗的提示，最基本的就是提示一下上傳了多少條，成功了多少條，如果兩個不相等就肯定有失敗的，進階一點的就追加一個需求點，把匹配失敗的展示在彈窗上，這樣就能更直觀的知道有哪些城市需要再次處理。

使用的同事在看到提示以后去修改相關的城市數(shù)據(jù)，然后再次上傳。

如果順利一般操作兩次，如果不順利不好說?，F(xiàn)實情況往往就在這個不好說里面。

我過去用過類似的功能，有些城市反復上傳都無法成功，問技術也不知道問題在哪里。然后就沒有然后了。

一旦反復遇到這種匹配失敗的情況，使用的同事的體驗就不會很好，然后會繼續(xù)提要優(yōu)化的問題。

問題就在這里了，沒法優(yōu)化。產品經(jīng)理需要解釋為什么無法優(yōu)化了，很可能是解釋不好的，最后的結果是雖然使用的同事接受了解釋，但僅僅是接受了解釋。

要是領導問起來，使用的同事對這個功能的評價就是不高的，那么對于做這個功能的產品來說就是做了一件不討好的事情，技術覺得不合適、同事用著不好用。

所以我遇到這種需求真是不想做，后續(xù)的處理和解釋比較麻煩。

遇到這種情況，有一點是可以明確的，那就是做是必須做的，畢竟需求的合理性是存在的。

但是你也必須做一些前期工作，避免后續(xù)的麻煩：

首先是必須合理管理使用人員的預期。一定要在前期的時候把可能會遇到的情況和使用的同事講清楚，管理好預期。

提需求的同事肯定是不知道這里面還有這么多名堂的，這就要靠你科普了。

你需要把這個問題用最簡單的語言講清楚，使用的同事如果比較容易溝通的話就還好，不容易溝通的通常不會在意你說的這些，他們會覺得自己肯定不會犯這些問題。

不管是哪一種你都需要在前期多做一些溝通，這樣至少在后面的溝通里面占據(jù)主動。

其次，你需要和主管領導也溝通一下這個問題，讓他心里有數(shù)。

把具體的需求和溝通的情況都說一下，如果后續(xù)遇到被其他部門質疑的時候，你的主管領導能在第一時間做出合理的處理，不至于一臉懵。

不要給領導添麻煩，尤其是可以避免的麻煩，領導也是人，不會喜歡麻煩的。

最后你還需要和技術的同事做溝通，講清楚這個需求的使用場景。

像這個批量上傳城市的需求，對于技術的同事來說，如果你不說場景，只說需求，他們肯定會提出來異議，說要按照預設的模板上傳，按照code進行匹配，這就和需求不匹配了。

你需要說清楚場景，解釋清楚為什么不是按照更精確的思路實現(xiàn)，而是采用這種方式。

講清楚關鍵的地方，技術自然也能理解，也就知道不是你這個產品經(jīng)理坑，而是確實需要這么做。

這三步下去就能把后續(xù)的影響降到最低。

產品經(jīng)理在這里面做的工作并不僅僅是整理需求，還有大量的溝通工作，實際上溝通本身就是產品設計解決方案的一部分。你需要讓大家知道你設計方案的思路，確保符合需求同時也保障落地實現(xiàn)。

產品經(jīng)理還是需要懂得保護自己的合理利益。

因為正好遇到這么個需求，所以分享一下，希望對大家有個啟發(fā)。

我說的不包含全部，僅僅是一種思考的分享。

本文由 @產品人玄青 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協(xié)議