認(rèn)識產(chǎn)品經(jīng)理-來自于唐杰(3,4章)

第三章:產(chǎn)品設(shè)計

產(chǎn)品設(shè)計是一個由抽象的概念到具體形象化的處理過程,通過文字或圖像等方式將我們規(guī)劃的產(chǎn)品需求展現(xiàn)出來。它將產(chǎn)品的某種目的或需求轉(zhuǎn)換為一個具體的物理或工具的過程,把一種計劃、規(guī)劃設(shè)想、問題解決的方法,通過具體的操作,以理想的形式表達(dá)出來。

由于產(chǎn)品設(shè)計階段要全面確定整個產(chǎn)品策略、外觀、結(jié)構(gòu)、功能,從而確定整個產(chǎn)品系統(tǒng)的布局,因而,產(chǎn)品設(shè)計的意義重大,具有“牽一發(fā)而動全局”的重要意義。如果一個產(chǎn)品的設(shè)計缺乏具體形象的表述,那么研發(fā)時就將耗費大量資源和勞動力來調(diào)整需求。相反,好的產(chǎn)品設(shè)計,不僅表現(xiàn)在功能上的優(yōu)越性,而且便于執(zhí)行時理解,從而使產(chǎn)品的研發(fā)效率得以增強(qiáng)。

1、產(chǎn)品需求文檔介紹

產(chǎn)品設(shè)計的最終表述的形式被稱為產(chǎn)品需求文檔,業(yè)界常常稱呼為PRD文檔,這是英文Product Requirement Document的縮寫。產(chǎn)品需求文檔是將產(chǎn)品規(guī)劃和設(shè)計的需求具體形象化表述出來的一種展現(xiàn)形式,主要用于產(chǎn)品界面設(shè)計和研發(fā)使用。

PRD文檔是基于BRD、MRD的延續(xù)文檔,主要是一份給執(zhí)行層面的工作人員閱讀的文檔,這部分人群絕大多數(shù)是設(shè)計與技術(shù)人員。在這類人群中,設(shè)計師更多依賴于產(chǎn)品原型進(jìn)行交互或視覺的設(shè)計,因此看這份文檔的人主要是技術(shù)人員。相對于技術(shù)人員,他們不太關(guān)注產(chǎn)品的商業(yè)需求和市場愿景,因為在進(jìn)行產(chǎn)品討論立項時,產(chǎn)品的定義就已經(jīng)向參與設(shè)計和研發(fā)的人員宣講過,因此技術(shù)人員更多的是關(guān)注界面、功能、交互、元素等等內(nèi)容,因此產(chǎn)品需求文檔是一份詳細(xì)的產(chǎn)品功能需求說明文檔,是產(chǎn)品文檔中最底層和最細(xì)致的文檔。

因為閱讀人類的因素,所以產(chǎn)品需求文檔是一份沒有閑話,直入主題的功能說明文檔。并且產(chǎn)品需求文檔是沒有標(biāo)準(zhǔn)規(guī)范的,也沒有統(tǒng)一的模板,每個公司都不一樣和每個人也不一樣,這個取決于個人習(xí)慣和團(tuán)隊要求。雖然產(chǎn)品需求文檔沒有明確的規(guī)范,但是目的都是一樣的,必須能夠明確產(chǎn)品的功能需求,便執(zhí)行人員理解任務(wù)要求。

2、產(chǎn)品需求文檔寫作

產(chǎn)品需求文檔是產(chǎn)品經(jīng)過規(guī)劃和設(shè)計之后的最終執(zhí)行文檔,因此這份文檔的質(zhì)量好壞直接影響到執(zhí)行部門是否能夠明確產(chǎn)品的功能和性能。

2.1、羅列信息(信息結(jié)構(gòu)圖)

在寫產(chǎn)品需求文檔之前,我們需要先羅列出產(chǎn)品功能的信息內(nèi)容,這一步是將想法逐漸清晰的第一步,也是幫助我們接下來設(shè)計功能的輔助信息,同時也可以輔助服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫。因為這是第一步,所以我們不需要羅列的很詳細(xì),在之后的步驟里,我們會逐步改進(jìn)和完善信息內(nèi)容。

羅列信息內(nèi)容的方式有很多種,文本形式、思維導(dǎo)圖形式等等都可以,最主要的是能夠清晰易懂,我最常用的方法就是使用思維導(dǎo)圖軟件(MindManager)羅列成結(jié)構(gòu)圖,因此我稱這一步為“信息結(jié)構(gòu)圖”。

上圖是一張以Blog系統(tǒng)為示例的信息結(jié)構(gòu)圖。信息結(jié)構(gòu)圖是一種接近數(shù)據(jù)庫結(jié)構(gòu)的圖表,在羅列信息結(jié)構(gòu)時,更多的是考慮信息數(shù)據(jù),但是他并不是真正意義的數(shù)據(jù)庫結(jié)構(gòu)。信息結(jié)構(gòu)圖是提供給產(chǎn)品經(jīng)理自己梳理信息內(nèi)容的結(jié)構(gòu)圖,也是方便產(chǎn)品經(jīng)理和服務(wù)端技術(shù)人員溝通數(shù)據(jù)結(jié)構(gòu)的參考圖,技術(shù)人員會根據(jù)這張圖表的內(nèi)容再結(jié)合產(chǎn)品原型或需求文檔,然后規(guī)劃和設(shè)計出真正意義上的數(shù)據(jù)庫結(jié)構(gòu)。

信息結(jié)構(gòu)圖中關(guān)于友情鏈接功能的信息數(shù)據(jù)只有“名稱”和“鏈接”兩個內(nèi)容,但是在實際功能需求中,友情鏈接還有兩個功能,分別是“顯示或隱藏”和“是否新窗口打開”,這兩個功能會在產(chǎn)品原型和需求文檔中詳細(xì)描述,但是在信息結(jié)構(gòu)中是沒有體現(xiàn)的,因為從產(chǎn)品層面上來說,這兩個只是功能,并不是信息內(nèi)容。但是在真正數(shù)據(jù)庫中,友情鏈接的這兩個功能分別也是有字段參數(shù)的,程序在讀取該參數(shù)后便知道友情鏈接的屬性,然后處理友情鏈接是顯示還是隱藏,是新窗口打開還是本窗口打開。通過友情鏈接這個例子,我們就知道了在實際中數(shù)據(jù)結(jié)構(gòu)和信息結(jié)構(gòu)是不一樣的,信息結(jié)構(gòu)只是產(chǎn)品層面的數(shù)據(jù)內(nèi)容。

無論是什么樣的產(chǎn)品類型,無論從哪里入手,我們第一步都是先要羅列信息結(jié)構(gòu),因為信息結(jié)構(gòu)圖不僅是輔助技術(shù)人員創(chuàng)建數(shù)據(jù)庫的圖表,也是輔助產(chǎn)品人員進(jìn)行產(chǎn)品功能規(guī)劃的參考,只有對信息或數(shù)據(jù)的結(jié)構(gòu)了解了,我們才能更好的設(shè)計產(chǎn)品。信息結(jié)構(gòu)圖是我們將概念想法形成結(jié)構(gòu)化的第一步,也是我們接下來幾步工作的輔助文檔,同時在接下來的幾步工作中,我們還會不斷的完善信息的結(jié)構(gòu)。

2.2、梳理需求(產(chǎn)品結(jié)構(gòu)圖)

