編輯導(dǎo)語：近年來，產(chǎn)品經(jīng)理是很多互聯(lián)網(wǎng)人都向往的一大崗位，那么作為一名UI設(shè)計師如果想轉(zhuǎn)行做產(chǎn)品經(jīng)理該如何做？作者總結(jié)自身項目經(jīng)驗，給大家介紹與總結(jié)自己接觸百萬級項目，負(fù)責(zé)產(chǎn)品經(jīng)理工作的方法，希望對正在轉(zhuǎn)型的你有所幫助。

俗話說不想當(dāng)產(chǎn)品經(jīng)理的UI不是好設(shè)計，這次跟大家聊一聊“UI設(shè)計師如何應(yīng)對To B百萬級項目-轉(zhuǎn)型產(chǎn)品經(jīng)理并0-1項目落地”。

第一次寫文章，分享一下自己的經(jīng)歷和總結(jié)經(jīng)驗，供大家參考；內(nèi)容涉及的環(huán)節(jié)比較多，很多地方寫的也比較籠統(tǒng)，如果大家感興趣歡迎一起深入討論。

做UI也有幾年的時間，產(chǎn)品經(jīng)理的種子也一直埋在心里，先跟大家介紹一下我是怎樣接觸到百萬級的項目，負(fù)責(zé)產(chǎn)品經(jīng)理工作的。

由于我們產(chǎn)品經(jīng)理人員的流失，導(dǎo)致剛剛接手的項目無人接手（其他產(chǎn)品經(jīng)理也不想去接這個項目）因素有兩點：一是要與新的團隊去合作（成員比較難搞）、二是政企項目的復(fù)雜度（項目與合作對象），下面會給大家簡單介紹一下。

領(lǐng)導(dǎo)經(jīng)過多方談話后，無人接手的項目就轉(zhuǎn)到我這里來了，人們總是對于未知的事物產(chǎn)生恐懼。而我此時也是悲喜交加，喜的是終于有機會去做產(chǎn)品經(jīng)理的工作了；悲的是萬一項目搞砸了怎么辦？

其實一開始我是拒絕的，與其說拒絕不如說是害怕，怕什么？怕把項目搞砸、被開發(fā)甲方懟、Bug亂飛、產(chǎn)品不能如期交付…你不接手可以說是不在職責(zé)范圍內(nèi)，一旦你接手后再出現(xiàn)問題那就是你的工作失誤，影響極大。

既然上了賊船那就好好當(dāng)個海盜吧，萬一成功了呢？懷著恐懼的心理，接手了項目及近20人的團隊，并開始了與甲方第一次溝通（產(chǎn)品經(jīng)理生涯正式開始）。

相信大家對產(chǎn)品的流程也倒背如流了吧，產(chǎn)品前期要進行需求溝通、需求分析、需求挖掘、產(chǎn)品原型設(shè)計、需求評審、開發(fā)、測試、驗收等一系列的環(huán)節(jié)。接下來分別從上述環(huán)節(jié)一一詳述并舉例說明。

一、需求溝通

1. 了解產(chǎn)品背景、業(yè)務(wù)流程

知己知彼，百戰(zhàn)不殆。這一環(huán)節(jié)主要是要與甲方溝通項目的背景、目標(biāo)、方向，了解業(yè)務(wù)和流程，說通俗點就是為什么要做這個產(chǎn)品，要解決什么問題，怎么解決？業(yè)務(wù)流程是怎樣的？這里至關(guān)重要，一定要搞清楚業(yè)務(wù)流程、甲方要做的事情，切合現(xiàn)實場景幫助甲方去把需求說清楚、更具象化，并落實到文檔中，抄送所有相關(guān)人員知曉。

這里要注意一點：你所對接的干系人是否具有話語權(quán)或者決策權(quán)，是否代表領(lǐng)導(dǎo)或者用戶（往往對接人和使用產(chǎn)品的不是一撥人）如果以上都不是就要注意了，這時候如果不制定策略那產(chǎn)品開發(fā)完成后，你大概率就會聽到：

