有一個新創業的項目,我個人有一點點投資參与的,最近開發進度一直不如預期,因為開發的負責人也是我認識很久的一個朋友,所以有點奇怪,就去聊了聊。(說來慚愧,主要我也有責任,本來答應一開始研發就介入做一些技術溝通的工作,結果自己太懶,一直沒太多過問) 然後發現,問題主要還是出現在溝通環節。這個創業團隊的負責人,業務運營能力應該還是有的,但是他們之前沒有技術產品開發的經驗,簡單說就是,團隊里缺乏一個產品經理的角色,需求的反覆和雙方理解的歧義導致了研發周期的延宕。

這個場景相信很多創業公司,甚至規模不小的公司都出現過,我也不敢說自己就可以徹底的解決,但是還是分享一下關於產品需求設計與開發溝通的一些觀點。

第一要旨: 產品人員在提出功能需求時,應明確告訴開發人員,其需求的目標是什麼。

很多產品人員做需求設計,給開發的時候只告訴開發你要做這個這個,那個那個,而並不具體說明為什麼要做這些,也許他們認為開發不需要了解這個,也許他們認為開發應該一看就明白這是什麼,但實際上,往往這裏就產生理解歧義。這是很常見的問題。

此外,產品人員,特別是沒有技術背景或技術背景一般的產品人員,有時候會替開發人員多想,比如會認為這樣做簡單而那樣做複雜,但也許技術實現成本並不是他想象的那樣,而對於創業公司,實現成本往往也是特別重要的需要考慮的因素,產品人員往往沒有給出實現成本最低的方案,而開發人員則盲目按照定義的需求出發,有時候做出的東西從實現成本來說非常不經濟,特別是時間成本,消耗非常巨大。

在符合第一要旨的前提下,開發人員應能參与需求的討論,我知道有些大公司或者產品經理不希望這樣,我定義好的需求你去實現就好了,你做研發的討論這個干什麼? 但這樣其實是有好處的。

  1. 研發人員的參与意識強,對產品的熱愛度和积極性會提高。
  2. 加深對需求目標的理解,減少開發過程中因理解歧義做出無用功或不符合需求的狀況。
  3. 有可能提供目標一致,而更低實現成本的方案。對創業公司,開發力量不夠完善的場景而言,這一點也非常重要。

當然,強調一點,研發人員可以參与需求設計的討論,但決策權仍需要明確掌握在產品經理手裡,(如果研發人員確實更懂得需求定義,可以兼任產品經理。但只要你賦予了獨立的產品經理角色,這個需求的決策權還是必須給予保證的。)

第二要旨:產品人員應給出所有功能需求的流程和結構圖

在給出具體功能需求設計之前,應給一個總綱,也是為了加深需求理解,形成完整的需求概念的一步重要工作。

很多時候,產品經理會覺得,我說的都那麼清楚了,你怎麼不明白呢? 其實主要就是因為在這個環節上產品經理對整個項目的背景,結構,前提,目標早已有了代入感,所以覺得每個細節都理所當然是這樣的,但是對研發而言,他們並沒有得到完整的背景信息,對細節的理解往往就出現偏差和誤判。對彼此功能點的關係,相互的聯繫了解的支離破碎,那麼實現起來這個系統也就難免出現不盡如人意的地方。

常見的,比如,用戶的某個屬性,在某個功能中體現出來,而在另一個功能中被賦予或產生變化的,但是因為需求設計的時候,沒有給出整體的結構和流程,只是在局部的設計中提供了不精確不嚴謹的描述(產品經理也許覺得描述的足夠清楚了,但是缺乏必備的背景信息鋪墊),那麼實現的工程師,(甚至可能兩個不同功能是不同工程師實現),也許會誤判做成兩個不同的字段,賦予不同的定義。這樣這個屬性的實現就徹底錯了,而在上線前甚至雙方都沒意識到存在這樣的問題。

第三要旨:具體視圖設計的三要素

不論是設計網站,還是設計app,基本都是由一個到多個交互視圖組成需求設計。

產品人員在提供這樣的應給與研發者如下三要素:

界面元素

比如哪裡是文字,哪裡是下拉框,哪裡是按鈕,這些屬於界面元素,可以用草圖,或word簡單排版,但要明確界面上的元素是什麼,如何展現。是靜止?浮動?

數據邏輯

這一點往往也是非常多創業團隊和新手產品經理容易忽視的,比如頁面這裡是最新新聞,那麼你要說明,這個最新新聞是基於怎樣的數據邏輯獲取的,當然這個基本上工程師都知道,按照時間逆序就好,但是如果涉及,比如有一個區塊叫做推薦遊戲,那麼你要告訴開發人員,這個推薦遊戲是從什麼地方取出來的信息,按照什麼邏輯取出來的。有的產品經理說,這不是技術活么?我怎麼知道? 哦,要是真不知道,就要跟技術人員溝通這個問題,看看你需要這個地方出現的東西體現出怎樣的一種特徵,然後問他應該怎麼來設計,然後你也要參与思考,這個數據邏輯是否符合用戶的預期,以及在運營中是否會出現一些比如說位置會固化,新數據無法體現的問題,這些都是產品經理要思考和確認的,不能說甩手給技術,當然,如果你遇到一個特別有產品經驗和理念的工程師,他真能幫你都解決好,但這情況其實非常罕見。

操作邏輯

界面上可以進行操作的有哪些元素,哪個可以點擊,可以選擇,操作后出現怎樣的反饋,比如显示浮層?進入新頁面?或怎樣怎樣? 這也是要在需求設計文檔里說清楚的。

一個視圖的設計,說清楚界面元素,數據邏輯,操作邏輯,開發者才能明確這個視圖的開發需求。不要讓開發的工程師自己去猜,去揣測,如果有些邏輯涉及算法,產品經理不清楚,也要與開發者確認他所採用的邏輯是什麼,以及效果是什麼,並與自己所預期的效果做比對,而不是說,這個我不清楚,讓工程師決定。 操作邏輯可能會指向其他視圖,這就是前面說的,結構流程圖要說明的地方。

在百度這樣的公司,產品經理要寫繁瑣冗長的MRD,(其實早期的MRD不繁瑣,也不冗長,但後來對需求定義的精確性要求越來越高,內容就越來越繁冗了)。其實我不喜歡這樣的風格,溝通成本太高,所以對於創業公司而言,還是盡可能簡單直接有效最好。 那麼我認為,要做到簡單直接有效,做好如上幾點,對於大部分場景來說,應該就可以滿足。

重複一下,第一,要讓開發工程師明確需求的目的並參与討論。第二,要給出結構圖,流程圖,對需求有完整的認識。第三,針對具體的視圖,提供元素,數據邏輯,操作邏輯 三要素,其實並不會很複雜,正常一個視圖寫一頁到兩頁就夠了。如果開發工程師配合比較默契,有較多合作基礎,中間很多內容可以寫個略字。但是這個結構建議還是養成習慣。

說一個執行中的要點,當產品經理給技術人員展示完文檔,表達完需求后,最好的一種確認方式是讓技術人員按照自己理解重述一下需求,重述的過程往往容易暴露出理解的歧義。確保你表達的與對方理解重述的一致,這樣有可能減少很多後續的麻煩。

今天講的主要是產品經理如何更好的與技術溝通;那麼在產品設計中,如何更好的滿足用戶需求,是另一個特別大的話題,以後有機會我們再聊聊看。

 

作者:曹政

微信公眾號:caoz的夢囈(caozsay)