• 小螞蟻站長吧-互聯網運營、增長黑客學習交流平臺

    您好,歡迎訪問小螞蟻站長吧!

    開發說這個需求做不了,你會如何應對?

    2000-01-01 00:00分類:產品經理 閱讀:

     

    編輯導語:作為產品經理,在和開發對接需求的時候,可能會遇到開發說需求做不了的情形,這種時候該怎么解決呢?是砍掉需求或者暴力溝通嗎?本文作者認為,本質是問題模型的問題,并分為三步進行了分析,一起來看一下吧。

    這是一個歷久彌新的產品話題。

    鏡同學相信,幾乎每個產品經理在和開發對接需求的過程中,都遇到過這樣的情形,根據我的觀察,不少產品經理最后都選擇了被動妥協。

    這里面主要有兩個原因:

    一是,某些產品經理客觀上懶于深入思考,想著既然開發都說實現不了了,那就沒辦法了唄,更有甚者就以此為尚方寶劍,二話不說就調整需求或者砍掉需求。

    二是,產品和開發溝通時沒有優勢壁壘,溝通視角天然對立,又或者開發講的技術邏輯產品同學壓根聽不懂,自然就覺得他們說的很有道理,要么就走入暴力溝通的死胡同:

    • 別人家能實現為啥你就實現不了?
    • 技術我不懂,反正這就是業務需求。
    • 反正我就要五彩斑斕的黑。
    • 明天要上線,怎么實現我不管。

    不管是哪種原因,最后造成的結果都是需求分歧無法得到妥善地解決,遺憾的是,這種情況竟然十分普遍,以至于在某些組織環境下,開發形成了慣性認知,導致稍顯復雜的需求,開發都會說技術實現不了。

    技術心想,反正你又不懂技術,這樣就造成產品經理很被動,并且,這與“我們要做難而正確的事”這個理念相違背。

    這就似乎陷入了解決問題的瓶頸:產品經理不懂技術,根本無法解決這些問題,這直接帶來了,產品的生態土壤的加速變壞。

    事實真的如此嗎?

    我在之前的文章中說過很多次:任何一個問題都有一個本質解和N個現象解,我們只有找到本質解才能從根本上解決這個問題。

    在我看來,懂不懂技術只是現象解,并不能從根本上解決這類問題,這個問題的本質仍然是問題模型的問題。

    那么,什么是正確的方法呢?

    我覺得主要可以分為三步,而這對于剛入門的產品經理尤其適合,因為他們有空杯心態,還沒有形成固化的工作方法,更容易從底層養成正確的方法論。

    一、你要有專家效應

    專家效應對外表達的是你的權威,我一直建議產品經理要對基礎的產品專業能力要熟練掌握,比如,在沒有準備好的情況下,不要輕易發表意見或者組織需求評審,只有在組織內形成了專家效應,后續的工作才能更有利。

    產品經理一旦失去權威,就會對后續的需求溝通極為不利。

    我舉個產品小案例:

    我們團隊之前有個產品經理在設計產品需求時,將”性別“這個字段做成了輸入框,而不是下拉選擇(男/女),結果被開發廣為吐槽,后來他的需求開發都不怎么重視。

    這雖然是個很小的細節,但會極大傷害你的專業能力,很容易失去開發的信任,類似于這樣的事情,我們一定要避免,比如,常見的坑還有“原型設計”缺乏基礎的交互,需求評審不講業務場景,需求說明沒有功能定義等等,這些之前文章都有過分享。

    總之,產品同學一定要注重專業能力,這是產品硬實力,是產品職場工作晉升的底層基礎。

    關于產品經理系統化的專業能力體系,我在之前的問題提到很多次,有興趣的同學也可以翻看或關鍵詞搜索之前的文章,比如,就在上一篇文章“敏捷五步,手把手教你畫產品架構圖?!敝芯吞岬?,產品架構設計就是展示你專家效應的有效手段之一。

    二、多元化思維,拓展能力邊界

    產品經理是一系列產品思維的表達載體,綜合能力集中體現在問題的解決上,這就需要跨學科學習,多元化思維,這中間就包括“技術思維”。

    上周我們在設計客戶關系管理時,關于“公海規則”的一個需求,開發說實現不了,當時技術同學建議客戶隸屬于公海,產品經理反饋給我后,我在群里發了消息,后來問題得到了妥善的解決。

    究其原因在于我有一些淺薄的技術積累,加之同理心思維,站在技術角度去思考并將產品語言翻譯成技術語言去說服他們。

    我是這樣回復的,分享給你,希望能對你理解“多元化思維對產品的價值”有幫助:

    關于“客戶管理系統中,同一個客戶同時滿足并觸發多條公海規則,如何流入處理”的建議:

    1、公海的主要業務場景是依據規則收回客戶,用以提高業務效率,其本質上其實是數據權限管理,即成為某個或多個公海成員的用戶,有權限查看并領取該公海里的客戶。

    2、明白了這個業務場景,若客戶A同時屬于公海①、公海②,當規則同時觸發時,應該同時流入公海①、公海②,比如集團事業部場景,客戶A屬于?;髽I,智慧環保為公海①,安全科技為公海②,兩個事業部都可以推進集團業務,此時應該允許公海①、公海②下的成員有權查看并領取。

    3、客戶應該為實體類,唯一標識應該是客戶ID,不應該為負責人或者隸屬公海,負責人或隸屬公海都是該客戶數據的兩個靜態字段。

    處理建議:

    1. 方案一:當客戶同時滿足多條公海規則時,應該流入兩個公海,當在某個公海中被領取之后,同時在另一個公海中也同步移除,不再展示,客戶數據是同一個數據(應優先按這個邏輯處理)
    2. 方案二:當客戶同時滿足多條公海規則時,流入最新創建的那條公海(指定公海規則即可)

    我的這個產品經理沒能說服開發本身,主要在于這個產品經理沒有技術思維,又缺乏深度思考和溝通的方法,所以把開發的反饋被動當成了本質解決方案,沒能有效解決這個需求。

    當然,不同崗位工作本身有邊界,產品經理并不需要深入技術本身,不過,適當懂一些技術思維和基本知識,在產品工作中能進行有效結合和融合思考,就能極大的提高需求傳遞效率。

    這也是我在之前文章中,反復推薦的一本書《領域驅動產品設計》的原因。

    三、聚焦問題本身,注意溝通方法

    很多時候,溝通都是有方法的,說服別人的關鍵在于聚焦問題本身,不要情緒對抗,就事論事,試著找到已有解決方案的案例,往往比蒼白的溝通更有說服力。

    我想起了多年前在之前公司做的一個小需求,當時的需求是要在“組織機構設計時”增加了搜索功能,因為我們集團使用這個系統,組織機構是每個事業部的業務單元,比如,每個城市區域可能都是一個組織機構。

    這就會導致有上百個組織機構,因此,對業務運營來說,可以搜索到某一個組織機構就顯得很有用,這也是業務本身的需求。

    當時我是和一個前端開發對接,那個開發同學反饋說不太好實現,可能他也是剛入門技術能力有限,也可能是項目時間太緊了。

    但是,我知道這個需求是很有業務價值的,我還知道:單一的溝通問題本身,遠遠不如找一個案例更有說服力。

    于是,我和他說,咱們不著急,先一起想想辦法,后來,我直接搜索“可搜索的樹形組件”,很快就找到了一個產品案例:

    拿著這個案例,我們溝通很快就達成了共識,并且,他不會認為你是淺薄的需求翻譯官,當你從業務場景講述需求價值,用同理心理解他的崗位技能,試圖和他同頻共振,再找一個產品案例去溝通交流,很快就能說服他。

    而且,這種事情還會不斷增加你的專家效應。

    說到這里,讓我們總結下,為了有效應對開發反饋說技術實現不了,從產品工作一開始我們就有必要執行三部曲:確立專家效應→找到根本原因→使用溝通軟技能。

    其實,最重要的還是要找到背后真正的原因,因為,很多時候開發反饋技術實現不了,并不一定就是技術瓶頸。

    我們在解決這些問題時,只有找到了背后真正的原因,才能更高效地解決問題,因為,背后真實的原因往往是本質解,但這其實有時候很難識別。

    不信,你試著回想斯賓格勒的一句話:秒針這一秒指向59,下一秒指向60,59就是60的原因嗎?

    最后,真的希望本文對你能有產品啟發。

    #專欄作家#

    產品大峽谷,公眾號:產品大峽谷,人人都是產品經理專欄作家。七年B端產品經理,供應鏈物流與金融領域,擅長需求設計、業務指導、商業觀察等。

    本文由@公眾號:產品大峽谷 原創發布于人人都是產品經理,未經許可,禁止轉載。

    題圖來自 Unsplash,基于CC0協議。

    上一篇: 產品這個工種,toC還是toB好?

    下一篇: 社會網絡學對產品經理有什么啟發?

    相關推薦
    ?

    關注我們

      小螞蟻站長吧-互聯網運營、增長黑客學習交流平臺
    返回頂部
    日韩在线精品视频a