從產(chǎn)品經(jīng)理的技術理解力看產(chǎn)品需求流程
一、寫在前面
鵝廠對產(chǎn)品經(jīng)理的能力項要求中有一條重要考量,叫做技術理解力。我一直在思考學習,怎樣才能算得上是具有技術理解力,也一直把提升技術理解力作為自己工作目標,直到最近,聽曾經(jīng)策劃并實現(xiàn)央視微信搖春晚的技術哥哥分享之后,才恍然大悟,所謂的技術理解力,不是讓產(chǎn)品經(jīng)理學看代碼,而是在溝通、需求、及項目推進時,思考方式與技術人員保持基本同步。這應該怎么理解呢?就讓我們從一個需求流程的角度來詳細說明吧。
需求來源有很多途徑:用戶調(diào)研、反饋,產(chǎn)品創(chuàng)新、升級、迭代、運營,市場分析,競品對標,甚至是老板需求等等不一而足、不可勝數(shù)。在傳統(tǒng)意義上,產(chǎn)品經(jīng)理根據(jù)需求特性,抽象產(chǎn)品特性,思考產(chǎn)品邏輯,制定產(chǎn)品目標、愿景、實施計劃,擬定詳細的文檔,按照交互-設計-重構-前后臺開發(fā)-測試驗收上線的流程,一步步推進即可。但看似合理且被大多數(shù)產(chǎn)品經(jīng)理認為是理所當然的流程中,卻隱藏著技術理解層面嚴重的bug。
二、對軟件設計的理解問題
大家知道,軟件開發(fā)設計有“面向過程”和“面向?qū)ο蟆敝郑m然兩種方式之間有千絲萬縷的關系,但在思考方式層面,卻有很大的區(qū)別:
- 面向過程,是指以任務/事件為中心,進行軟件設計。
- 面向?qū)ο?,是指以事物為中心的軟件設計。
舉個用戶要搭乘地鐵從T站到F站的簡單例子來說明:
如果用面向過程的設計方式,會將地鐵啟動、運行、到站等一系列的動作設定為過程,也許還要設定地鐵維修的過程。然后將這所有的過程按照邏輯串在一起,完成一個任務。
如果用面向?qū)ο蟮姆绞皆O計,那直接將地鐵定義為對象,地鐵的顏色、形狀等則為屬性,地鐵的運行和到站就是地鐵的方法,也即地鐵的行為,而不是過程。
參照軟件設計的方式,產(chǎn)品經(jīng)理在思考需求、抽象產(chǎn)品特性和邏輯時,也有類似的思考方式的區(qū)別:
- 有時過于關注產(chǎn)品如何實現(xiàn)每一個步驟,就難以描繪產(chǎn)品大局,難以把握用戶分類、了解每一類用戶的目標;又有時如果面向?qū)ο?,就有可能將簡單的邏輯復雜化。這樣沒用明確思考方式的情況下,無論是產(chǎn)品PRD、交互或開發(fā)溝通,都可能產(chǎn)生分歧。
- 要達到合理的技術理解,需要在需求思考環(huán)節(jié),就要考慮使用哪種思維方式繼續(xù),尤其是需要和技術人員提前溝通,磨合雙方對于產(chǎn)品需求思考的方式,是需要面向過程,還是需要面向?qū)ο蟆?/li>
- 在溝通的基礎上,繼續(xù)詳細的設計產(chǎn)品:明確產(chǎn)品用戶分類、每一類用戶的目標以及行為路徑,從而明確產(chǎn)品特性和邏輯。根據(jù)每類用戶的情況,擬定對應的流程、時序、交互等一系列所需的說明,然后再提交技術開發(fā)。產(chǎn)品與技術這樣同步的思維方式,相信可以免去很多需求設計轉換為軟件設計時的問題。
三、對需求實施的理解問題
很多產(chǎn)品經(jīng)理都說過這樣的話:這個需求很簡單,隨便改改就可以啦。當然,這也是技術同學最不喜歡的話之一,我也不例外,曾因為一個簡單頁面的圖文修改,對技術人員嗤之以鼻,但當了解內(nèi)情后才發(fā)現(xiàn),不僅僅是修改html的問題,還涉及到css、json、數(shù)據(jù)庫讀取修改以及數(shù)據(jù)字段的調(diào)整。所以對于需求的理解,從產(chǎn)品經(jīng)理和技術人員角度而言,所看到的大小和范圍,也許就像冰山一樣,水面和水底有很大的區(qū)別。
在這種技術層面的改動要大于產(chǎn)品預期的情況,難免就會產(chǎn)生分歧。為了盡量使需求的實施理解,也能保持同步,可以參考以下要素:
- 參加技術人員的概要設計評審:當產(chǎn)品需求提到技術層面時,一般技術人員會對需求進行概要設計、評審、詳細設計及評審、開發(fā)實施等環(huán)節(jié)。當然產(chǎn)品經(jīng)理一般不會在技術層面介入太深,但為了盡量使需求不偏離目標,參加技術層面的概要設計評審,是很好的一個選擇,雖然對于多數(shù)產(chǎn)品經(jīng)理而言,不一定能全聽懂技術在概要設計層面的討論。參加概要設計評審可以了解需求在啟動技術設計時,涉及到的相關系統(tǒng)、干系人、內(nèi)外部團隊等,大致了解技術實施層面的困難、瓶頸和資源需求。以減少用戶類型、路徑等環(huán)節(jié)的偏差。
- 提前向技術同步產(chǎn)品的遠期愿景:同步產(chǎn)品愿景和長期版本目標,可以是在需求剛出現(xiàn)時,也可以是在交互設計時,但個人感覺最晚不能晚于技術的概要設計。提前同步產(chǎn)品愿景,可以在技術人員做技術設計時,能確定數(shù)據(jù)、架構、迭代以及預留字段,更能確定技術實現(xiàn)方式,是按照較大的系統(tǒng)實施,還是按照簡單的邏輯實施,因為很多時候,技術的實現(xiàn)方式有多種選擇。以免產(chǎn)品的期望是宏偉大廈,因為沒有提前同步給技術,導致技術在打地基時,按照普通的平房實施了。
- 了解需求中的關鍵點:這一點需要在每一次技術溝通中進行確認,但盡量在技術概要設計前了解清楚,這也就是參加技術概要設計評審的重要性所在。了解需求的關鍵點,了解了相關困難、瓶頸、資源需求等,對于需求實施的排期、時間節(jié)點評估則會掌握的比較清晰。
所以對于需求實施的理解,產(chǎn)品和技術保持同步,才能使需求實施事半功倍。
四、對項目進度推進的理解問題
需求項目進度溝通方面,產(chǎn)品和技術的理解也存在分歧:評估的時間點內(nèi)不能完成目標,甚至沒有明確的時間評估。面對這樣的問題,最重要的,肯定是按照前期的溝通制定計劃,正如搖春晚技術哥哥的說法,就是有了計劃,才能感知變化。因此建議考慮以下元素:
- 根據(jù)需求的關鍵點,把控項目進度:前文提到,了解需在技術實施環(huán)節(jié)的關鍵節(jié)點,目的就是為了整體把控需求,防止在關鍵節(jié)點掉鏈子。有時是需要產(chǎn)品協(xié)助,或是督促技術打通關鍵節(jié)點的問題,有時則是因為前期的評估和了解,提前將實施中關鍵節(jié)點可能存在的問題消化掉。
- 需求實施的“時間最小單元”不能太久:需求實施的“時間最小單元”,我把它定義為,需求實施過程中,可以標識為里程碑或是有明確交付物的最短時間。例如一個H5的登錄注冊功能的開發(fā),判斷每個輸入框信息輸入格式是否準確,將信息提交至數(shù)據(jù)庫,數(shù)據(jù)庫寫入數(shù)據(jù)并返回是否正確寫入,給用戶對應的反饋,這些每個環(huán)節(jié)的開發(fā)所需時間,都可以理解為一個時間最小單元。按照正常的邏輯,這樣的時間最小單元,建議是0.5天至3天,最好不超過3天。
- 時不時的討論推進的困難和進度:對于推進實施中的需求,不能當成一個完全交出去的任務,更不能當“甩手掌柜”,而是應該參照時間最小單元,不時的討論推進中是否存在困難,應如何解決困難,詢問時間最小單元中的推進進度,如有沒有進度,則可能需要調(diào)整計劃了。
所以從項目進度推進角度,也是需要產(chǎn)品和技術都轉換思維,首先是了解對方的想法,然后是從對方角度思考,共同發(fā)掘問題和困難所在,再去解決。這樣提前預估、制定時間節(jié)點、共同督促的推進方式,才能使項目推進更順利。
五、本文總結
至此,個人感覺通過思維同步、需求同步、技術同步、項目推進同步以及溝通同步這些元素,可以更好的推進需求。
因此個人斗膽將一個產(chǎn)品需求流程的走法,優(yōu)化為:
- a、(與技術人員溝通面向過程還是面向?qū)ο蟮乃伎挤绞剑└鶕?jù)需求特性,抽象產(chǎn)品特性;
- b、思考產(chǎn)品邏輯,制定產(chǎn)品目標、愿景(同步與技術人員討論產(chǎn)品愿景);
- c、制定(初步)實施計劃,擬定詳細的文檔,交互及溝通-設計及溝通;
- d、(參與軟件概要設計評審,評估項目時間排期及執(zhí)行中的困難);
- e、(制定開發(fā)計劃,任務拆分到0.5天至3天)重構及前后臺開發(fā);
- f、(討論推進中的困難,咨詢督促進度);
- g、測試驗收-上線-優(yōu)化迭代;
其中括號中的內(nèi)容,則為優(yōu)化后的流程內(nèi)容。
以上理論及觀點,均為個人思考歸結,不一定是適用于所有需求和項目,也不一定適合所有的產(chǎn)品和技術,但還是希望對我們的工作推進,起到一定參考作用。
最后引用鄧小平爺爺?shù)囊痪湓?,白貓黑貓,能捉老鼠就是好貓。共勉?/p>
#專欄作家#
陳勃,微信公眾號:哈勃筆跡(habobiji),人人都是產(chǎn)品經(jīng)理專欄作家,互聯(lián)網(wǎng)從業(yè)6年,騰訊產(chǎn)品經(jīng)理。對于互聯(lián)網(wǎng)與航空的結合、互聯(lián)網(wǎng)產(chǎn)品有較深入的了解且持續(xù)關注中。愛好音樂與文學,文藝青年一枚。
本文系作者授權發(fā)布,未經(jīng)許可,不得轉載。
感覺很有用,收藏了,謝謝
雖然我還沒達到考慮這些問題的地步,不過還是看完了,默默收藏,日常工作中必定會有不一樣的理解
已讀,任何合作最不可缺少的就是溝通,我現(xiàn)在工作也是很深刻的認識到合作交流與溝通的重要性。
不錯,跟技術用類似技術的語言交流減少理解和認知差異