當(dāng)我們對產(chǎn)品的信息結(jié)構(gòu)了解后,我們就需要規(guī)整腦海中的產(chǎn)品需求,讓想法更加結(jié)構(gòu)化,因此這一步就要梳理產(chǎn)品的需求。在設(shè)計產(chǎn)品原型之前,我們首先要羅列出產(chǎn)品的功能結(jié)構(gòu),包括頻道、頁面、模塊及元素。這一步依然使用思維導(dǎo)圖軟件,像繪制樓盤鳥瞰圖一樣將產(chǎn)品的結(jié)構(gòu)繪制成結(jié)構(gòu)圖,因此我稱這一步為“產(chǎn)品結(jié)構(gòu)圖”。

產(chǎn)品結(jié)構(gòu)圖是一種將產(chǎn)品原型以結(jié)構(gòu)化的方式展現(xiàn)的圖表,結(jié)構(gòu)內(nèi)容也如同產(chǎn)品原型一樣,從頻道到頁面,再細(xì)化頁面功能模塊和元素。所以產(chǎn)品結(jié)構(gòu)圖是產(chǎn)品經(jīng)理在設(shè)計原型之前的一種思路梳理的方式,并不是給其他工作人員查看的文檔,通過類似鳥瞰式的結(jié)構(gòu)圖可以讓產(chǎn)品經(jīng)理對產(chǎn)品結(jié)構(gòu)一目了然,也方便思考。

如上圖示例,“活動大全”的產(chǎn)品結(jié)構(gòu)依次是:產(chǎn)品 -> 頻道 -> 頁面 -> 頁面元素 -> 操作 ->元素。我們換一個角度觀看示例,產(chǎn)品結(jié)構(gòu)圖實際上就是一種結(jié)構(gòu)化的產(chǎn)品原型。這樣做的目的就是梳理產(chǎn)品結(jié)構(gòu)邏輯,讓我們清楚的知道產(chǎn)品有幾個頻道,頻道下面有沒有子頻道或者有多少個頁面,這些頁面里又有哪些功能模塊,這些功能模塊里又有哪些元素。

上圖以我們第一步的“信息結(jié)構(gòu)圖”為基礎(chǔ)繪制的“產(chǎn)品結(jié)構(gòu)圖”,有了這份結(jié)構(gòu)導(dǎo)圖,我們可以對產(chǎn)品進(jìn)行鳥瞰式考慮和完善,當(dāng)有問題時,修改起來也比原型和文檔方便很多。比如在后續(xù)規(guī)劃中,我們發(fā)現(xiàn)文章的圖片等附件上傳后,管理不太方便,這時就可以在結(jié)構(gòu)圖中增加一個“附件管理”頻道。如果我們使用產(chǎn)品結(jié)構(gòu)圖的方式,那么附件管理的功能增加和修改就會比原型工具更加便捷和效率。

產(chǎn)品結(jié)構(gòu)圖的方法同樣適用于移動互聯(lián)網(wǎng)產(chǎn)品的設(shè)計,并且比起Web產(chǎn)品更加容易梳理產(chǎn)品結(jié)構(gòu)。

產(chǎn)品結(jié)構(gòu)圖是一種讓產(chǎn)品經(jīng)理通過思維導(dǎo)圖的方式梳理思路的方法,通過這種方法可以明確產(chǎn)品有多少個頻道、有多少個頁面、頁面有多少個功能模塊、功能模塊有多少個元素,逐步的將腦海里的想法明確梳理成結(jié)構(gòu)。雖然這種方法能夠明確產(chǎn)品的結(jié)構(gòu),但是這樣的思維導(dǎo)圖也就只有產(chǎn)品經(jīng)理自己能夠看懂,因為對于設(shè)計和技術(shù)人員這是一個抽象的表述方式,如果沒有詳細(xì)的講解,是很難理解的。

產(chǎn)品結(jié)構(gòu)圖是將產(chǎn)品原型具體化的一種方式,只是羅列了產(chǎn)品的頻道頁面和功能,但是沒有詳細(xì)的進(jìn)行推演,關(guān)于細(xì)化方面是否符合產(chǎn)品邏輯,是否符合用戶體驗,這些都是沒有深思過的,因此我們接下來就要進(jìn)行原型設(shè)計,開始具體的考慮可行性。

2.3、原型設(shè)計(界面線框圖)

當(dāng)我們逐漸清晰了產(chǎn)品的需求后,并梳理了產(chǎn)品的各個頻道及頁面,那么這一步就要開始驗證這些想法的具體界面表現(xiàn)和方案的可行性了。

原型設(shè)計是幫助我們更細(xì)致的思考,并做各項需求的評估,同時也是將自己腦海里的想法進(jìn)行輸出的一種方式。通過原型設(shè)計后,我們就可以進(jìn)行產(chǎn)品宣講了,相比較于抽象的文字描述,原型則更加直觀的展現(xiàn)產(chǎn)品的需求,設(shè)計和技術(shù)人員或者老板也能夠更加直觀的了解到產(chǎn)品意圖。

原型設(shè)計是將結(jié)構(gòu)化的需求進(jìn)行框架化,因此原型也被稱為線框圖,具體的表現(xiàn)手法有很多種,相關(guān)的輔助軟件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。

當(dāng)?shù)搅嗽驮O(shè)計這一步時,已經(jīng)不僅僅是構(gòu)思了,我們需要更加深入的了解每個頁面上元素和這些元素的屬性。例如按鈕元素,我們就需要考慮這個按鈕的功能,并且這個功能操作后帶給后端和前端的反饋。例如注冊會員按鈕,用戶操作后,第一步邏輯是驗證用戶輸入的信息是否合法,不合法則給出前端反饋;合法則和后端通信驗證是否已經(jīng)存在同樣信息,已經(jīng)存在則給出前端反饋,不存在則進(jìn)入下一步,注冊成功;注冊成功后的反饋是跳轉(zhuǎn)頁面,還是彈出層提示用戶完善資料,

這些都是需要更詳情的考慮。當(dāng)然這些更細(xì)致的思考是留在需求文檔撰寫時的,而此時我們需要做的就是把這些元素通過原型表現(xiàn)出來。

原型設(shè)計的表現(xiàn)手法主要有三種:手繪原型、灰模原型、交互原型。從工作效率的角度考慮,我非常建議先通過手繪的形式快速在草紙上繪制出產(chǎn)品的原型,推演和討論方案的可行性。當(dāng)方案的可行性被驗證之后,我們再根據(jù)個人習(xí)慣或團(tuán)隊要求,通過軟件工具進(jìn)行更深入的設(shè)計。

① 手繪原型

因為原型也被稱為線框圖,因此手繪是最簡單直接的方法,也是最快速的表現(xiàn)產(chǎn)品輪廓的手法。

手繪原型在初期驗證想法時非常高效,也方便討論和重構(gòu),同時也適合敏捷開發(fā)時快速出原型。

② 灰模原型

灰模原型是由圖形設(shè)計軟件制作而成,最常用的軟件是Photoshop和Fireworks,相對手繪原型,灰模更加清晰和整潔,也適用于正式場合的PPT形式宣講。

灰模原型也可以稱之為平面原型,所以如果不會使用圖形軟件也可以使用Axure RP設(shè)計,相比交互原型,灰模原型只是缺少交互效果,僅僅是將產(chǎn)品需求以線框結(jié)構(gòu)的方式展示出來,讓產(chǎn)品需求更加規(guī)整的直觀展現(xiàn)。

③ 交互原型

交互原型是使用原型設(shè)計軟件完成的原型,常用軟件是AxureRP,通常情況交互原型的設(shè)計要早于產(chǎn)品需求文檔,是產(chǎn)品經(jīng)理想法推演的重要一步。通過AxureRP之類的交互原型軟件制作出來的產(chǎn)品原型,在功能需求和交互需求的表現(xiàn)上,幾乎和正式產(chǎn)品是一致的,所以有時交互原型也被稱為產(chǎn)品Demo版。