• “這不是我想要的”
• “為什么要這么做？”
• “這樣不合理需要改一下”
• ……

不僅會導(dǎo)致需求延期還會影響整個團隊的情緒。

二、需求分析

1. 分析需求，將原始需求轉(zhuǎn)換為產(chǎn)品功能點

為什么要將原始需求轉(zhuǎn)換成產(chǎn)品需求？一是要梳理產(chǎn)品邏輯和層級、二是要將語言翻譯成開發(fā)團隊可以看的懂的內(nèi)容，這樣才可以進行后續(xù)的工作量評估、迭代計劃的制定等。

通過我們上一輪兒溝通后，已經(jīng)對產(chǎn)品的背景、方向、目標(biāo)、業(yè)務(wù)都已深入了解。這時心中大概也有了一個產(chǎn)品雛形，對接下來要做的事情也逐漸清晰。

第一步：我們將甲方提供的原始需求文檔，分析需求后轉(zhuǎn)換成產(chǎn)品功能點。這里通過第一輪的溝通和深入了解業(yè)務(wù)，對于用戶要做的事情已經(jīng)清楚，所以轉(zhuǎn)換成功能點難度不是很大。舉個例子，如下：

• 甲方原始需求：“我們要通過手持終端現(xiàn)場把管井、隧道井、桿、塔……一些要素資源采集到手機上，并且可以錄入地理位置、相關(guān)信息以此來提高作業(yè)效率，幫助我們對資源的管理”
• 產(chǎn)品需求：“移動端增加井、桿、塔等要素功能圖標(biāo)，支持點擊后地圖打點，打點成功后右側(cè)彈出信息卡片，用戶可編輯錄入；打點成功后，要素支持增刪改功能?！?/li>

我們在對原始需求分析的時候，要先從產(chǎn)品的一級開始，也就是業(yè)務(wù)的第一步開始。這樣的好處是邏輯、層級不會混亂，是按照業(yè)務(wù)邏輯一步一步的深入產(chǎn)品功能；如果我們上來就對照原始需求一條條拆分，接下來你很可能就迷失在產(chǎn)品中，非?；靵y。

原始需求分析完成后，基本上產(chǎn)品的邏輯、方向、功能都清晰了，這時不要急于開始產(chǎn)品設(shè)計、開發(fā)，切記！哪怕你已經(jīng)和甲方看過了需求內(nèi)容，甲方也覺得沒有問題，也請不要暗自竊喜，急于進行下一流程。

有一點需要注意：在和甲方過產(chǎn)品功能文檔之前，最好先給內(nèi)部開發(fā)團隊的同學(xué)講一遍，讓團隊知曉我們即將要做的事情，心理上有個準(zhǔn)備（或者是哪些方案的成本較大，在給甲方看時，內(nèi)部先消化掉，避免一些不必要的麻煩）。

三、需求挖掘

1. 繼續(xù)明確需求、發(fā)現(xiàn)隱藏需求（真?zhèn)涡枨螅?/h3>

相信大家都知道那匹馬的故事，這里在贅述一下：

100多年前，福特公司的創(chuàng)始人亨利·福特先生到處跑去問客戶：“您需要一個什么樣的更好的交通工具？”

幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。但是福特先生卻沒有立馬往馬場跑，而是接著往下問。

福特：“你為什么需要一匹更快的馬？”

客戶：“因為可以跑得更快！”

福特：“你為什么需要跑得更快？”

客戶：“因為這樣我就可以更早的到達(dá)目的地?！?/p>

福特：“所以，你要一匹更快的馬的真正用意是？”

客戶：“用更短的時間、更快地到達(dá)目的地！”

我們需要對產(chǎn)品需求文檔結(jié)合多方用戶、業(yè)務(wù)、多角度進行深度挖掘，以此來發(fā)現(xiàn)還有哪些我們未知的、隱藏的需求。包括現(xiàn)在的功能點是否真的是用戶想要的？這些功能的實現(xiàn)能給用戶帶來什么價值？還有沒有更好的方案？

