国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

本流程僅適用于軟件產(chǎn)品開發(fā)。enjoy~

在行業(yè)內(nèi)，產(chǎn)品研發(fā)線上包括的職位分別有產(chǎn)品經(jīng)理、項目經(jīng)理、用戶研究、交互設(shè)計師、視覺設(shè)計師、前段工程師、開發(fā)vs服務(wù)、測試等角色，部分公司產(chǎn)品經(jīng)理兼著項目經(jīng)理的工作，或交互設(shè)計師也兼著用戶研究的工作，甚至交互和視覺設(shè)計統(tǒng)一由產(chǎn)品設(shè)計師一同承擔(dān)，這也是行業(yè)發(fā)展的需要和趨勢，會對各角色的能力要求越來越高，不同企業(yè)和不同的團隊都會根據(jù)不一樣的項目類型、平臺、資源等因素，決定團隊的搭配。產(chǎn)品是整體團隊共同努力的產(chǎn)出物，一個好產(chǎn)品的誕生除了團隊成員的個人能力，還有需要建設(shè)一套規(guī)范的協(xié)作工作流程。

以下以產(chǎn)品經(jīng)理、交互設(shè)計師、視覺設(shè)計師、開發(fā)、測試為團隊案例進行具體講解。

如何建立

1、明確產(chǎn)品設(shè)計五個階段

所有的軟件都會經(jīng)過這五個階段，分別是：

立項階段：一個項目在正式立項會后，就算正式啟動。

參與人員：項目經(jīng)理、產(chǎn)品經(jīng)理、設(shè)計師、開發(fā)、測試等項目組各環(huán)節(jié)關(guān)鍵成員參與

需求階段：主要梳理用戶需求、商業(yè)需求、客戶需求

參與人員：產(chǎn)品經(jīng)理、用戶研究、交互設(shè)計師

設(shè)計階段：主要包含交互、視覺方案詳細設(shè)計

參與人員：交互設(shè)計師、視覺設(shè)計師

開發(fā)階段：實現(xiàn)產(chǎn)品方案方案

參與人員：開發(fā)vs服務(wù)

驗證階段：檢驗產(chǎn)品質(zhì)量，設(shè)計師進行走查根據(jù)實現(xiàn)

參與人員：測試人員、產(chǎn)品經(jīng)理、設(shè)計師

項目組各成員必須完全理解各階段的目標(biāo)，及自身在各階段的主要職責(zé)目標(biāo)。

2、各階段主要目標(biāo)及職責(zé)

（1）立項階段

產(chǎn)品經(jīng)理：輸出產(chǎn)品概要說明，主要描述本項目主要目標(biāo)任務(wù)；

發(fā)起立項會議，制定會議議題，討論項目大概的時間計劃需求，立項前必須經(jīng)過多方確認（包括：資源分配、技術(shù)可行性等評估）；

輸出物：項目計劃表

交互設(shè)計師：進行目標(biāo)用戶分析（即為什么做這個？這個需求針對的用戶群是什么？用戶特征是什么？），具體方法包括目標(biāo)用戶定位、桌面研究、人物角色、競爭分析、實鏡調(diào)查等，發(fā)現(xiàn)和理解用戶需求；

輸出物：產(chǎn)品概要文檔

視覺設(shè)計師：該階段的需求還未完全明確，可以針對產(chǎn)品類型、方向進行設(shè)計趨勢分析；

輸出物：設(shè)計趨勢分析文檔

（2）需求階段

需求階段包括了需求發(fā)現(xiàn)、需求分析、需求管理工作。

產(chǎn)品經(jīng)理：

1. 洞察行業(yè)，理解用戶，明確商業(yè)目標(biāo)；
2. 收集各方來源需求，包括：用戶反饋、用研分析需求、設(shè)計需求、市場需求、領(lǐng)導(dǎo)需求等等，并進行分類管理；
3. 進行需求討論，邀請專家、用研、交互設(shè)計師進行討論，使用KANO模型、優(yōu)先排級、二維知覺圖等工具分析；
4. 將確定的需求整理成需求list，并輸出給交互設(shè)計師、視覺設(shè)計師；
5. 書寫產(chǎn)品PRD文檔，并組織多方評審會議；
6. 待方案通過后，將PRD文檔輸出給交互、視覺、開發(fā)；
7. 組織交互設(shè)計師評估交互設(shè)計時間進度；
8. 需求閘門關(guān)閉，控制該版本需求數(shù)量，避免不斷的改變或加入需求，造成項目的失控。