通常情況下交互原型是產(chǎn)品經(jīng)理與交互設(shè)計師共同討論確定,然后由交互設(shè)計師制作,但是絕大多數(shù)的公司是沒有交互設(shè)計師這個職位的,因此這類工作最終是由產(chǎn)品經(jīng)理來負(fù)責(zé)的。

以上三種方法并不是漸進(jìn)的流程,而是三種原型設(shè)計的方法,具體取決于你的產(chǎn)品需求和團(tuán)隊要求。

對于產(chǎn)品經(jīng)理來說,原型設(shè)計是為了幫助我們細(xì)致的考慮方案,并論證方案的可行性,同時也是為了產(chǎn)品宣講時讓聽眾能夠清晰直觀的了解產(chǎn)品,避免抽象的語言描述導(dǎo)致聽眾理解困難和理解偏差。產(chǎn)品原型也是為了確保產(chǎn)品在執(zhí)行過程中,是按產(chǎn)品經(jīng)理最初設(shè)想的需求和期望完成的,因此產(chǎn)品經(jīng)理的原型是沒有很高的要求的,只要對方能夠聽懂看懂就可以了,所以使用手繪原型是最高效率的方法。

2.4、用例模型(產(chǎn)品用例圖)

用例(UseCase)是一種描述產(chǎn)品需求的方法,使用用例的方法來描述產(chǎn)品需求的過程就是用例模型,用例模型是由用例圖和每一個用例的詳細(xì)描述文檔所組成的。在技術(shù)和產(chǎn)品的工作領(lǐng)域里都有用例模型的技能知識。技術(shù)人員的用例主要是為了方便在多名技術(shù)人員協(xié)同工作,或者技術(shù)人員任務(wù)交接時,讓參與者更好的理解代碼的邏輯結(jié)構(gòu)。產(chǎn)品人員的用例主要是為了方便技術(shù)研發(fā)和功能測試時,讓參與者更好的理解功能的邏輯。

用例起源和發(fā)展于軟件時代的產(chǎn)品研發(fā),后來被綜合到UML規(guī)范之中,成為一種標(biāo)準(zhǔn)化的需求表述體系。雖然用例在軟件研發(fā)和技術(shù)工作中應(yīng)用的非常廣泛,但是在互聯(lián)網(wǎng)產(chǎn)品規(guī)劃和設(shè)計中,并不經(jīng)常使用,互聯(lián)網(wǎng)產(chǎn)品的需求表達(dá)為了敏捷效率,通常采用原型加產(chǎn)品需求文檔。

UML是英文Unified ModelingLanguage的縮寫,中文稱為統(tǒng)一建模語言或標(biāo)準(zhǔn)建模語言,是用例模型的建模語言,常用工具是Microsoft OfficeVisio。產(chǎn)品用例是一種通過用戶的使用場景來獲取需求的方式,每個用例提供了一個或多個場景,該場景說明了產(chǎn)品是如何和最終用戶或其它產(chǎn)品互動,也就是誰可以用產(chǎn)品做什么,從而獲得一個明確的業(yè)務(wù)目標(biāo)。

① 用例圖

用例圖并不是畫成了圖形的用例。用例圖包含一組用例,每一個用例用橢圓表示,放置在矩形框中;矩形框表示整個系統(tǒng)。矩形框外畫如圖所示的小人,表示參與者。參與者不一定是人,可以是其它產(chǎn)品、軟件或硬件等等。某一參與者與某一用例用線連起來,表示該參與者和該用例有交互。

許多人通過UML認(rèn)識了用例,UML定義為展現(xiàn)用例的圖形符號。UML并不是為描述用例定義書寫格式的標(biāo)準(zhǔn),因此許多人誤認(rèn)為這些圖形符號就是用例本身;然而,圖形符號只能給出最簡單的一個或一組用例的概要。UML是用例圖形符號最流行的標(biāo)準(zhǔn),但是除了UML標(biāo)準(zhǔn),用例也有其它的可選擇的標(biāo)準(zhǔn)。

② 用例描述文檔

用例圖只是在總體上大致描述了產(chǎn)品所能提供的各種服務(wù),讓我們對于產(chǎn)品的功能有一個總體的認(rèn)識。除此之外,我們還需要描述每一個用例的詳細(xì)信息,這些信息應(yīng)該包含以下內(nèi)容:

用例名稱:本用例的名稱或者編號

行為角色:參與或操作(執(zhí)行)該用例的角色

簡要說明:簡要的描述一下本用例的需求(作用和目的)

前置條件:參與或操作(執(zhí)行)本用例的前提條件,或者所處的狀態(tài)

后置條件:執(zhí)行完畢后的結(jié)果或者狀態(tài)

用例描述文檔基本上是用文本方式來表述的,為了更加清晰地描述用例,也可以選擇使用狀態(tài)圖、流程圖或序列圖來輔助說明。只要有助于表達(dá)的簡潔明了,就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式,或是其它圖形。如流程圖有助于描述復(fù)雜的決策流程,狀態(tài)轉(zhuǎn)移圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為,序列圖適合于描述基于時間順序的消息傳遞。

在互聯(lián)網(wǎng)產(chǎn)品和設(shè)計中,用例的使用越來越少,通常有了產(chǎn)品原型再加上功能流程圖和功能說明文檔就能夠?qū)a(chǎn)品需求詳細(xì)的表述清楚,所以也沒有必須撰寫用例了。但是在大公司里,往往會追求產(chǎn)品流程的規(guī)范性,要求撰寫用例,不過在敏捷開發(fā)的時候也會采用其它更有效率的方式,不一定非要撰寫用例。

前面幾步我們將產(chǎn)品需求逐漸細(xì)化并且通過原型的方式將產(chǎn)品需求形象化的展現(xiàn)了出來,但是在產(chǎn)品功能的邏輯細(xì)節(jié)方面,原型就非常不直觀了,所以用例是一個非常重要的描述需求過程的文檔。

但是由于用例文檔以文字為主,并且格式復(fù)雜,不適用于高效率的產(chǎn)品需求表述,所以展現(xiàn)邏輯流程的“功能流程圖”是一個簡潔直觀的可替代用例文檔的方式。

如上圖所示,功能流程圖是一種使用圖形的方式表示算法邏輯的圖表,因為千言萬語不如一張圖,通過流程圖將“優(yōu)惠券”功能模塊的邏輯和需求非常形象直觀、一目了然的展現(xiàn)了出來。

流程圖的展現(xiàn)方式也不會產(chǎn)生“歧義性”,便于理解,邏輯出錯時也非常容易發(fā)現(xiàn),并且可以直接轉(zhuǎn)化為程序需求描述文檔。

2.6、需求文檔(PRD文檔)

前面的幾個步驟是為了幫助我們梳理需求、驗證可行性和明確細(xì)節(jié),到了這一步的時候我們已經(jīng)非常清晰的了解產(chǎn)品需求,此時撰寫產(chǎn)品需求文檔可以大大減少和避免了撰寫文檔時容易忽略的細(xì)節(jié)黑洞。

