起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識UI設計師如何應對To B百萬級項目——轉型產品經理實錄
編輯導語：近年來，產品經理是很多互聯網人都向往的一大崗位，那么作為一名UI設計師如果想轉行做產品經理該如何做？作者總結自身項目經驗，給大家介紹與總結自己接觸百萬級項目，負責產品經理工作的方法，希望對正在轉型的你有所幫助。
俗話說不想當產品經理的UI不是好設計，這次跟大家聊一聊“UI設計師如何應對To B百萬級項目-轉型產品經理并0-1項目落地”。
第一次寫文章，分享一下自己的經歷和總結經驗，供大家參考；內容涉及的環節比較多，很多地方寫的也比較籠統，如果大家感興趣歡迎一起深入討論。
做UI也有幾年的時間，產品經理的種子也一直埋在心里，先跟大家介紹一下我是怎樣接觸到百萬級的項目，負責產品經理工作的。
由于我們產品經理人員的流失，導致剛剛接手的項目無人接手（其他產品經理也不想去接這個項目）因素有兩點：一是要與新的團隊去合作（成員比較難搞）、二是政企項目的復雜度（項目與合作對象），下面會給大家簡單介紹一下。
領導經過多方談話后，無人接手的項目就轉到我這里來了，人們總是對于未知的事物產生恐懼。而我此時也是悲喜交加，喜的是終于有機會去做產品經理的工作了；悲的是萬一項目搞砸了怎么辦？
其實一開始我是拒絕的，與其說拒絕不如說是害怕，怕什么？怕把項目搞砸、被開發甲方懟、Bug亂飛、產品不能如期交付…你不接手可以說是不在職責范圍內，一旦你接手后再出現問題那就是你的工作失誤，影響極大。
既然上了賊船那就好好當個海盜吧，萬一成功了呢？懷著恐懼的心理，接手了項目及近20人的團隊，并開始了與甲方第一次溝通（產品經理生涯正式開始）。
相信大家對產品的流程也倒背如流了吧，產品前期要進行需求溝通、需求分析、需求挖掘、產品原型設計、需求評審、開發、測試、驗收等一系列的環節。接下來分別從上述環節一一詳述并舉例說明。
一、需求溝通
1. 了解產品背景、業務流程
知己知彼，百戰不殆。這一環節主要是要與甲方溝通項目的背景、目標、方向，了解業務和流程，說通俗點就是為什么要做這個產品，要解決什么問題，怎么解決？業務流程是怎樣的？這里至關重要，一定要搞清楚業務流程、甲方要做的事情，切合現實場景幫助甲方去把需求說清楚、更具象化，并落實到文檔中，抄送所有相關人員知曉。
這里要注意一點：你所對接的干系人是否具有話語權或者決策權，是否代表領導或者用戶（往往對接人和使用產品的不是一撥人）如果以上都不是就要注意了，這時候如果不制定策略那產品開發完成后，你大概率就會聽到：
- “這不是我想要的”
- “為什么要這么做？”
- “這樣不合理需要改一下”
- ……
不僅會導致需求延期還會影響整個團隊的情緒。
二、需求分析
1. 分析需求，將原始需求轉換為產品功能點
為什么要將原始需求轉換成產品需求？一是要梳理產品邏輯和層級、二是要將語言翻譯成開發團隊可以看的懂的內容，這樣才可以進行后續的工作量評估、迭代計劃的制定等。
通過我們上一輪兒溝通后，已經對產品的背景、方向、目標、業務都已深入了解。這時心中大概也有了一個產品雛形，對接下來要做的事情也逐漸清晰。
第一步：我們將甲方提供的原始需求文檔，分析需求后轉換成產品功能點。這里通過第一輪的溝通和深入了解業務，對于用戶要做的事情已經清楚，所以轉換成功能點難度不是很大。舉個例子，如下：
- 甲方原始需求：“我們要通過手持終端現場把管井、隧道井、桿、塔……一些要素資源采集到手機上，并且可以錄入地理位置、相關信息以此來提高作業效率，幫助我們對資源的管理”
- 產品需求：“移動端增加井、桿、塔等要素功能圖標，支持點擊后地圖打點，打點成功后右側彈出信息卡片，用戶可編輯錄入；打點成功后，要素支持增刪改功能?！?/li>
我們在對原始需求分析的時候，要先從產品的一級開始，也就是業務的第一步開始。這樣的好處是邏輯、層級不會混亂，是按照業務邏輯一步一步的深入產品功能；如果我們上來就對照原始需求一條條拆分，接下來你很可能就迷失在產品中，非常混亂。
原始需求分析完成后，基本上產品的邏輯、方向、功能都清晰了，這時不要急于開始產品設計、開發，切記！哪怕你已經和甲方看過了需求內容，甲方也覺得沒有問題，也請不要暗自竊喜，急于進行下一流程。
有一點需要注意：在和甲方過產品功能文檔之前，最好先給內部開發團隊的同學講一遍，讓團隊知曉我們即將要做的事情，心理上有個準備（或者是哪些方案的成本較大，在給甲方看時，內部先消化掉，避免一些不必要的麻煩）。
三、需求挖掘
1. 繼續明確需求、發現隱藏需求（真偽需求）
相信大家都知道那匹馬的故事，這里在贅述一下：
100多年前，福特公司的創始人亨利·福特先生到處跑去問客戶：“您需要一個什么樣的更好的交通工具？”
幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。但是福特先生卻沒有立馬往馬場跑，而是接著往下問。
福特：“你為什么需要一匹更快的馬？”
客戶：“因為可以跑得更快！”
福特：“你為什么需要跑得更快？”
客戶：“因為這樣我就可以更早的到達目的地。”
福特：“所以，你要一匹更快的馬的真正用意是？”
客戶：“用更短的時間、更快地到達目的地！”
我們需要對產品需求文檔結合多方用戶、業務、多角度進行深度挖掘，以此來發現還有哪些我們未知的、隱藏的需求。包括現在的功能點是否真的是用戶想要的？這些功能的實現能給用戶帶來什么價值？還有沒有更好的方案？
（不要覺得他們對業務了如指掌，流程極其完美，其實他們只是沒有發現問題而已，或者已經發現問題，沒有更好的解決方案，一旦有了更好方案即將面臨需求變更。）
我們在前期就需要把這些可能會發生的事情，盡量扼殺在搖籃里，將風險降低到最小值。舉個例子，如下：
甲方：“一條光纜會通過多個井、桿、塔等等一些物體，我需要批量添加光纜，以關聯放置在不同要素中，避免我們機械化的操作，提高工作效率”
產品：“為什么要做批量添加的功能？同一條光纜穿過不同的要素，光纜信息都是一樣的，而不同的光纜信息是不一樣的；現實場景中也不存在突然要添加一批光纜的情況，即使小概率出現，為滿足這一場景，很容易造成數據出錯，程序沒辦法控制。”
甲方：“我想先創建一批光纜，再去建立關聯，這樣就省去了一條條的創建時間，而且我們作業員都是專業的。”
產品：“我們在要素關聯表中，支持搜索功能，只要未被當前要素所關聯的光纜都可以搜索出來并建立關聯；創建光纜時，自動賦值共有字段既可以規避臟數據，又可以保證數據的正確性，同時也提高了效率，這個方案可以嗎？”
甲方：“可以?！?/p>
Ps：需求剛開始看起來似乎是合理的，那如果不進行分析、挖掘就將功能接下，那極有可能會要求在加一條“批量刪除光纜”的功能，既然都支持批量添加了，那批量刪除也一定會提出來。一旦用戶在實際使用時，發現不好用或者有更好的方案，那等待的只有需求變更，而且甲方還能夠說出為什么要變更，導致你啞口無言。
實際上一種場景，會有多種解決方案，這個時候就需要盡可能的把所有方案都羅列出來，從用戶、項目、商業的角度去選擇合適的方案，這樣在跟甲方闡述時也會更容易被接受。
在明確需求后，接下來就需要組織開發團隊進行需求講解，讓大家知曉我們要做的事情（在前期也需要將一些專業術語、相關業務資料給到大家）要注意一定要將情況實時同步給開發同學，這樣你就會發現合作順暢很多。
接下來就是開發團隊工作量的評估，排需求優先級，制定迭代計劃。（如一個月拆分4周，每周的開發內容，每周四發版驗收）等等。
三、產品原型設計
1. 原型文檔
在經過我們需求分析、需求挖掘環節后，一定要將結果，以書面形式抄送各相關干系人，讓大家知曉，切記（一定要抄送到位，不容小覷）！
接下來就開始我們的原型設計環節了，除了從商業、用戶、甲方、項目的維度去考慮產品框架，還要注意項目周期、開發成本、資源的問題。這些因素都將直接影響你的產品形態。而原型設計也要注意后續的可擴展性，具備快速響應需求變更的框架。
這一環節不要急著動手畫原型，而是要先思考；準備好紙、筆，將你的想法快速的留在紙張上，盡可能多的去思考方案，逐一去分析每個方案的利弊，最終得到結果，再去畫原型進行細節補充優化。切記！不要只考慮當前功能的展現，要結合整個產品流程，進行原型設計。
根據迭代計劃，我們將需求原型設計完成后，先內部過方案，內部達成一致后再去跟甲方過方案，切記！在跟甲方過完方案無誤后，一定要將結果抄送相關干系人，再進行開發階段，切記！！不要急于開發。
由于團隊的技術負責人前期一直強調，要注意開發成本，盡量降低開發同學難度的同時要滿足業務訴求……所以導致我接下來滿腦子都是怎樣的設計方案開發成本最低，復用率更高。
當你被一些外來因素干擾你決策時，不要急著去排斥，要去分析這些建設性的意見是否是合理的，如果是合理的我們就采納，去想辦法解決掉。如果一開始就帶有極強的排斥心里，那將會影響你后續的工作進展，心態一定要放平。
2. 交互文檔
交互文檔具體寫哪些內容？要怎么寫？以什么形式展現？
- 交互文檔的展示形式有很多，這里我習慣將交互說明文檔，放置在原型右側。這樣可以對照著原型去看具體的交互邏輯。
- 交互文檔內容包括：功能操作描述、跳轉邏輯、邏輯判斷等。其目的就是要讓開發同學明白功能是做什么的，怎么操作，有哪些狀態、校驗、判斷等等。
- 根據原型內容，按照順序逐一將功能進行展開描述；可分為功能描述、業務原則描述兩類。
注意原型文檔一定要有變更記錄，不同時間節點備份迭代內容，切記在一個文檔中從開始改到結束。如下圖：
四、需求評審
由于我們在與甲方過方案之前，已經與內部溝通過了，所以接下來的評審相對會比較順利。召集相關開發人員，進行需求評審就可以了。前面說到要將進展、方案同步給開發，并不是以開發成本為中心設計需求，而是要讓開發同學有參與感、責任感；更重要的是整個團隊都要熟悉了解業務，前期做好充足準備，避免大家出現為了做需求而做需求的現象。
會議開始之前不必過于擔心會出現反對聲音，因為你的方案是在眾多方案中推演決策而來的，所以這個時候你也有充足的依據去進行討論，當然如果有更好的方案也要虛心采納。
需求評審結束后，將最終的結果整理好，告知各個相關人員，接下來就是開發階段了。切記！如果出現需求變更，或者原型內容的改動，一定要第一時間告訴團隊內所有成員。
五、開發/測試/驗收
當大的功能開發、測試完成后，可以將產品成果給甲方進行驗收。主要形式為拉會議，召集甲方干系人，將產品進行演示、確認。這里目的就是再一次確認，因為開發之前已經給甲方做了心里建設，這里在通過平臺化繼續確認。
六、交付/驗收
項目交付后，如果出現需求變更，這里基本上都是大領導級別的了，一般都是當面會談，將變更內容落在紙面上，各方領導進行簽字確認后，再回到產品研發部。
機會是留給有所準備的人，希望大家能永遠保持積極的心態，一路披荊斬棘，升職加薪。
本文由 @三范范 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
我司也是做政企項目的，但工作流程有差別。我們是先出一版原型，再去和局里調研?？罩秩?，局里是說不出什么東西的。
請問項目流程的配圖與文章中的產品流程為什么不一樣？圖片是隨便配的么？
你好，產品流程是在整個項目流程前環節中，拆分后進行細化的；而項目流程在實際工作中也會有所出入，比如很多公司沒有“交互設計師”，這一環節的工作內容也被融合到了產品工作中。
為什么要將原始需求轉換成產品需求？一是要梳理產品邏輯和層級、二是要將語言翻譯成開發團隊可以看的懂的內容，這樣才可以進行后續的工作量評估、迭代計劃的制定等。
走心的文章，細節的配圖，生活中一定是有品質的人。要繼續寫下去哦（頭像都很好看 ）！