輸出物：具體的需求list、產(chǎn)品需求文檔

交互設(shè)計師：

1. 挖掘用戶需求，發(fā)現(xiàn)用戶痛點（滿足什么場景下的需求？使用過程中的痛點在哪？當(dāng)前的主導(dǎo)需求和潛在需求？），使用流程圖、用戶旅程圖、生態(tài)系統(tǒng)圖、親和圖等工具，這是用研、交互最核心的部分，所有的設(shè)計idea都需建立在目標(biāo)用戶和使用場景之上，脫離用戶談設(shè)計都是不能成立的；
2. 將痛點整理成需求list，輸出給產(chǎn)品經(jīng)理匯總；
3. 待產(chǎn)品經(jīng)理輸出PRD過程文檔，可以根據(jù)需求進行初步概念設(shè)計方案，概念方案輸出的形式可以是草圖、DEMO、動態(tài)演示、高保真原型，具體不做限制，目標(biāo)可以明確表設(shè)計想法，時間控制一般迭代版本在3天左右，大型項目控制在7天左右；
4. 內(nèi)部審核，確定參會人員范圍、會議目標(biāo)，應(yīng)提前1天發(fā)出需求評審文檔，以便評審人員提前了解具體方案，發(fā)現(xiàn)問題，可以避免會議過程中無序討論爭執(zhí)，提高會議效率；并在會議后做好會議記錄，郵件方式發(fā)生相關(guān)人員，針對評審結(jié)果對方案進行優(yōu)化（后續(xù)的相關(guān)評審會議都需要這樣做）；
5. 快速驗證，設(shè)定好測試案例，最好找真實用戶對象進行測試，若資源、時間不允許的情況，可以找身邊同事、親人、朋友進行定性研究，3-5個即可。最小成本試錯，設(shè)計最優(yōu)方案，如果你想偷懶跳過該步驟，最后的方案很可能是偏離用戶需求，那么將以十倍甚至更多的代價進行修改彌補，甚至錯過了好的市場時機，所有的設(shè)計必須放入實際的場景中于用戶對話才能得以驗證，所以在產(chǎn)品孕育過程必須堅持與用戶的對話；
6. 設(shè)計提案，合理組織提案內(nèi)容，把目標(biāo)理解、需求分析、概念方案（與視覺方案一起）整個設(shè)計思路梳理清晰，另外注重個人的表達能力，這也是設(shè)計師必須課，把握好每一次這樣的機會。同樣提前發(fā)起會議，確定參會人員范圍、會議目標(biāo)，應(yīng)提前1天預(yù)定會議上，并發(fā)出方案，可以提前收集關(guān)鍵評審人員對方案的意見，可以預(yù)期了解各個不同人員的想法，提前發(fā)現(xiàn)問題，預(yù)想優(yōu)化方案和提議；

輸出物：用戶分析報告、分析過程文檔、照片記錄、語音記錄、需求分析結(jié)果文檔、概念設(shè)計方案

視覺設(shè)計師：

1. 進行設(shè)計趨勢分析，并輸出分析報告；
2. 配合交互設(shè)計進行概念方案設(shè)計，快速將ideal進行視覺呈現(xiàn)；
3. 進行視覺風(fēng)格推導(dǎo)。

輸出物：概念設(shè)計方案、視覺風(fēng)格推導(dǎo)文檔

（3）設(shè)計階段

從抽象到具象關(guān)鍵的一步。

產(chǎn)品經(jīng)理：

1. 跟進交互設(shè)計方案，確保不偏離初衷；
2. 參與設(shè)計評審會議；
3. 在進行方案技術(shù)評估會議上，對各交互設(shè)計、視覺設(shè)計、開發(fā)、測試的時間進行梳理和評估，時間必須精確到天，包含了版本提交和上線日期。

輸出物：詳細項目時間關(guān)鍵節(jié)點文檔

交互設(shè)計師：