產(chǎn)品需求文檔是將產(chǎn)品規(guī)劃和設(shè)計的需求具體形象化表述出來的一種展現(xiàn)形式,主要用于產(chǎn)品界面設(shè)計和研發(fā)使用。因為每個人的習(xí)慣和團(tuán)隊要求都是不一樣的,所以產(chǎn)品需求文檔沒有統(tǒng)一的行業(yè)規(guī)范標(biāo)準(zhǔn),無論以什么樣的格式撰寫產(chǎn)品需求文檔,最終的目的都是讓執(zhí)行人員能夠理解產(chǎn)品需求,根據(jù)需求完成產(chǎn)品。

產(chǎn)品需求文檔的表現(xiàn)形式有很多種,常見的有Word、圖片和交互原型這三種形式,文檔內(nèi)容通常包含信息結(jié)構(gòu)圖、界面線框圖、功能流程圖、功能說明文檔。雖然產(chǎn)品需求文檔沒有標(biāo)準(zhǔn)的規(guī)范,但是有兩項是必不可少的,那就是文件標(biāo)識和修改記錄。文檔在撰寫過程中,我們可以自行不斷的修改完善,但是如果正式發(fā)布或交給團(tuán)隊其他成員后,一旦有了修改,為了文檔的同步,我們就需要標(biāo)注出文檔的修改內(nèi)容,備注修改記錄,這樣可以方便大家查看和了解改動的內(nèi)容。關(guān)于文件標(biāo)識和修改記錄,格式都大同小異。

① Word

這是傳統(tǒng)意義上的產(chǎn)品需求文檔,主要有四個部分組成(具體根據(jù)產(chǎn)品要求進(jìn)行劃分),分別是:結(jié)構(gòu)圖、全局說明、頻道功能、效果圖。

因為產(chǎn)品需求文檔的閱讀者主要是偏向于技術(shù)人員,因此文檔的目的性非常明確,就是要描述產(chǎn)品的功能需求,所有產(chǎn)品需求文檔沒有關(guān)于市場方面的描述。

為了保證需求的執(zhí)行效率,建議大家盡量減少不必要的文字,在能夠讓閱讀者看懂并且了解產(chǎn)品意圖的情況下,文字越少越好。這主要是因為絕大多數(shù)人是沒有足夠耐心認(rèn)真看完產(chǎn)品需求文檔的,因此我們要盡量減化文檔內(nèi)容。

①-1、結(jié)構(gòu)圖:

①-1.1、信息結(jié)構(gòu)圖:主要是輔助服務(wù)端技術(shù)人員創(chuàng)建或調(diào)整數(shù)據(jù)結(jié)構(gòu)的參考文件

①-1.2、產(chǎn)品結(jié)構(gòu)圖:主要是輔助設(shè)計和技術(shù)開發(fā)人員了解產(chǎn)品的全局結(jié)構(gòu)。

①-2、全局說明:

主要講解產(chǎn)品的全局性功能的說明,例如網(wǎng)站產(chǎn)品的頁面編碼、用戶角色,移動產(chǎn)品的緩存機(jī)制、下載機(jī)制,這類全局性功能的說明。這里我舉一個移動產(chǎn)品的“狀態(tài)維持與恢復(fù)”的例子。示例如下:

狀態(tài)的維持與恢復(fù)

當(dāng)用戶退出產(chǎn)品時(誤操作、Home鍵、鎖屏、自動關(guān)機(jī)),產(chǎn)品需要維持用戶操作前的狀態(tài),當(dāng)用戶返回產(chǎn)品時仍可以恢復(fù)到之前狀態(tài),并繼續(xù)使用。

維持狀態(tài)包括流程操作、信息瀏覽、文本輸入、文件下載。

鎖屏狀態(tài)時,如果用戶在產(chǎn)品中有下載任務(wù)時,仍然保持下載。

①-3、頻道功能:

以頻道為單位,頁面為子項,分別描述產(chǎn)品的頻道、頁面及頁面模塊元素的功能需求。示例如下:

1、頻道名:頻道介紹及需求說明

2、頁面1:頁面介紹及需求說明

2.1、頁面模塊1:模塊功能需求說明

2.1.1、頁面模塊1-元素1:功能說明

2.1.2、頁面模塊1-元素2:功能說明

2.2、頁面模塊2:模塊功能需求說明

在撰寫功能需求時,我們需要考慮用戶的流程,例如一個“完成”按鈕,我們需要描述他完成后,系統(tǒng)要不要給出反饋提示(反饋提示是什么樣的形式反饋,內(nèi)容顯示成什么,有沒有內(nèi)容需要調(diào)取數(shù)據(jù)庫),或者要不要跳轉(zhuǎn)頁面(跳轉(zhuǎn)到哪個頁面,這個頁面是其他頻道頁面,還是這個功能的子頁面,如果是子頁面就需要再描述這個子頁面的模塊及元素內(nèi)容)。

①-4、效果圖:

效果圖是由設(shè)計師完成的產(chǎn)品圖,和實際開發(fā)完成的產(chǎn)品保真度一致。

這個示例是一個移動產(chǎn)品(iPad)需求文檔,其中部分隱私內(nèi)容已過濾隱藏,并且只保留了首頁和地圖找房頻道的需求說明。由于工作環(huán)境沒有交互設(shè)計師,所以Word文檔中包含了部分交互說明。

② 圖片

圖片形式的產(chǎn)品需求文檔是基于效果圖的說明文件,將傳統(tǒng)Word形式的功能需求說明標(biāo)注在效果圖上,這種方式經(jīng)常使用在移動互聯(lián)網(wǎng)領(lǐng)域,實際上是圖文形式的交互需求文件,只是在此基礎(chǔ)上更深入的描述出功能需求。

對于圖片形式的產(chǎn)品需求文檔,我們只需要另外再描述一下全局說明,其他頻道頁面的需求直接以圖片形式展示,這種方式相對于Word文檔的純文字更加生動易讀并且直觀,因此有一些產(chǎn)品經(jīng)理非常喜歡用這種方式代替Word形式的產(chǎn)品需求文檔。

③ 交互原型

這里指的交互原型就是前面篇章講到的原型設(shè)計,使用Axure PR之類的交互原型設(shè)計軟件制作出來的產(chǎn)品原型非常真實和直觀,并且原型軟件還支持元素標(biāo)注和導(dǎo)出Word文檔,因此很多產(chǎn)品經(jīng)理都喜歡使用Axure PR來代替Word完成產(chǎn)品需求文檔。

當(dāng)我們通過Axure PR制作出產(chǎn)品原型后,實際上他已經(jīng)是很完善的產(chǎn)品Demo了,因此我們只需要加上元素的標(biāo)注,在標(biāo)注中說明功能需求,這樣導(dǎo)出的HTML文件相比Word文檔更直觀易懂,是非常高效的產(chǎn)品需求說明方式。

無論你采用哪種方式撰寫需求文檔,最終的目的都是為了方便團(tuán)隊成員理解產(chǎn)品的意圖,因此哪種方法能夠避免細(xì)節(jié)黑洞,高效完成產(chǎn)品的設(shè)計和研發(fā),那么這種方法就是最有效的方法。

第四章:產(chǎn)品管理

產(chǎn)品管理是公司為了管理一個產(chǎn)品或者產(chǎn)品線的產(chǎn)品計劃、產(chǎn)品市場和產(chǎn)品生命周期所采用的組織架構(gòu)。產(chǎn)品管理是一個非常典型強(qiáng)矩陣型的管理方式,工作性質(zhì)包括項目管理,但并不完全等同于項目管理,主要負(fù)責(zé)在產(chǎn)品生命周期中對產(chǎn)品規(guī)劃、設(shè)計、開發(fā)、運營等環(huán)節(jié)進(jìn)行管理或支持的工作,負(fù)責(zé)這項工作的人被稱之為產(chǎn)品經(jīng)理。

