|
有一個新創(chuàng)業(yè)的項目，我個人有一點點投資參與的，最近開發(fā)進度一直不如預期，因為開發(fā)的負責人也是我認識很久的一個朋友，所以有點奇怪，就去聊了聊。（說來慚愧，主要我也有責任，本來答應一開始研發(fā)就介入做一些技術溝通的工作，結果自己太懶，一直沒太多過問） 然后發(fā)現(xiàn)，問題主要還是出現(xiàn)在溝通環(huán)節(jié)。這個創(chuàng)業(yè)團隊的負責人，業(yè)務運營能力應該還是有的，但是他們之前沒有技術產品開發(fā)的經驗，簡單說就是，團隊里缺乏一個產品經理的角色，需求的反復和雙方理解的歧義導致了研發(fā)周期的延宕。
這個場景相信很多創(chuàng)業(yè)公司，甚至規(guī)模不小的公司都出現(xiàn)過，我也不敢說自己就可以徹底的解決，但是還是分享一下關于產品需求設計與開發(fā)溝通的一些觀點。
第一要旨： 產品人員在提出功能需求時，應明確告訴開發(fā)人員，其需求的目標是什么。
很多產品人員做需求設計，給開發(fā)的時候只告訴開發(fā)你要做這個這個，那個那個，而并不具體說明為什么要做這些，也許他們認為開發(fā)不需要了解這個，也許他們認為開發(fā)應該一看就明白這是什么，但實際上，往往這里就產生理解歧義。這是很常見的問題。
此外，產品人員，特別是沒有技術背景或技術背景一般的產品人員，有時候會替開發(fā)人員多想，比如會認為這樣做簡單而那樣做復雜，但也許技術實現(xiàn)成本并不是他想象的那樣，而對于創(chuàng)業(yè)公司，實現(xiàn)成本往往也是特別重要的需要考慮的因素，產品人員往往沒有給出實現(xiàn)成本最低的方案，而開發(fā)人員則盲目按照定義的需求出發(fā)，有時候做出的東西從實現(xiàn)成本來說非常不經濟，特別是時間成本，消耗非常巨大。
在符合第一要旨的前提下，開發(fā)人員應能參與需求的討論，我知道有些大公司或者產品經理不希望這樣，我定義好的需求你去實現(xiàn)就好了，你做研發(fā)的討論這個干什么？ 但這樣其實是有好處的。
- 研發(fā)人員的參與意識強，對產品的熱愛度和積極性會提高。
- 加深對需求目標的理解，減少開發(fā)過程中因理解歧義做出無用功或不符合需求的狀況。
- 有可能提供目標一致，而更低實現(xiàn)成本的方案。對創(chuàng)業(yè)公司，開發(fā)力量不夠完善的場景而言，這一點也非常重要。
當然，強調一點，研發(fā)人員可以參與需求設計的討論，但決策權仍需要明確掌握在產品經理手里，（如果研發(fā)人員確實更懂得需求定義，可以兼任產品經理。但只要你賦予了獨立的產品經理角色，這個需求的決策權還是必須給予保證的。）
第二要旨：產品人員應給出所有功能需求的流程和結構圖
在給出具體功能需求設計之前，應給一個總綱，也是為了加深需求理解，形成完整的需求概念的一步重要工作。
很多時候，產品經理會覺得，我說的都那么清楚了，你怎么不明白呢？ 其實主要就是因為在這個環(huán)節(jié)上產品經理對整個項目的背景，結構，前提，目標早已有了代入感，所以覺得每個細節(jié)都理所當然是這樣的，但是對研發(fā)而言，他們并沒有得到完整的背景信息，對細節(jié)的理解往往就出現(xiàn)偏差和誤判。對彼此功能點的關系，相互的聯(lián)系了解的支離破碎，那么實現(xiàn)起來這個系統(tǒng)也就難免出現(xiàn)不盡如人意的地方。
常見的，比如，用戶的某個屬性，在某個功能中體現(xiàn)出來，而在另一個功能中被賦予或產生變化的，但是因為需求設計的時候，沒有給出整體的結構和流程，只是在局部的設計中提供了不精確不嚴謹?shù)拿枋觯óa品經理也許覺得描述的足夠清楚了，但是缺乏必備的背景信息鋪墊），那么實現(xiàn)的工程師，（甚至可能兩個不同功能是不同工程師實現(xiàn)），也許會誤判做成兩個不同的字段，賦予不同的定義。這樣這個屬性的實現(xiàn)就徹底錯了，而在上線前甚至雙方都沒意識到存在這樣的問題。
第三要旨：具體視圖設計的三要素
不論是設計網(wǎng)站，還是設計app，基本都是由一個到多個交互視圖組成需求設計。
產品人員在提供這樣的應給與研發(fā)者如下三要素：
界面元素
比如哪里是文字，哪里是下拉框，哪里是按鈕，這些屬于界面元素，可以用草圖，或word簡單排版，但要明確界面上的元素是什么，如何展現(xiàn)。是靜止？浮動？
數(shù)據(jù)邏輯
這一點往往也是非常多創(chuàng)業(yè)團隊和新手產品經理容易忽視的，比如頁面這里是最新新聞，那么你要說明，這個最新新聞是基于怎樣的數(shù)據(jù)邏輯獲取的，當然這個基本上工程師都知道，按照時間逆序就好，但是如果涉及，比如有一個區(qū)塊叫做推薦游戲，那么你要告訴開發(fā)人員，這個推薦游戲是從什么地方取出來的信息，按照什么邏輯取出來的。有的產品經理說，這不是技術活么？我怎么知道？ 哦，要是真不知道，就要跟技術人員溝通這個問題，看看你需要這個地方出現(xiàn)的東西體現(xiàn)出怎樣的一種特征，然后問他應該怎么來設計，然后你也要參與思考，這個數(shù)據(jù)邏輯是否符合用戶的預期，以及在運營中是否會出現(xiàn)一些比如說位置會固化，新數(shù)據(jù)無法體現(xiàn)的問題，這些都是產品經理要思考和確認的，不能說甩手給技術，當然，如果你遇到一個特別有產品經驗和理念的工程師，他真能幫你都解決好，但這情況其實非常罕見。
操作邏輯
界面上可以進行操作的有哪些元素，哪個可以點擊，可以選擇，操作后出現(xiàn)怎樣的反饋，比如顯示浮層？進入新頁面？或怎樣怎樣？ 這也是要在需求設計文檔里說清楚的。
一個視圖的設計，說清楚界面元素，數(shù)據(jù)邏輯，操作邏輯，開發(fā)者才能明確這個視圖的開發(fā)需求。不要讓開發(fā)的工程師自己去猜，去揣測，如果有些邏輯涉及算法，產品經理不清楚，也要與開發(fā)者確認他所采用的邏輯是什么，以及效果是什么，并與自己所預期的效果做比對，而不是說，這個我不清楚，讓工程師決定。 操作邏輯可能會指向其他視圖，這就是前面說的，結構流程圖要說明的地方。
在百度這樣的公司，產品經理要寫繁瑣冗長的MRD，（其實早期的MRD不繁瑣，也不冗長，但后來對需求定義的精確性要求越來越高，內容就越來越繁冗了）。其實我不喜歡這樣的風格，溝通成本太高，所以對于創(chuàng)業(yè)公司而言，還是盡可能簡單直接有效最好。 那么我認為，要做到簡單直接有效，做好如上幾點，對于大部分場景來說，應該就可以滿足。
重復一下，第一，要讓開發(fā)工程師明確需求的目的并參與討論。第二，要給出結構圖，流程圖，對需求有完整的認識。第三，針對具體的視圖，提供元素，數(shù)據(jù)邏輯，操作邏輯 三要素，其實并不會很復雜，正常一個視圖寫一頁到兩頁就夠了。如果開發(fā)工程師配合比較默契，有較多合作基礎，中間很多內容可以寫個略字。但是這個結構建議還是養(yǎng)成習慣。
說一個執(zhí)行中的要點，當產品經理給技術人員展示完文檔，表達完需求后，最好的一種確認方式是讓技術人員按照自己理解重述一下需求，重述的過程往往容易暴露出理解的歧義。確保你表達的與對方理解重述的一致，這樣有可能減少很多后續(xù)的麻煩。
今天講的主要是產品經理如何更好的與技術溝通；那么在產品設計中，如何更好的滿足用戶需求，是另一個特別大的話題，以后有機會我們再聊聊看。
|