1. 進行交互詳細設(shè)計，包含信息架構(gòu)圖、頁面流程圖、任務(wù)流程圖、整體設(shè)計方案、交互狀態(tài)注釋等，注意交互文檔的標(biāo)準化格式、文檔命名、文案真實性、避免視覺化和使用截圖、文件命名方式、建立標(biāo)準控件，最好制定交互文檔書寫規(guī)范，并嚴格執(zhí)行，這樣有利于設(shè)計、開發(fā)、測試人員閱讀，降低溝通成本，更能體現(xiàn)個人的專業(yè)度；
2. 組織內(nèi)部審核，包含自檢和設(shè)計組審核（小范圍），設(shè)計師本身需要養(yǎng)成嚴謹細心態(tài)度，在發(fā)出文檔前一定養(yǎng)成自檢習(xí)慣；
3. 評審范圍再次擴大，評審人員包含總監(jiān)、產(chǎn)品、交互，會議后必須整理會議記錄，并根據(jù)評審結(jié)果優(yōu)化方案；
4. 召集項目組各環(huán)節(jié)關(guān)鍵成員進行方案可行性評估，主要包含技術(shù)可行性評估、技術(shù)范圍評估、開發(fā)時間評估，并在過程中可能會根據(jù)技術(shù)的評估會對方案進行評審，會議后必須整理會議記錄，并根據(jù)評審結(jié)果優(yōu)化方案，還有需確定各環(huán)節(jié)具體參與人員名單；
5. 最后一輪方案需求評審，再次召集項目組各環(huán)節(jié)關(guān)鍵成員，對最終方案進行一次評審，在過程可能還會存在細枝末葉的調(diào)整，但基本可以保證方案方向的確定性，確保后續(xù)開發(fā)階段不做大的需求變動；
6. 宣講，應(yīng)該召集項目組所有設(shè)計、開發(fā)、測試等著實參與人員，針對方案進行宣講，過程中對方案不做具體討論；

輸出物：詳細交互設(shè)計方案

在設(shè)計過程中經(jīng)過了大大小小的多倫評審，這樣有利于后續(xù)需求方案的穩(wěn)定性，降低整個開發(fā)成本，且進入開發(fā)階段后，產(chǎn)品經(jīng)理可抽出身來進行下一個版本的規(guī)劃和思考，具體的實施由設(shè)計師、開發(fā)、測試執(zhí)行即可。

視覺設(shè)計：

1. 關(guān)鍵頁面設(shè)計，確定基礎(chǔ)風(fēng)格，建立基礎(chǔ)規(guī)范；
2. 根據(jù)交互設(shè)計方案，進行具體視覺詳細設(shè)計；
3. 組織評審：堅持自檢、小組范圍評審、產(chǎn)品范圍評審等評審原則（以上交互設(shè)計環(huán)節(jié)有詳細說明），避免后續(xù)不斷調(diào)整風(fēng)格問題，前期關(guān)鍵頁面設(shè)計盡可多預(yù)留時間進行設(shè)計推導(dǎo)；
4. 輸出設(shè)計資源給予開發(fā)或前端工程師，注意模塊分組、圖標(biāo)命名、以及不同分辨率的設(shè)計和管理；

輸出物：詳細設(shè)計設(shè)計方案、設(shè)計資源

開發(fā)人員：

1. 通過參與評審會議，熟悉了解產(chǎn)品邏輯、流程，設(shè)計底層框架；
2. 提出技術(shù)支持需求；
3. 技術(shù)評估會上評估時間需求；

測試人員：

1. 通過參與評審會議，熟悉了解產(chǎn)品邏輯、流程；
2. 技術(shù)評估會上評估測試時間；
3. 制定測試案例和具體執(zhí)行計劃；

（4）開發(fā)階段

產(chǎn)品經(jīng)理：

1. 在該階段，產(chǎn)品經(jīng)理可以進行下一個版本的規(guī)劃和思考；
2. 開發(fā)過程中，合理調(diào)配資源，支持各方需求；
3. 還原度跟進，整理相關(guān)BUG，通過固定工具反饋給測試人員。

交互設(shè)計師：

1. 整理交互設(shè)計規(guī)范，包含：基本原則、通用交互的規(guī)范、基本控件交互規(guī)范、擴展控件交互規(guī)范、信息提示規(guī)范、導(dǎo)航規(guī)范、頁面典型視圖規(guī)范、窗口規(guī)范、文本規(guī)范等，作為后續(xù)設(shè)計指導(dǎo)；
2. 還原度跟進，整理相關(guān)BUG，通過固定工具反饋給測試人員；
3. 開發(fā)反饋完善方案。