1、產(chǎn)品管理介紹

從產(chǎn)品的需求開始到產(chǎn)品淘汰報廢的全部生命歷程被稱為產(chǎn)品生命周期。在產(chǎn)品的整個生命周期中,產(chǎn)品經(jīng)理需要打破部門壁壘,整合跨部門資源,實現(xiàn)面向市場的產(chǎn)品規(guī)劃和設(shè)計,確保和企業(yè)戰(zhàn)略的一致性。工作內(nèi)容包括產(chǎn)品戰(zhàn)略、產(chǎn)品市場、產(chǎn)品需求、產(chǎn)品規(guī)劃、產(chǎn)品開發(fā)、產(chǎn)品上線等工作事項的管理。

雖然產(chǎn)品管理涉及的層面比較廣,但是實際中產(chǎn)品經(jīng)理的工作內(nèi)容并非全是如此。業(yè)界普遍的產(chǎn)品管理流程是由公司高層領(lǐng)導(dǎo)確定戰(zhàn)略規(guī)劃和方向,項目負(fù)責(zé)人分解戰(zhàn)略并細(xì)化,同時確定階段目標(biāo),最后由產(chǎn)品經(jīng)理負(fù)責(zé)產(chǎn)品需求的規(guī)劃和設(shè)計,然后溝通和協(xié)調(diào)研發(fā)團(tuán)隊完成產(chǎn)品需求的開發(fā)和上線。

因此產(chǎn)品經(jīng)理除了管理產(chǎn)品規(guī)劃和設(shè)計之外,還需要對產(chǎn)品的執(zhí)行進(jìn)行溝通和協(xié)調(diào),促進(jìn)團(tuán)隊合作,驅(qū)動產(chǎn)品工作的正常進(jìn)行。

2、需求管理

產(chǎn)品因需求而生,在產(chǎn)品的整個生命周期中,產(chǎn)品經(jīng)理會收到來自各個方面的需求,但是每一個需求的必要性、重要性和實現(xiàn)成本都需要經(jīng)過深思熟慮的分析和計劃,避免盲目的決定需求或者變更需求,這樣很容易導(dǎo)致工作混亂,所以產(chǎn)品經(jīng)理首要的管理工作就是對需求進(jìn)行管理。

需求管理的第一步就是要梳理不同來源的需求,需求主要來自公司內(nèi)部(老板或領(lǐng)導(dǎo)、其他部門或同事)、外部(用戶、客戶、合作伙伴)、還有產(chǎn)品經(jīng)理自己(調(diào)研策劃或靈感)。當(dāng)需求匯集到產(chǎn)品經(jīng)理手里之后,我們可以根據(jù)之前在“產(chǎn)品規(guī)劃”章節(jié)中介紹的“需求分類”的方法,將需求進(jìn)行分類管理。分類管理的常用工具有Project、Execl、MindManager等,我常用的是Execl和MindManager軟件。

需求管理的最終工作就是需求分析和決策,關(guān)于分析和決策的方式方法我們在之前的“產(chǎn)品規(guī)劃”章節(jié)中詳細(xì)為大家介紹過了,但是除此之外,需求管理中最重要的就是對發(fā)散性需求的管理,往往因此也會導(dǎo)致產(chǎn)品在執(zhí)行過程中不斷的變更或增加需求。

由于人的思維是發(fā)散性的,所以往往在產(chǎn)品構(gòu)思的過程中會出現(xiàn)各種新鮮好玩的想法,這些想法可能來自領(lǐng)導(dǎo)或者產(chǎn)品經(jīng)理自己,但是這些想法往往都是和產(chǎn)品核心方向不相關(guān)的,但是由于這些想法能夠在當(dāng)時帶來誘惑,因此這些不相關(guān)的需求會嚴(yán)重干擾了團(tuán)隊的精力,打亂或者延誤產(chǎn)品原本的計劃。

很多時候需求的變更或增加是因為我們面臨太多選擇和想要的太多,沒有適當(dāng)?shù)目刂谱约旱挠⒁宰约旱南埠脕頉Q定需求,這些因素很容易導(dǎo)致產(chǎn)品沒有明確的方向、團(tuán)隊成員疲于奔命,但是卻沒有實際的成果。

往往當(dāng)我們擁有一個非常興奮的想法時,此時我們只是無知的樂觀,而實現(xiàn)這個想法則需要各個部門的配合,當(dāng)隨著在這個想法上花費了越來越多的時間并且開始學(xué)習(xí)所有關(guān)于這個想法的相關(guān)事務(wù)時,我們才能意識到一個未經(jīng)深思熟慮的想法所帶來的后果,這些因果最終很有可能將產(chǎn)品帶入危機(jī)中。

所以在需求管理的時候,產(chǎn)品經(jīng)理首先需要控制自己的欲望,基于產(chǎn)品規(guī)劃的三個考慮因素和四個設(shè)計理念,重新審視產(chǎn)品和篩選需求的優(yōu)先級,識別每一個需求的必要性、重要性和實現(xiàn)成本。通過深思熟慮給團(tuán)隊明確方向并專注,聚焦資源的支配,確保團(tuán)隊的精力都聚焦在產(chǎn)品的核心需求上。

3、目標(biāo)管理

目標(biāo)管理是以目標(biāo)為導(dǎo)向,以人為中心,以成果為標(biāo)準(zhǔn),而使組織和個人取得最佳業(yè)績的現(xiàn)代管理方法。目標(biāo)管理亦稱“成果管理”,俗稱責(zé)任制。是指在企業(yè)個體職工的積極參與下,自上而下地確定工作目標(biāo),并在工作中實行“自我控制”,自下而上地保證目標(biāo)實現(xiàn)的一種管理辦法。

3.1、產(chǎn)品目標(biāo)管理

一個團(tuán)隊的執(zhí)行力低,最主要的因素就是因為領(lǐng)導(dǎo)者的執(zhí)行力低下,決策效率低,無法給團(tuán)隊傳達(dá)明確清晰的目標(biāo)。如果領(lǐng)導(dǎo)者沒有目標(biāo)管理的意識,很容易在傳達(dá)需求的時候模棱兩可,導(dǎo)致執(zhí)行者對任務(wù)內(nèi)容和目標(biāo)不夠清晰,以及對所要執(zhí)行的事情的重要性理解不夠,最終結(jié)果可能就是未完成或者延期完成。

目標(biāo)管理并不是有了任務(wù)才有目標(biāo),而是相反,有了目標(biāo)才能確定任務(wù)內(nèi)容和方向,也才能對其進(jìn)行有效分解,轉(zhuǎn)變成各個部門以及各個人的子目標(biāo)或者小目標(biāo)。

產(chǎn)品經(jīng)理作為最終執(zhí)行的領(lǐng)導(dǎo)者,需要將戰(zhàn)略和階段目標(biāo)進(jìn)行更加細(xì)化的規(guī)劃,讓籠統(tǒng)的目標(biāo)可以具體到版本需求,便于設(shè)計師和工程師執(zhí)行,所以在工作中產(chǎn)品經(jīng)理還要有一些項目管理的常識,細(xì)化和制定需求的實施計劃,并且跟進(jìn)實施進(jìn)度。

運用目標(biāo)管理的方法,產(chǎn)品經(jīng)理將戰(zhàn)略與階段目標(biāo)進(jìn)行了細(xì)化,規(guī)劃和設(shè)計出了產(chǎn)品的各個迭代版本的需求。當(dāng)有了這些細(xì)化的子目標(biāo)之后,產(chǎn)品經(jīng)理就可以對其進(jìn)行有效的分解,轉(zhuǎn)變成各個部門或者各個人的任務(wù)和目標(biāo),此時便可以協(xié)調(diào)團(tuán)隊成員完成產(chǎn)品需求的研發(fā)。

