項目比選流程 _生活百科

編輯導語：畫一個好的產品原型，是每個產品經理的必修課。但是從零開始的項目比其他已經進入正常迭代節奏的項目難度更大。本文主要介紹如何根據個人實際工作經驗繪制一個新項目的產品原型。感興趣的朋友，一起來看看吧。
每個產品經理在成長的道路上總會遇到一些全新的挑戰，比如全新的功能，全新的項目，甚至全新的業務，全新的市場。
每一個新的挑戰都是對自己的磨練。
其中，從零開始經歷一個項目，手工打造一個全新的產品，是產品經理成長最快的方式，也是檢驗自己能力的絕佳方式。
但是，負責一個全新的項目，不同于負責功能迭代和新的功能模塊，其復雜程度已經大大提高，往往讓人無從下手。
關于新項目的市場分析、用戶分析、需求分析等等，已經有很多文章和介紹了，這里就持個人拙見。
本文主要從如何設計新項目原型的角度介紹一些個人的工作經驗，希望對大家有所幫助和啟發。
一、新項目的難點一個新項目的原型是令人頭痛的，主要有以下原因：
與功能特性迭代不同，新項目需要全局視角，但項目中的每個人(包括產品經理本人)對產品的最終形態都缺乏清晰直觀的認識。新項目往往包含多個模塊，原型設計容易專注于每個模塊和頁面本身，最終使得原型只是頁面的堆積，而缺乏功能模塊之間的聯動；不同的功能模塊有優先級，頁面上不同的功能也有優先級，所以產品原型很難在體現不同模塊和功能優先級的同時展現整體的功能特征；在項目的整個過程中，隨著討論的深入和項目的推進，原型會經歷反復的修改，內部信息很難對齊。因為有這么多的困難，所以做好這件事是有意義的。
去年，我開始負責部門一個舊系統的改造。因為新系統增加了很多功能特性，刪除了舊系統很多多余的功能，整體流程和交互也有了很大的調整，所以某種程度上可以算是一個全新的項目。
因為是后臺項目，所以這個項目沒有交互設計師和視覺設計師，產品經理提供的原型也直接用于項目研發。
為了支持這一項目，該部還投入了一些新的研究和開發資金。d人力。這些新生對業務知識和舊系統的功能知之甚少。所以，如何通過需求原型統一大家的認識，實現項目的持續推進，就成了除了梳理系統需求之外的重中之重。
我也會以這個項目的一些實際工作經驗為例，介紹如何設計一個新項目的原型，以及原型的更新迭代。
00-1010很多產品經理把產品原型等同于頁面交互。
事實上，產品原型本質上是一種交流工具，它使產品經理能夠更方便地交流產品的功能特性，也使R& ampd和測試更快地了解產品的工藝和功能，從而更準確地評估方案。
因此，許多溝通技巧也適用于產品原型。
沒有人喜歡在不了解背景的情況下，一下子進入交流的話題。
產品原型也是如此，所以我們也需要在產品原型中為相關的業務背景和業務流程做鋪墊，讓團隊成員先沒有一個整體的了解，而不是突然進入具體的頁面設計。
下圖00-1010是騰訊云備案審核系統的關鍵業務流程，整個審核系統的訂單處理都是基于這個核心流程。
00-1010除了描述核心業務流程，我們還需要介紹整個系統包含哪些模塊，每個模塊包含多少頁面，頁面之間的關系如何。
如果某個功能模塊相對復雜，涉及多個頁面，那么清晰的頁面流程圖可以更好地幫助R& amp理解。
225" inline="0" alt="新項目，如何畫好產品原型？" onerror="javascript:errorimg.call(this);">3. 頁面狀態及交互說明
上面的部分，是不同頁面之間的流轉關系。
有些時候，同一個頁面，在不同的狀態或環節，其主要功能操作往往也有所區別，因此在特定的頁面，最好也能加上頁面狀態及主要功能操作的說明。
4. 競品資料
競品調研也是產品分析環節非常重要的一環，在產品原型的設計中，友商的設計經常能開闊我們的視野，為我們帶來一些啟發。
我在進行功能體驗的時候，對友商產品流程進行的整理，看看友商在哪些地方學習了我們，也看看友商有哪些地方值得我們學習。（在這里也給產品新人提一個建議，對于自己負責的項目，也可以根據類似的辦法，整理相關的資料）
三、每個頁面/模塊增加功能點列表在進行具體頁面的設計時，往往很難在一個頁面中講述清楚所有的功能，尤其是涉及到狀態變更，以及某些隱藏功能的時候。
此外，頁面中不同功能的優先級是不一樣的，追求頁面功能完整性的話，就會顯得頁面非常臃腫，難以區分輕重緩急。
這個時候，我們可以在子頁面中具體介紹每一個子功能點，大到一個重要的交互，小到一個具體字段的定義，都可以單獨進行說明。
同時，在頁面中增加一個功能點列表，并對每一個功能進行編號，以及定義好相關的優先級。
這個項目，因為開發工作量較大，我們分為了好幾期進行開發，PM和研發也主要根據這里定義的優先級進行排期。
四、不制作過于復雜的交互效果沒有人不喜歡高保真原型，但高保真原型是有代價的。
在我看來，具有復雜交互效果的高保真原型，主要是面向老板（投資人）、產品核心用戶的，并不適合敏捷開發流程。
在實際的研發流程中，高保真原型是存在一些缺點的：
（1）不直觀
某一些彈窗必須通過特定的條件或特定的按鈕才能觸發，如果研發比較粗心，沒有注意到原型中的這個點擊動作，那就漏過了這個產品經理精心設計的功能了。
（2）容易讓人聚焦于細節
產品實現需遵循粗放到精致的過程，如果原型中使用了過于復雜的需求，容易讓人聚焦于細節，而忽略整體流程中的問題。
（3）維護困難
項目初期，產品原型會經歷非常多的改動，甚至會出現刪掉某個大模塊的情況，具體到每一個頁面，也時常經歷著大改的考驗，因此過于復雜的交互，會給后續產品原型的維護帶來諸多困難。
（4）職責不明
如果項目還有交互、視覺同學參與進來，那么太過于精細的產品原型，反而會限制交互、視覺的發揮，讓交互、視覺的工作淪為“畫圖”，反而少了許多對項目的思考及參與，長此以往，對整個項目反而是不利的。
目前包括Axure在內的很多原型設計工具，都支持制作復雜的交互效果，但我們要秉承“為我所用”、“我會，但沒必要”的原則，使用合適恰當的方式來呈現需求。
個人是習慣將彈框這些默認不可見的元素，也放到頁面原型的旁邊，并在頁面中增加相關標記，表明頁面元素與這些彈框的關系；此外，也會在頁面中增加相關文字說明，以便研發同學了解。
五、發布在線原型Axure這些原型工具是支持生成html文件的，可以直接通過瀏覽器打開，查看原型的具體內容。
然而，如果原型需要頻繁修改，那么原型文件的同步就成了大問題。往往一個原型文件剛發出去，就發現有一些需要修改變更的地方，又需要趕緊打包一個新的版本。多的時候，一天打包十幾個版本都是可能的。
版本眾多的原型文件，很容易造成信息不對稱，因為產品經理也很難將最新的原型文件及時同步給到所有人。
因此，有一個統一的，在線的，可隨時更新的在線原型是非常必要的。
Axure本身支持將產品原型發布到云端，可以直接鏈接查看產品原型，不過這樣做會存在信息泄露的風險。
為了規避這種風險，我們可以將原型的靜態文件更新到自己的服務器上。
我之前的項目中，就曾經通過這種方式進行管理，讓研發同學幫忙將原型文件發布到內網的服務器中。
只不過這種習慣最終沒有保留下來，因為服務器權限還是在研發同學那里，每次發布原型都需要研發同學幫助，后來項目團隊發生變化之后，就沒有繼續沿用這個方法了。
后來發現了騰訊內部的pages工具，可以來發布靜態頁面，產品經理自己就能適用git工具發布更新原型文件，雖然存在一點門檻，但上手之后卻是非常方便。
目前我們團隊內部的產品經理都主要使用這種方式來對外發布產品原型，推薦大家學習使用。
六、時常更新，并記錄變更內容在線原型雖然可以實時更新，但也引發了新的問題：產品經理在同步原型文件的時候，一般還會同時同步修改的內容。
但可以方便地實時更新之后，這種修改記錄的同步就很難要求了。即使同步了，往往也只是在項目團隊內部，而很難同步到項目團隊以外。
因此在原型中，最好能夠配套一個ChangeLog，這樣可以讓所有人員，快速了解原型的更新內容。即使每天原型更新十幾次，也能夠在ChangeLog中說明所有改動的內容。
七、適合的，就是最好的之前說過，原型是一種溝通工具，既然是一種溝通工具，就需要根據溝通的對象，溝通的場景，以及團隊內的流程及習慣進行調整，并沒有放諸四海皆準的標準，適合的，就是最好的！
作為產品經理，在產品需求溝通這個環節，應該將團隊成員當成用戶，將原型當成一個產品來打磨。
團隊成員，除了研發，還會有PM、測試，乃至是Leader，不同角色想要從原型中獲取的信息各不相同。
同樣是研發職能，不同的研發人員的習慣也不盡相同。
作為產品經理，在進行原型設計時，需要考慮不同職能，不同人員的需要，不斷地打磨原型內容的呈現，盡可能地提高團隊內部的溝通效率。
最后也說一句，我們不能忽略忽略產品原型在項目中的作用，也不能過度拔高原型的作用，不能因為有了清晰準確的產品原型，就省略掉必要的溝通。
作者：klayhuang，騰訊產品運營；公眾號：騰訊大講堂
本文由 @騰訊大講堂原創發布于人人都是產品經理，未經許可，禁止轉載。
【項目比選流程】題圖來自Unsplash，基于CC0協議。

項目比選流程

猜你喜歡