（不要覺得他們對業(yè)務(wù)了如指掌，流程極其完美，其實他們只是沒有發(fā)現(xiàn)問題而已，或者已經(jīng)發(fā)現(xiàn)問題，沒有更好的解決方案，一旦有了更好方案即將面臨需求變更。）

我們在前期就需要把這些可能會發(fā)生的事情，盡量扼殺在搖籃里，將風(fēng)險降低到最小值。舉個例子，如下：

甲方：“一條光纜會通過多個井、桿、塔等等一些物體，我需要批量添加光纜，以關(guān)聯(lián)放置在不同要素中，避免我們機械化的操作，提高工作效率”

產(chǎn)品：“為什么要做批量添加的功能？同一條光纜穿過不同的要素，光纜信息都是一樣的，而不同的光纜信息是不一樣的；現(xiàn)實場景中也不存在突然要添加一批光纜的情況，即使小概率出現(xiàn)，為滿足這一場景，很容易造成數(shù)據(jù)出錯，程序沒辦法控制?！?/p>

甲方：“我想先創(chuàng)建一批光纜，再去建立關(guān)聯(lián)，這樣就省去了一條條的創(chuàng)建時間，而且我們作業(yè)員都是專業(yè)的。”

產(chǎn)品：“我們在要素關(guān)聯(lián)表中，支持搜索功能，只要未被當(dāng)前要素所關(guān)聯(lián)的光纜都可以搜索出來并建立關(guān)聯(lián)；創(chuàng)建光纜時，自動賦值共有字段既可以規(guī)避臟數(shù)據(jù)，又可以保證數(shù)據(jù)的正確性，同時也提高了效率，這個方案可以嗎？”

甲方：“可以?！?/p>

Ps：需求剛開始看起來似乎是合理的，那如果不進行分析、挖掘就將功能接下，那極有可能會要求在加一條“批量刪除光纜”的功能，既然都支持批量添加了，那批量刪除也一定會提出來。一旦用戶在實際使用時，發(fā)現(xiàn)不好用或者有更好的方案，那等待的只有需求變更，而且甲方還能夠說出為什么要變更，導(dǎo)致你啞口無言。

實際上一種場景，會有多種解決方案，這個時候就需要盡可能的把所有方案都羅列出來，從用戶、項目、商業(yè)的角度去選擇合適的方案，這樣在跟甲方闡述時也會更容易被接受。

在明確需求后，接下來就需要組織開發(fā)團隊進行需求講解，讓大家知曉我們要做的事情（在前期也需要將一些專業(yè)術(shù)語、相關(guān)業(yè)務(wù)資料給到大家）要注意一定要將情況實時同步給開發(fā)同學(xué)，這樣你就會發(fā)現(xiàn)合作順暢很多。

接下來就是開發(fā)團隊工作量的評估，排需求優(yōu)先級，制定迭代計劃。（如一個月拆分4周，每周的開發(fā)內(nèi)容，每周四發(fā)版驗收）等等。

三、產(chǎn)品原型設(shè)計

1. 原型文檔

在經(jīng)過我們需求分析、需求挖掘環(huán)節(jié)后，一定要將結(jié)果，以書面形式抄送各相關(guān)干系人，讓大家知曉，切記（一定要抄送到位，不容小覷）！

接下來就開始我們的原型設(shè)計環(huán)節(jié)了，除了從商業(yè)、用戶、甲方、項目的維度去考慮產(chǎn)品框架，還要注意項目周期、開發(fā)成本、資源的問題。這些因素都將直接影響你的產(chǎn)品形態(tài)。而原型設(shè)計也要注意后續(xù)的可擴展性，具備快速響應(yīng)需求變更的框架。

這一環(huán)節(jié)不要急著動手畫原型，而是要先思考；準(zhǔn)備好紙、筆，將你的想法快速的留在紙張上，盡可能多的去思考方案，逐一去分析每個方案的利弊，最終得到結(jié)果，再去畫原型進行細(xì)節(jié)補充優(yōu)化。切記！不要只考慮當(dāng)前功能的展現(xiàn)，要結(jié)合整個產(chǎn)品流程，進行原型設(shè)計。