3.2、使用目標(biāo)管理

目標(biāo)管理的具體形式各種各樣,但其基本內(nèi)容是一樣的。在業(yè)界被廣泛使用的“SMART原則”是目標(biāo)管理中的一種方法,能夠有效地進(jìn)行成員的組織與目標(biāo)的制定和控制,SMART原則要求制定的目標(biāo)要達(dá)到五個標(biāo)準(zhǔn):明確性、衡量性、可達(dá)成性、相關(guān)性和時限性。

① 明確性

產(chǎn)品需求的任務(wù)和目標(biāo)一定要明確,不能夠模糊。例如:“通知開會”,這就是一個籠統(tǒng)的目標(biāo)。一個有明確性的目標(biāo)應(yīng)該這樣表述,“6月2日下午

15:00在一號會議室召開XX項目設(shè)計方案討論會,設(shè)計部XX項目組所有成員參與,會議時長2小時”。傳達(dá)一個明確的目標(biāo)才能獲取最大的完成幾率。

所謂明確就是要用具體的語言清楚地說明要達(dá)成的行為標(biāo)準(zhǔn)。明確的目標(biāo)幾乎是所有成功團(tuán)隊的一致特點。很多團(tuán)隊不成功的重要原因之一就因為目標(biāo)定的模棱兩可,或沒有將目標(biāo)有效的傳達(dá)給相關(guān)成員。

② 衡量性

目標(biāo)需要可衡量,而可衡量往往需要有數(shù)字,把目標(biāo)量化。如果制定的目標(biāo)沒有辦法衡量,就無法判斷這個目標(biāo)是否實現(xiàn)??珊饬康臉?biāo)準(zhǔn)就是需要確定任務(wù)數(shù)量是多少?做成什么樣才是完成?完成要花多少時間?等等。

③ 可達(dá)成性

一個目標(biāo)必須是可以實現(xiàn)的,或者說經(jīng)過努力是可以實現(xiàn)的。所以任務(wù)目標(biāo)要是執(zhí)行者能力范圍內(nèi)可以達(dá)到的。換言之就是目標(biāo)要現(xiàn)實,例如讓執(zhí)行者去移動公司給聯(lián)通手機(jī)號充值話費,這就是一個不現(xiàn)實的任務(wù),不具備可達(dá)成性。

④ 相關(guān)性

目標(biāo)的相關(guān)性是指實現(xiàn)該目標(biāo)與其他目標(biāo)的關(guān)聯(lián)情況。如果實現(xiàn)了這個目標(biāo),但對其他的目標(biāo)完全不相關(guān),或者相關(guān)度很低,那這個目標(biāo)即使被達(dá)到了,意義也不是很大。因為畢竟工作目標(biāo)的設(shè)定,是要和崗位職責(zé)相關(guān)聯(lián)的,不能跑題。

比如產(chǎn)品需求是研發(fā)一個iOS系統(tǒng)的APP,任務(wù)要求學(xué)習(xí)“iOS人機(jī)界面指導(dǎo)手冊”以便更好的理解系統(tǒng)特性和設(shè)計規(guī)范,這樣有助于提升APP的用

戶體驗。這個任務(wù)就是和目標(biāo)有關(guān)聯(lián)性的,但是如果任務(wù)是學(xué)習(xí)“Android設(shè)計規(guī)范”,那么就跑題了,因為學(xué)習(xí)“Android設(shè)計規(guī)范”這一任務(wù)與研

發(fā)iOS系統(tǒng)的APP這一目標(biāo)相關(guān)度很低。

⑤ 時限性

目標(biāo)特性的時限性就是指目標(biāo)是有時間限制的。必須具有明確的截止期限,即一個目標(biāo)只有在一定的時間內(nèi)達(dá)成才有意義。給目標(biāo)一個確定的完成時間,這會有助于執(zhí)行者集中精力完成目標(biāo)。時限性的要求可以幫助執(zhí)行者避免因為日常瑣事而耽誤了完成目標(biāo)的進(jìn)度。

產(chǎn)品經(jīng)理作為團(tuán)隊合作促進(jìn)者、執(zhí)行力驅(qū)動者、工作效率提升者,必須對目標(biāo)管理有著很深的理解,在傳達(dá)產(chǎn)品需求和任務(wù)的時候,使用“SMART原則”可以大大提升團(tuán)隊的執(zhí)行效率,給執(zhí)行者很明確的任務(wù)目標(biāo)和時限。避免執(zhí)行人不知道該如何執(zhí)行,或者需要執(zhí)行的事情有難度,難到不知道該如何下手。

4、團(tuán)隊溝通

僅僅掌握了需求目標(biāo)的管理還是不夠的,當(dāng)產(chǎn)品經(jīng)理規(guī)劃和設(shè)計好產(chǎn)品需求之后,就要通過溝通來協(xié)調(diào)研發(fā)團(tuán)隊完成產(chǎn)品需求的開發(fā)和上線。溝通是人與人之間、人與群體之間思想與感情的傳遞和反饋的過程,以求思想達(dá)成一致和感情的通暢。但是產(chǎn)品經(jīng)理的溝通不僅僅是一種交流,目的是通過溝通傳達(dá)產(chǎn)品需求和意圖,以及驅(qū)動需求和意圖的執(zhí)行,所以產(chǎn)品經(jīng)理的溝通是一種執(zhí)行溝通,溝通效率決定了工作效率。

產(chǎn)品經(jīng)理作為團(tuán)隊中的樞紐崗位,絕大多數(shù)的時間是用于溝通的,通過溝通促進(jìn)團(tuán)隊合作、驅(qū)動項目執(zhí)行,所以掌握團(tuán)隊溝通的技巧非常有助于我們提升工作效率。

4.1、積極主動溝通

產(chǎn)品經(jīng)理是產(chǎn)品規(guī)劃和設(shè)計的直接責(zé)任人,需要多部門溝通和協(xié)調(diào),擔(dān)當(dāng)團(tuán)隊的執(zhí)行力推動者,所以在工作中要積極主動的溝通。

很多時候,團(tuán)隊成員因為各種因素,或是忙忘了,或是不擅長主動溝通,導(dǎo)致工作反饋不即時,所以產(chǎn)品經(jīng)理在工作中有工作反饋等需求時,不要等別人給,主動要。并且在工作中要積極響應(yīng)需求任務(wù),產(chǎn)品規(guī)劃和設(shè)計要盡量提供完善資料,不要等別人要,主動給。

4.2、換位思考溝通

產(chǎn)品經(jīng)理需要換位思考溝通,明白各個職位的想法和知識,即時調(diào)整自己的溝通方式,要以通俗易懂的詞語和對方溝通。很多時候我們以為對方懂了,其實對方聽的很迷糊,所以在溝通中千萬別主觀的認(rèn)為對方懂了,需要在溝通中互動反饋,確認(rèn)對方是否真的懂了產(chǎn)品需求的意圖。

4.3、直接跟進(jìn)工作

為了避免信息傳遞的失真,產(chǎn)品經(jīng)理應(yīng)當(dāng)直接和相應(yīng)的執(zhí)行人溝通。在任務(wù)分配時,由部門負(fù)責(zé)人安排工作人員,產(chǎn)品經(jīng)理直接和相應(yīng)的工作人員對接,直接跟進(jìn)工作,避免信息傳遞失真,也保證需求和進(jìn)度。

