產品設計人員有一項重要的工作,就是將自己所設計的東西交付給研發,由研發人員進行後續的工作。最終產品的實現,還是要依靠我們辛勞的研發同志。所以就有了產品交付會。

有些公司叫需求評審會,但是我個人認為交付與評審還兩個概念,可是也並非不可并行。在我看來,“交付”,是將確定無誤的東西給到研發(還是那句話,確定無誤?臣妾做不到啊~),而“評審”,更多在於“評”。由大家集思廣益,對產品設計進行優化。

然而如果項目比較緊急,不會有專門的評審會,只能依靠前期的溝通,來完成大部分“評”的工作。

此次我重點說產品交付會。而且前提是大家對要做什麼功能已經有了基本了解,但是具體的細則,還是需要小小的“講&評”一下。

拿我所經歷過的交付會和評審會來說,基本流程差不多,而且也挺有意思。所以特特做了一組小漫畫,讓大家感受一下這種氣氛。

(截圖+axure排版,視覺效果還請不要挑剔)

PS:

本身產品評審就是個枯燥的工作,產品人員不停的講,研發人員不停的腦補。如果提前不做準備的話,還真不知道產品在BB什麼。

所以我通常的做法是:

提前一天將交付的內容發給研發人員,並在郵件中註明,此次要新增什麼功能。貼上對應的DEMO地址,方便研發人員查看,這樣交付會就會開得比較有針對性。

在之前的文章中我曾經提過,修改了哪些地方要明明白白的標記出來,具體可以查看 WEB端UE設計及管理規範-2

PS:

上文也提到了,交付的過程也是PK的過程。研發可能會提出的問題大概有這麼幾種:

  1. 你剛才說的某個功能,我沒怎麼聽明白,能不能再說一下?
  2. 這個功能做的有意義么?我怎麼覺得好像沒有必要啊。(其實他們想說,這TM做了誰用啊)
  3. 你有沒有考慮到這麼整會影響到**、**、**、**地方啊?那些地方你打算怎麼處理?
  4. 你這邊的邏輯是這樣設計的,但我們那邊數據庫不是這麼設計的,可否換種實現方式啊?
  5. 你這個業務規則設定的壓根就不符合邏輯啊……

同樣見着拆招了

Q:你剛才說的某個功能,我沒怎麼聽明白,能不能再說一下?

A:一般交付其實不用說的太詳細,我曾經也細緻到單個字段,但是發現效果並不好。既浪費時間,而且也沒有人能耐着性子那麼長時間都集中注意力聽你BB,所以撿主要的講即可。如果你沒聽明白,沒關係,我再稍微具體點跟你說清楚。如果我說完,你沒問題了,就視為你認可了。

Q: 這個功能做的有意義么?我怎麼覺得好像沒有必要啊。(其實他們想說,這TM做了誰用啊)

A: 此時可以搬出用戶的需求、市場的需求、競品的分析等等來說服研發,最後來一句:我們所做的每一個功能,都是經過深思熟慮的,這你放心好了。但是千萬不要說,這是我們定好的,你們執行就行了,不用管他合不合理。如果你真的這麼說了,研發人員內心已經把你捅了N多遍了。強壓之下給你來個罷工,那你就沒轍了。

Q: 你有沒有考慮到這麼整會影響到**、**、**、**地方啊?那些地方你打算怎麼處理?

A: 如果你已經考慮到了,那最好,請直接陳述即可。如果你本身沒有考慮到,這時就要趕緊服軟。因為當你說這個功能的時候,程序猿同學已經在腦海中遍歷一遍了,他們是思維嚴謹的單線程生物,只要他們提出來的,絕大多數都是會真的產生影響的,你也沒必要嘴硬死不承認。此時最好的方式就是趕緊說好話:哇塞,猿哥想的好全面啊,我都沒有想好,我回去要好好補上,多跟猿哥你請教請教。那這一塊等我補上之後再發出來大家看看,成不?

Q: 你這邊的邏輯是這樣設計的,但我們那邊數據庫不是這麼設計的,可否換種實現方式啊?

A: 可愛的程序猿不是執行任務的工具,他們很有自己的想法,所以當他們提出這個問題的時候,多半其實已經幫你想好解決方案了。你只需要說:具體要的嘛,就是這麼一個功能,猿哥你有什麼好的意見,如果實現簡單,那當然是按照你的方式來執行了。可是前提要滿足我這個功能哦。

Q: 你這個業務規則設定的壓根就不符合邏輯啊……

A: 遇到這樣的問題,就好比產品人員心理出現了個晴天霹靂。。來,哥我們慢慢說,哪裡不符合邏輯了,如果確實是有邏輯漏洞,如果影響比較大,建議會議結束吧,產品人員回去好好反省去吧。如果是小的漏洞,那我們就商量下怎麼彌補了吧。

PS:

驚險過後,繼續開會,下一個功能,又是一次PK的開始。

PS:

評估工作量的時候,我個人基本是不會插嘴的,除非是大家需要回顧剛才的功能點,我會再簡單幫大家梳理一下。畢竟研發需要多久,研發心裏面更清楚,大家都是一個團隊的,合作就是建立在互相信任的基礎上的,也沒有必要特別去壓迫別人的時間。

PS:

會議結束,此時通常一個半天就過去了,產品趕緊要把會議中承諾要完善的部分完善起來,因為接着就要進入開發了,如果遲遲不調整,等於間接壓縮了研發的時間,這樣大家心情就不美麗了。

最後:

跟研發人員合作這麼多年,我始終認為,研發哥哥們,是一個很可愛的群體,雖然經常會被我給坑到,也會經常背後吐槽(沒關係,只要你們開心,儘管吐槽好了),但是真心來說,只要你本身做的夠好,研發人員基本不會故意推脫工作。偶爾不開心,哄一哄很快就沒事了,所以我個人特別喜歡跟程序猿混。

 

作者:宋娟(個人公眾號 UED_ID_Designer),曾在蘇寧易購、焦點科技就職過,現在一個創業團隊任職UE主管。6年互聯網產品設計經驗,曾主導蘇寧易購以及百卓採購網等多款產品的產品規劃和設計工作。個人網站地址:www.so-sweet.cn

本文由 @宋娟 原創發佈於人人都是產品經理 ,未經許可,禁止轉載。