三種方式,提高你對需求的理解

0 評論 10813 瀏覽 41 收藏 9 分鐘

不要帶著疑惑去處理需求,因為這個就像滾雪球,隨著更多業務的不斷增加,因為一開始的疑惑,而導致更多的不理解出現,這是一個令人懊惱的過程。因此在需求伊始,一定要將自己對需求的疑惑,充分地表達出來,好讓需求方自檢的同時,也好對你的問題進行一遍梳理。

需求在我們的日常生活中可以說是無處不在。比如你早上起床你需要洗漱,徐需要吃飯,需要做很多習以為常的事情。

那么在日常的產品工作中,當我們遇到一個需求,我們要怎么做呢?答案肯定不是不分青紅皂白的拿來就做,這樣的做法很可能導致的結果就是一而再再而三的改稿。所以有以下幾種方式,能夠提高你對理解需求的方式。

1、盡量在場

我們在需求方發布的需求的時候,如果可以要盡量在場,不管你是被邀請的,還是自己主動要參加,都可以;盡量讓自己在場,讓自己知道 ,需求誕生的背景,這樣能夠非常有利于你的后期設計??赡苡械男』锇闀f我如果很忙或者因為職位的級別不夠等種種不可能抗力因素怎么辦?其實這個很好解決,如果你實在是無法置身其中,那你就要打起十二分的精神,和向你傳達需求的小伙伴好好請教,勢必問到自己心中沒有疑惑,在和小伙伴溝通的過程中,不妨用用下面幾個小方法:

  • 第一個就是小伙伴在講的時候,每到一個段落,你要在心里構思一下你對目前需求的理解,然后重復給他聽,第一是傳達自己的反饋,一方面也是證明自己有在認真考慮,再者讓對方了解自己的描述是否準確傳到了。
  • 第二個就是每到一個選擇的十字路口的時候,你要重復他的話,比如:“我要在個人中心的最上面,添加一個頭像?!蹦憧梢杂米约旱脑拰倓偟臎Q定性選擇進行重復。當然具體要證明組織語言以及選擇時機還是要看自己。
  • 第三個隨手帶一張紙和筆,俗話說好記性不如爛筆頭,在溝通的過程中,做到實時的給出想法和判斷是一個設計師必備的素質。
  • 第四個一定得問清楚,不管你心里os這個問題問出來會不會太蠢,因為你是需求的最后執行者,你有必要知道每一個細節。

二、深度交流

在需求傳達的初期,往往需求本身也不是很完善,這個時候,你一定要和pm緊緊的搞在一起(開玩笑),因為你的反饋對他來說也很重要。從需求的制定背景,需求的等級,需求的開發時間,需求自身的重要程度等方面來進行交流,交流下來,你可能發現這只是一個因為競品做了,所以我們也要做的需求,或者只是因為業務方為了kpi的好看,當然也有可能最后的結果是這是一個很重要很嚴肅的需求。

三、及時提出自己的疑惑

不要帶著疑惑去處理需求,因為這個就像滾雪球,隨著更多業務的不斷增加,因為一開始的疑惑,而導致更多的不理解出現,這是一個令人懊惱的過程。因此在需求伊始,一定要將自己對需求的疑惑,充分地表達出來,好讓需求方自檢的同時,也好對你的問題進行一遍梳理。

對于怎么更好的理解需求,先說這么多;接下來是當你對于需求重逢理解之后,要如何去處理需求。大致也分為以下幾個部分:

1、調研

調研的方式有很多,比如通過數據進行一個趨勢分析,或者通過桌面研究,競品分析,定量定性的研究種種,但是你在具體實施的時候要考慮需求的等級,其時間周期以及本身的資源限制,來進行,不然這一步是無法開始的。但是基本的調研還是要有的,不然你無法應付后期的審稿模塊。

假設如果沒有這些先天的條件,那你就要依賴自己的專業能力和經驗來解決了,但是同時也可以在需求的處理過程中,去煩一煩pm,盡可能的闡述自己的具體解決辦法。

2、合理的排期

產品上一直有句話叫“先有再說”,聽起來好像不是那么負責任,其實這里的的先有再說,不是意味著有了之后就不管了,拋諸腦后,而是先將某個功能做上去,然后通過版本的不斷疊加,最后達到產品的完美。你可能會說為什么在一開始就讓它達到完美?但是其實在真實的環境中,一個功能需求的誕生和上線,時間都是非常緊湊的,你如果想在上線的初期就讓產品趨于完美,那就需要大量的時間成本和人力成本來進行保障,但是這樣往往解決了功能的不完美性,但是再上線,發現其他產品早就開始下一個產品亮點的推進了。

3、溝通與推動

在需求處理的末尾,你需求整理自己的稿件,標好相關信息進行,將自己的想法以及界面的相關信息進行整理,然后發到承接此項目的小伙伴手中。但這僅僅只是開始,你還要在具體的開發過程中,隨時待命,比如一些技術限制,需求優先級,邏輯漏洞等,這些問題會陸陸續續的找上你,你要有解決這么矛盾沖突的地方,并解決它。關于推動,不僅要跟蹤開發的進度,還要是不是關心一下是不是項目遇到了什么問題,有時候自以為制作的產品邏輯上都沒有問題,但是開發小哥哥可以靈光一閃的告訴你同樣一個解決問題的更簡單的方法,讓你欽佩不已。

當然在需求的具體實施中,你可能要參加審稿大會,你要接受各個方面的質疑,也就是撕逼,他們考慮問題的角度和出發點都和你不一樣,所以要善于傾聽和接受,實在是無法妥協的地方可以再找一些方法來進行驗證,比如灰度發布 a/b測試等。但是不能找身邊的人舉手表決,個人認為不是很專業,公平性也有待商榷。

總結一下

沒有說太多理論性的東西,只是說了一些工作中的細節,我不是說理論性的東西不好,理論是基石,是想法的源泉,但是在和業務,pm爭得面紅耳赤的時候,更多的是對自己怎么去掌控各方的意見,和尋找突破口。

 

作者:秦東源,個人公眾號:海鮮君的設計物語

本文由 @秦東源 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!