從產(chǎn)品原型開始,團(tuán)隊之間就應(yīng)該保持密切的合作,產(chǎn)品經(jīng)理確定產(chǎn)品的需求,明確產(chǎn)品要做什么,然后調(diào)動大家積累參與到產(chǎn)品的設(shè)計當(dāng)中。從設(shè)計部獲得最佳的用戶體驗與交互設(shè)計方案,從技術(shù)部獲得最新的技術(shù)動態(tài),以便分析能否應(yīng)用到產(chǎn)品當(dāng)中。特別是與技術(shù)部的合作更為密切,產(chǎn)品經(jīng)理需要了解自己規(guī)劃的產(chǎn)品原型從技術(shù)層面能否實現(xiàn)。同時也要跟技術(shù)人員溝通需求,了解是否有其他更優(yōu)的解決方案。

4.4、明確工作任務(wù)

溝通中我們需要使用目標(biāo)管理的方法向?qū)Ψ矫鞔_的傳遞工作任務(wù),其中包括任務(wù)內(nèi)容、任務(wù)目標(biāo)、完成時間、任務(wù)優(yōu)先級。

4.5、減少文字溝通

工作中我們或多或少會用到文字溝通,其中包括產(chǎn)品需求文檔、任務(wù)郵件等等。但是文字的表述是遠(yuǎn)遠(yuǎn)比不上當(dāng)面的溝通更有成果,所以我們要盡量避免使用文字溝通,而在文字溝通時千萬別長篇大論,精簡不必要的話,直入主題。產(chǎn)品需求盡量使用原型表述,有說明文字以標(biāo)注的形式集成在原型中。

4.6、把握時間節(jié)點

在工作中我們是不希望被別人打擾的,同樣產(chǎn)品經(jīng)理在溝通時要注意把握時間點,在不打擾的對方的情況下找其溝通。最好是先發(fā)一封郵件,讓對方先大概了解溝通主題。

4.7、虛心接受反饋

能力的提升是通過不斷的學(xué)習(xí)、總結(jié)和檢省,因此我們需要虛心接受別人反饋的建議。如果反饋不正確或者反饋是一種抱怨與指責(zé),那么我們先發(fā)自內(nèi)心的承認(rèn)錯誤,然后檢省自己并尋找問題所在,千萬別互相抱怨和互相指責(zé),這容易讓問題越來越嚴(yán)重。

4.8、化解壓力與矛盾

產(chǎn)品經(jīng)理是團(tuán)隊的樞紐點,也是壓力、矛盾的集中營,所以我們自己需要有一個良性的化解壓力的方法,在解決自身壓力的同時還要化解團(tuán)隊的矛盾。

解壓的方法每個人都有不同,但是化解矛盾都是大同小異的。團(tuán)隊矛盾往往先是從抱怨與指責(zé)開始的,我們在接受反饋的時候,如果遇到抱怨與指責(zé)的時候需要清楚,這是一個毒瘤,會越長越大,最終會直接影響團(tuán)隊的和諧,所以我們必須要制止它的發(fā)展,避免大家陷入這樣的慣性旋窩中。

抱怨與指責(zé)是雙向的,別人可以迷失,但是我們作為產(chǎn)品經(jīng)理必須要保持理性,結(jié)束抱怨與指責(zé),主動道歉,終止抱怨與指責(zé)不斷的擴(kuò)大。那怕不是我們的錯,但是我們是產(chǎn)品經(jīng)理,終止毒瘤的發(fā)展是我們的職責(zé),等待大家保持冷靜后再溝通。因此產(chǎn)品經(jīng)理需要時刻保持理性,除了虛心接受團(tuán)隊成員的反饋,還要努力化解和減少抱怨與指責(zé),更不能為自己找借口,必須克服所有障礙,解決所有問題。

4.9、感謝和夸獎

產(chǎn)品是團(tuán)隊成員共同努力完成的,產(chǎn)品經(jīng)理作為產(chǎn)品的負(fù)責(zé)人,需要學(xué)會感謝團(tuán)隊成員的付出,并且要勇于說出感謝。感謝和夸獎可以提升產(chǎn)品經(jīng)理在團(tuán)隊成員中的良好印象,減少溝通障礙。

5、團(tuán)隊協(xié)同

一個完整的產(chǎn)品是由團(tuán)隊合作共同完成的,負(fù)責(zé)最終執(zhí)行的工作人員被統(tǒng)稱為研發(fā)團(tuán)隊,研發(fā)團(tuán)隊由產(chǎn)品設(shè)計、技術(shù)開發(fā)兩個方面的崗位組成。產(chǎn)品設(shè)計人員包括產(chǎn)品經(jīng)理、交互設(shè)計師、視覺設(shè)計師,技術(shù)開發(fā)人員包括前端、服務(wù)端、數(shù)據(jù)端、測試等方面的工程師。

在大公司里,產(chǎn)品、技術(shù)、設(shè)計等崗位的工作人員都被劃分在各自的部門里,然后根據(jù)項目再組成虛擬小組,由項目經(jīng)理或者產(chǎn)品經(jīng)理帶頭執(zhí)行產(chǎn)品的研發(fā),所以大公司里的設(shè)計和技術(shù)等工作人員并不完全只負(fù)責(zé)一個產(chǎn)品項目。在小公司或者創(chuàng)業(yè)型團(tuán)隊里,可能公司或團(tuán)隊只有一個產(chǎn)品,所以大家也就共同負(fù)責(zé)這一個產(chǎn)品。

無論工作環(huán)境如何,產(chǎn)品需求的執(zhí)行都會涉及到各個方面的工作溝通和協(xié)調(diào),在產(chǎn)品研發(fā)的過程中,團(tuán)隊協(xié)同的默契度決定了工作的效率。但是在研發(fā)團(tuán)隊中,每個人的想法都是不一樣的,默契也需要很長時間的磨合,如果我們能夠了解到各個崗位工作人員的想法,那么對于減少磨合周期,提升溝通和工作的效率,無疑是一個非常好的途徑。

① 交互設(shè)計師:想的是用戶體驗

在很多公司里是沒有單獨的交互設(shè)計師崗位的,通常都是由產(chǎn)品經(jīng)理直接負(fù)責(zé),所以產(chǎn)品經(jīng)理等于半個交互設(shè)計師。在有交互設(shè)計師崗位的公司里,由于產(chǎn)品經(jīng)理和交互設(shè)計師都會考慮用戶體驗,所以多多少少產(chǎn)品經(jīng)理也會參與到交互設(shè)計的環(huán)節(jié),在產(chǎn)品需求設(shè)計的時候很容易會和交互設(shè)計師的工作重疊,因此在工作中和交互設(shè)計師產(chǎn)生分歧也是常事了。

雖然產(chǎn)品經(jīng)理比交互設(shè)計師更懂用戶需求,并且對產(chǎn)品感覺、把握項目進(jìn)度等等綜合能力要強(qiáng)于交互設(shè)計師。但是交互設(shè)計師比產(chǎn)品經(jīng)理更了解用戶行為習(xí)慣,了解用戶體驗。所以在工作中,產(chǎn)品經(jīng)理需要相信交互設(shè)計師在領(lǐng)域內(nèi)的專業(yè)性,畢竟交互設(shè)計師是專業(yè)人士。