視覺設(shè)計師：

1. 整理視覺設(shè)計規(guī)范，包含：標(biāo)準色彩、標(biāo)準文字組合、基礎(chǔ)布局、圖標(biāo)風(fēng)格、基本控件、通用頁面結(jié)構(gòu)等，作為后續(xù)設(shè)計指導(dǎo)；
2. 還原度跟進，整理相關(guān)BUG，通過固定工具反饋給測試人員；
3. 開發(fā)反饋完善方案。

開發(fā)人員：

1. 按計劃進行具體開發(fā)；

測試人員：

1. 制定詳細的測試案例；
2. 根據(jù)開發(fā)結(jié)果進行初步測試。

（5）驗證階段

產(chǎn)品經(jīng)理：

1. 策劃上線準備，包含：運營推廣、產(chǎn)品上線準備（引導(dǎo)頁、應(yīng)用商店截圖、部署用戶反饋渠道等）；
2. 收集測試反饋產(chǎn)品問題；
3. 遺留問題跟蹤；
4. 準備上線后，獲取用戶反饋和數(shù)據(jù)分析方式和工具。

交互和視覺設(shè)計：

1. 遺留問題跟蹤；
2. 還原度跟進，整理相關(guān)BUG，通過固定工具反饋給測試人員；

開發(fā)人員：

1. 根據(jù)測試反饋進行bug修復(fù)。

測試人員：

1. 執(zhí)行第一輪、第二輪測試；
2. 合理整理測試問題，并及時反饋給產(chǎn)品、設(shè)計、開發(fā)；
3. 整理最后的測試報告。

以上即整個產(chǎn)品設(shè)計流程，簡單描述了不同角色在五個階段的不同職責(zé)，規(guī)范輸入輸出，有效把控團隊節(jié)奏，合理推進項目塑造產(chǎn)品。在實際工作中其實并不會完全依據(jù)流程執(zhí)行，會根據(jù)實際團隊搭配、項目的大小進行調(diào)配。尤其巨無霸項目，必須拆分成多個模塊進行，每個模塊都按該流程走，類似于敏捷開發(fā)中提到的sprint（沖刺）概念。

對比敏捷開發(fā)：

上圖為敏捷宣言遵循的原則，可以看出敏捷強調(diào)去文檔、去流程，通過高效的溝通傳達信息，這樣對團隊之間的耦合度要求更高，同時更適合創(chuàng)業(yè)團隊，一般企業(yè)內(nèi)都不會建議完全去文檔化的過程，需要考慮版本的迭代、團隊擴大、人員的變更情況，同時文檔可以節(jié)約一些常規(guī)問題上的溝通成本，同時也降低了錯誤發(fā)生率。但是敏捷中的“敏”是可以應(yīng)用到上述流程中，將每個模塊拆得更細，流程中也更加快，同樣過程中使用站會（整理每天完成任務(wù)和當(dāng)天計劃任務(wù)）、燃盡圖（一種項目管理工具）、故事版（四個欄目：待開發(fā)、開發(fā)中、待測試、測試中、待發(fā)布，每增加一個任務(wù)需求都放入該故事版中，讓團隊成員明白每個需求的狀態(tài)）方式和工具。

適用范圍：

1. 如果你們團隊中還沒有一套規(guī)范流程，可以以該流程為基礎(chǔ)進行實施，再根據(jù)自身特色進行完善流程；
2. 團隊人數(shù)超過10人，或多個產(chǎn)品線的企業(yè)，可以以該作為流程規(guī)范，讓團隊深刻理解該流程，對號入座即可；
3. 正在轉(zhuǎn)型中的企業(yè)，還沒有達到互聯(lián)網(wǎng)產(chǎn)品團隊的成熟、效率，可以以此流程為基礎(chǔ)，走穩(wěn)每個版本迭代；
4. 如果沒有執(zhí)行敏捷方法，可以在此流程基礎(chǔ)上融入敏捷精髓，進行嘗試；

最后希望能夠讓各位看官有所收獲，歡迎交流學(xué)習(xí)！

【完】

作者：Joun Deng? ?微信公眾號：J交互

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

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