中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

B端產(chǎn)品設計與需求評審過程大致是怎樣的流程？本篇文章里，作者就進行了一番梳理，從需求編寫、需求溝通、需求評審會議等維度進行了拆解，一起來看一下，或許會對你有所幫助。

簽完合同，定完項目范圍，會有一個項目章程書，產(chǎn)品經(jīng)理需要編寫產(chǎn)品需求文檔，包括業(yè)務流程圖、數(shù)據(jù)流程圖，開發(fā)的同事看見項目章程書只會對項目有個大概的了解，并不清楚自己該做些什么開發(fā)，需要產(chǎn)品經(jīng)理帶領團隊細化需求。

一、需求編寫

產(chǎn)品經(jīng)理寫了第一版需求文檔初稿后，就可以找相關開發(fā)同事溝通了。

我的需求文檔內(nèi)容一般包括業(yè)務流程圖和原型圖含說明文字，因為業(yè)務流程圖可以幫助自己更好得理解項目全局，流程圖體現(xiàn)了每個模塊和每個功能之間的關聯(lián)性，在流程圖上一畫就可以發(fā)現(xiàn)邏輯漏洞，業(yè)務流程圖順了，整個項目需求就順了。

如果畫流程圖的過程中，發(fā)現(xiàn)畫不下去的情況，一般就是對項目的需求沒有很好的理解，那么就先去翻閱項目書，看看有沒有什么遺漏的部分，如果還是不解，那么就找項目經(jīng)理或者前期參與的相關同事，目的是對整個項目的需求有全局的理解。

產(chǎn)品經(jīng)理作為整個研發(fā)團隊的需求輸入方，必須對每個需求都了如指掌。一方面，對項目非常了解才可以把需求文檔寫清楚，不會亂七八糟得到處是錯。另一方面，這有助于產(chǎn)品經(jīng)理領導力的形成，每次與研發(fā)團隊做需求交流的時候，研發(fā)同事都會提出非常多的質(zhì)疑，如果產(chǎn)品經(jīng)理經(jīng)常無法自圓其說，總是被找到很多漏洞，那么產(chǎn)品經(jīng)理在團隊中的領導力會大打折扣。

產(chǎn)品經(jīng)理雖然不是領導崗，但在團隊職責中屬于領導屬性，需要有與研發(fā)battle的能力，所以準備工作一定要充分，才可以以理服人，讓研發(fā)團隊信服你。

下圖是業(yè)務流程示意，業(yè)務流程關鍵在于簡單易懂且不遺漏，千萬不能復雜了，別人看不懂的業(yè)務流程圖不是好流程圖。

下圖是我在墨刀上做的設計稿（去敏截圖），以前我習慣用axure做原型設計，但墨刀在線版確實方便不少，看個人喜歡，以效率導向做工具的選擇。

二、需求溝通

在與相關研發(fā)同事做私下交流的過程中，產(chǎn)品經(jīng)理需要對需求做一遍闡述，在闡述的時候，往往自己就會發(fā)現(xiàn)不少設計漏洞，配合的同事也會發(fā)現(xiàn)闡述漏洞，發(fā)現(xiàn)漏洞，優(yōu)化設計，是這場交流的目的，這也是為了提高后面需求評審會的效率。

當然，這就需要產(chǎn)品經(jīng)理做一個評估，是單個交流效果高，還是團隊一起交流效率高。我的經(jīng)驗來說，不同的需求要區(qū)別對待。有些大的框架需要和研發(fā)負責人溝通，有些同事這方面的能力比較欠缺，如果拉著一起評審，反而浪費他的時間，降低溝通效率。

我的原則是，評審會議上，不說話的人就不該來參加這次會議，屬于互相浪費時間。而有些需求，涉及的功能模塊非常多，互相之間都有關聯(lián)，那么一定要把相關的同事都喊上，否則很容易出現(xiàn)一模一樣的事情講多次都無法拍板的情況，把大家都湊在一起，互相之間的約束關系，都攤開來說，整體規(guī)劃設計。

所以需求評審會議前期的需求溝通，按需組織，需要產(chǎn)品經(jīng)理對需求、對需求的實現(xiàn)、對團隊成員的分工職責，有一個全局把握后決定。

三、需求評審會議

準備好需求文檔后，就可以開正式的需求評審會議了。產(chǎn)品經(jīng)理需要發(fā)正式的郵件，一般情況就發(fā)給相關團隊成員（研發(fā)同事、測試同事、項目經(jīng)理、銷售售前等，根據(jù)團隊情況而定），并抄送給相關方（如老板，發(fā)給老板的目的主要是向上管理，讓他知道下進度情況，一般情況老板不必參會）。

產(chǎn)品經(jīng)理要把準備好的需求文檔（業(yè)務流程圖、原型圖、說明文檔等）作為附件一并發(fā)送，并預定會議室和會議時間，會議時間一般定在郵件發(fā)出后的1-3日，因為要保證團隊成員在會議前有足夠的時間看一遍文檔，在看的過程中，對有疑問的地方，標注出來，回復給產(chǎn)品經(jīng)理，一般被標注的地方就是邏輯矛盾點，也會成為評審會議溝通的重點，這樣可以提高會議的效率。

文檔內(nèi)容很多，如果直接在會議上打開，并沒有提前瀏覽，會出現(xiàn)兩個問題。

第一個問題是，團隊沒有足夠的時間消化并理解需求，看得模棱兩可，容易遺漏問題，沒有及時發(fā)現(xiàn)，那么等會議結束開始干活的時候，就會發(fā)現(xiàn)這也有問題、那也有問題，出現(xiàn)返工情況。

第二個問題是，團隊如果在會議上第一次看到文檔，會提出很多很多無謂的問題，而這些問題當他們看了全部文檔后其實就不是問題了，那么會導致會議效率低下，團隊氛圍不佳，會認為評審會議又臭又長，浪費時間。

四、需求評審會議紀要

需求評審會議結束的時候，產(chǎn)品經(jīng)理需要發(fā)會議紀要的郵件，把會議討論內(nèi)容，下一步的todo項，郵件發(fā)出，這封郵件非常重要，因為表示需求已經(jīng)通過了評審，研發(fā)同事可以開始正式干活了，需要緊接著就輸出開發(fā)設計文檔供大家評審。

研發(fā)同事在編寫開發(fā)設計文檔過程中，依然會找產(chǎn)品經(jīng)理不斷得溝通需求，以確認開發(fā)方案可以滿足需求，還有一種情況是，研發(fā)同事發(fā)現(xiàn)如果需求做適當調(diào)整，開發(fā)難度將會大大降低，縮短工期，那么也需要和產(chǎn)品經(jīng)理溝通，做一些權衡的考量。

在開發(fā)方案定下來之前，需求依然存在調(diào)整的情況，如果需求文檔做了變更，那么產(chǎn)品經(jīng)理需要同步變更給團隊，最好就是拉個會議，把幾日內(nèi)溝通的情況，與大家溝通一下，這也屬于需求評審，如果有不合理的地方，團隊提出，再做調(diào)整，需求文檔和開發(fā)方案是一個漸進明細的過程。

有變更一定要做書面記錄，不然會出現(xiàn)信息不一致的情況，會出現(xiàn)返工或扯皮，導致團隊氛圍不佳。

以上就是針對B端產(chǎn)品設計與需求評審過程的簡單分享。