交互設(shè)計是一種在用戶純主觀使用產(chǎn)品過程中建立起來的感受,用戶的行為習(xí)慣除了使用設(shè)備的基礎(chǔ)特性外,往往操作習(xí)慣都是被引導(dǎo)的,至于一個按鈕放在A位置還是B位置,在產(chǎn)品需求的本質(zhì)上區(qū)別并不大,相信交互設(shè)計師的決定是經(jīng)過專業(yè)思考的。所以產(chǎn)品經(jīng)理在交互設(shè)計之前,只要充分和交互設(shè)計師溝通,表明產(chǎn)品需求和意圖,然后只要把控交互設(shè)計沒有破壞掉產(chǎn)品的需求和意圖。

② 視覺設(shè)計師:想的是風(fēng)格美觀

視覺設(shè)計也是一種藝術(shù),但凡是藝術(shù)的東西,都是一種主觀的行為,沒有絕對的對錯之分,也沒有懂與不懂,只有審美與訴求點不一樣而已。所以產(chǎn)品經(jīng)理和視覺設(shè)計師之間是很難用主觀或者抽象的知識去互相說服對方的,畢竟大家的視野角度不一樣。

例如自行車產(chǎn)品,產(chǎn)品經(jīng)理只需要把控好自行車這個產(chǎn)品的本質(zhì)需求和意圖是按照產(chǎn)品規(guī)劃完成的即可,至于自行車的色彩風(fēng)格,相信視覺設(shè)計師在色彩風(fēng)格上面的美術(shù)研究要比產(chǎn)品經(jīng)理更專業(yè)。

產(chǎn)品設(shè)計的本身是為用戶服務(wù)的,所以視覺也是一種溝通與傳達(dá),當(dāng)我們對視覺設(shè)計方案有異議的時候,我們應(yīng)當(dāng)充實自己在視覺領(lǐng)域的知識,盡量使用具體形象化的表述方式描繪視覺想法。如果產(chǎn)生爭議,我們可以多做幾個視覺設(shè)計稿,讓團(tuán)隊其他工作人員或者用戶參與設(shè)計稿的體驗,收集他們的建議和反饋。

③ 技術(shù)工程師:想的是實現(xiàn)模型

技術(shù)人員是產(chǎn)品從規(guī)劃設(shè)計到實現(xiàn)的最后一步的執(zhí)行人員,負(fù)責(zé)產(chǎn)品需求的開發(fā)工作,所以技術(shù)人員在理解需求的時候,考慮的是需求在技術(shù)層面的實現(xiàn)方法,想的是實現(xiàn)模型。

當(dāng)需求到了實現(xiàn)的時候,如果存在考慮不周全的細(xì)節(jié)時,就很容易造成技術(shù)邏輯不通,往往這些因素會導(dǎo)致需求不夠完善,需要重新設(shè)計或者變更,這種情況就會造成技術(shù)人員之前工作量的浪費。

常見的細(xì)節(jié)缺失會出現(xiàn)在功能的邏輯流程方面,比如電子商務(wù)網(wǎng)站在促銷管理中有一個設(shè)置某個商品首次購買可以特價的功能,這個功能背后就有很多關(guān)聯(lián)性的邏輯,例如在促銷之前已經(jīng)購買過,還能不能享受這次的特價購買?也就是首次購買是指所有時間的首次?還是從促銷時間之后算起的首次?并且如何遇到提交訂單后但是訂單被拒絕或者客戶取消,再購買算不算首次購買?這個首次購買的定義是指訂單成功運出,還是說只要提交過這個商品的訂單,無論有沒有成功運出,都不再是首次?

所以在和技術(shù)人員協(xié)同工作時,往往導(dǎo)致工作不順的原因就在于產(chǎn)品需求不夠細(xì)致,功能邏輯不通,這些缺失的因素,那怕是一個小改動,也許就要讓技術(shù)人員耗費好長時間去修改,并且在需求新增、變更以及項目趕進(jìn)度等等情況下,工作量都會落實到技術(shù)人員身上。所以我們在和技術(shù)人員對接工作時,應(yīng)當(dāng)從產(chǎn)品技術(shù)層面的實現(xiàn)模型考慮,為技術(shù)人員提供明確的、完善的產(chǎn)品需求文檔,盡量減少和避免增加技術(shù)人員的多余工作量。

團(tuán)隊協(xié)同的基礎(chǔ)是建立在互相尊重和信任之上的,所以在產(chǎn)品經(jīng)理不了解的領(lǐng)域里,我們應(yīng)當(dāng)充分尊重和信任團(tuán)隊里的專業(yè)人士,避免使用主觀的喜好進(jìn)行溝通和決策。同時產(chǎn)品經(jīng)理也要主動和團(tuán)隊里的各個層面的人員保持溝通,即時跟進(jìn)產(chǎn)品實施的進(jìn)度和反饋,避免產(chǎn)品在執(zhí)行過程中偏離方向。

6、項目管理

項目管理是在限定的資源及限定的時間內(nèi)需完成的一次性任務(wù)。具體可以是一項工程、服務(wù)、研究課題及活動等。這項工作通常由項目經(jīng)理負(fù)責(zé),但是由于項目經(jīng)理主要關(guān)注點都是質(zhì)量、安全、進(jìn)度、成本等方面的,具體到產(chǎn)品的細(xì)節(jié)則都是由產(chǎn)品經(jīng)理負(fù)責(zé)把握。

在很多小型或者創(chuàng)業(yè)型團(tuán)隊中,沒有單獨的項目管理的崗位,所以很多時候這項工作就由產(chǎn)品經(jīng)理擔(dān)當(dāng)了起來。就算有項目經(jīng)理的公司,由于項目經(jīng)理的職責(zé)沒辦法細(xì)致到產(chǎn)品的需求和意圖的細(xì)節(jié)把控上,所以關(guān)于產(chǎn)品的細(xì)節(jié)執(zhí)行還是需要產(chǎn)品經(jīng)理跟進(jìn)。因此我們了解一些項目管理的知識,也是非常有助于產(chǎn)品管理。

項目管理不同于目標(biāo)管理,目標(biāo)管理是可以細(xì)化成非常小的顆粒任務(wù),但是項目管理是一個整體的任務(wù)計劃。比如“裝修房子”,這就是一個任務(wù)計劃,管理這個計劃屬于項目管理。

但是裝修有很多細(xì)化的工作內(nèi)容,有裝修之前的事務(wù),和裝修之后的事務(wù),都是屬于項目計劃的范疇之內(nèi)。在這個大的項目計劃之中,裝修要有選購材料的事項,這個就屬于項目中的一項任務(wù),對應(yīng)這個任務(wù)的安排就是目標(biāo)管理,項目管理者就需要給執(zhí)行者明確選購時間、地點、材料名、用途、數(shù)量以及預(yù)算等等內(nèi)容,讓任務(wù)參與或執(zhí)行者清晰任務(wù)內(nèi)容和達(dá)成的目標(biāo)。

所以目標(biāo)管理是以任務(wù)成果為標(biāo)準(zhǔn)的管理原則,但是項目管理則是一個大整體的計劃管理。在產(chǎn)品管理當(dāng)中,一次產(chǎn)品的迭代便是一次項目計劃,產(chǎn)品迭代的需求會再細(xì)化成具體的各個任務(wù)并分配給相應(yīng)的工作人員執(zhí)行,而這些任務(wù)的安排便是目標(biāo)管理。

項目管理的工作通常使用甘特圖對項目計劃進(jìn)行管理和跟進(jìn),常用軟件有Project、Execl等,我常用的是Execl軟件。通過甘特圖分配任務(wù)和制定計劃,然后再運用目標(biāo)管理的方法,向執(zhí)行部門或執(zhí)行人傳達(dá)任務(wù)內(nèi)容和目標(biāo)。


最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容