根據(jù)迭代計劃，我們將需求原型設(shè)計完成后，先內(nèi)部過方案，內(nèi)部達(dá)成一致后再去跟甲方過方案，切記！在跟甲方過完方案無誤后，一定要將結(jié)果抄送相關(guān)干系人，再進行開發(fā)階段，切記??！不要急于開發(fā)。

由于團隊的技術(shù)負(fù)責(zé)人前期一直強調(diào)，要注意開發(fā)成本，盡量降低開發(fā)同學(xué)難度的同時要滿足業(yè)務(wù)訴求……所以導(dǎo)致我接下來滿腦子都是怎樣的設(shè)計方案開發(fā)成本最低，復(fù)用率更高。

當(dāng)你被一些外來因素干擾你決策時，不要急著去排斥，要去分析這些建設(shè)性的意見是否是合理的，如果是合理的我們就采納，去想辦法解決掉。如果一開始就帶有極強的排斥心里，那將會影響你后續(xù)的工作進展，心態(tài)一定要放平。

2. 交互文檔

交互文檔具體寫哪些內(nèi)容？要怎么寫？以什么形式展現(xiàn)？

• 交互文檔的展示形式有很多，這里我習(xí)慣將交互說明文檔，放置在原型右側(cè)。這樣可以對照著原型去看具體的交互邏輯。
• 交互文檔內(nèi)容包括：功能操作描述、跳轉(zhuǎn)邏輯、邏輯判斷等。其目的就是要讓開發(fā)同學(xué)明白功能是做什么的，怎么操作，有哪些狀態(tài)、校驗、判斷等等。
• 根據(jù)原型內(nèi)容，按照順序逐一將功能進行展開描述；可分為功能描述、業(yè)務(wù)原則描述兩類。

注意原型文檔一定要有變更記錄，不同時間節(jié)點備份迭代內(nèi)容，切記在一個文檔中從開始改到結(jié)束。如下圖：

四、需求評審

由于我們在與甲方過方案之前，已經(jīng)與內(nèi)部溝通過了，所以接下來的評審相對會比較順利。召集相關(guān)開發(fā)人員，進行需求評審就可以了。前面說到要將進展、方案同步給開發(fā)，并不是以開發(fā)成本為中心設(shè)計需求，而是要讓開發(fā)同學(xué)有參與感、責(zé)任感；更重要的是整個團隊都要熟悉了解業(yè)務(wù)，前期做好充足準(zhǔn)備，避免大家出現(xiàn)為了做需求而做需求的現(xiàn)象。

會議開始之前不必過于擔(dān)心會出現(xiàn)反對聲音，因為你的方案是在眾多方案中推演決策而來的，所以這個時候你也有充足的依據(jù)去進行討論，當(dāng)然如果有更好的方案也要虛心采納。

需求評審結(jié)束后，將最終的結(jié)果整理好，告知各個相關(guān)人員，接下來就是開發(fā)階段了。切記！如果出現(xiàn)需求變更，或者原型內(nèi)容的改動，一定要第一時間告訴團隊內(nèi)所有成員。

五、開發(fā)/測試/驗收

當(dāng)大的功能開發(fā)、測試完成后，可以將產(chǎn)品成果給甲方進行驗收。主要形式為拉會議，召集甲方干系人，將產(chǎn)品進行演示、確認(rèn)。這里目的就是再一次確認(rèn)，因為開發(fā)之前已經(jīng)給甲方做了心里建設(shè)，這里在通過平臺化繼續(xù)確認(rèn)。

六、交付/驗收

項目交付后，如果出現(xiàn)需求變更，這里基本上都是大領(lǐng)導(dǎo)級別的了，一般都是當(dāng)面會談，將變更內(nèi)容落在紙面上，各方領(lǐng)導(dǎo)進行簽字確認(rèn)后，再回到產(chǎn)品研發(fā)部。

機會是留給有所準(zhǔn)備的人，希望大家能永遠(yuǎn)保持積極的心態(tài)，一路披荊斬棘，升職加薪。

本文由 @三范范 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議