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

Ruby語言的發(fā)明人Matz說：“代碼越少，bug就會(huì)越少?！蔽臋n也是一樣，越簡短，包含的錯(cuò)誤就越少，同時(shí)也更容易閱讀，更容易更新，更可能帶來簡潔的設(shè)計(jì)，總之，保持簡短的好處太多了。對(duì)于產(chǎn)品團(tuán)隊(duì)來說，簡短的文檔更容易撰寫，所以這一條原則并不是負(fù)擔(dān)。

這段話給產(chǎn)品經(jīng)理在梳理需求文檔時(shí)提了一個(gè)非常重要的建議：保持需求文檔的簡短。

產(chǎn)品需求文檔作為一種和研發(fā)人員溝通的重要工具，梳理不好，會(huì)直接影響后續(xù)與研發(fā)人員的溝通質(zhì)量?！氨３中枨笪臋n的簡短”，這點(diǎn)看似簡單，但卻是我在最初做產(chǎn)品，梳理需求文檔時(shí)體會(huì)最深的一點(diǎn)。

在剛做產(chǎn)品時(shí)，我發(fā)現(xiàn)一個(gè)奇怪的現(xiàn)象：在我們開完需求會(huì)議把產(chǎn)品大概的需求告訴研發(fā)人員后，他們?cè)趯?shí)際開發(fā)過程中很少去看我寫的需求文檔。通常是遇到問題口頭詢問。我當(dāng)時(shí)就很奇怪，文檔里每一步都寫得很細(xì)，為什么他們不喜歡讀我寫的文檔？

于是我?guī)е蓡柡脱邪l(fā)溝通，得到的答案是：他們沒時(shí)間看我寫的過于冗長的文檔。他們只需要簡單地理解這個(gè)功能大概是做什么的，怎么去實(shí)現(xiàn)它即可。文檔中的內(nèi)容又多又復(fù)雜，要把文檔完全理解非常費(fèi)時(shí)，一些不影響開發(fā)的字段完全可以放在備注中。從這件事之后，我開始反觀自己文檔的問題。以前總害怕研發(fā)看不懂，把一個(gè)需求寫得非常細(xì)。復(fù)雜的一個(gè)功能可能寫到十幾行（接近300多個(gè)字）。站在研發(fā)人員的角度來看，在較短的開發(fā)時(shí)間里想用最快的速度去理解需求，長篇幅的文檔確實(shí)增加了他們理解上的難度以及閱讀的速度。

在梳理需求文檔時(shí)，保持文檔簡短，會(huì)增加整個(gè)文檔的易讀性。以下是我總結(jié)的保持文檔簡短的3個(gè)步驟。

1. 分析需求：開發(fā)需要實(shí)現(xiàn)哪些操作。
2. 填寫軀干：寫出操作流程。
3. 增加枝葉：展示具體內(nèi)容。

讓文檔瘦身不僅僅增加了易讀性，其實(shí)也增加了它的靈活性。因?yàn)榇蠹以陂_發(fā)過程中會(huì)發(fā)現(xiàn)，最終開發(fā)完的產(chǎn)品與原來寫的需求文檔很難保持完全的一致性。由于接口提供問題、技術(shù)等各種原因，開發(fā)過程中多多少少會(huì)出現(xiàn)需求變更的情況，把文檔寫得簡短一些也利于以后變更時(shí)修改。

實(shí)踐案例

因?yàn)樗诠尽獊喰趴萍际且患覍Ｗ⒂跒殡娦胚\(yùn)營商提供IT解決方案和服務(wù)的公司。有一種常見的場(chǎng)景就是：電信運(yùn)營商的客戶經(jīng)理經(jīng)常會(huì)在一天工作的開始，查看當(dāng)天未讀的提醒，或是待閱的工作。我們將客戶經(jīng)理的這個(gè)需求暫定一個(gè)名字叫：待閱功能。待閱功能的大致描述是這樣的：客戶經(jīng)理看到的待閱事項(xiàng)主要有三大類：欠費(fèi)提醒、賬單提醒、生日提醒。每個(gè)提醒點(diǎn)擊后可查看一些具體內(nèi)容，比如，生日提醒需要顯示提醒時(shí)間、提醒對(duì)象、短信內(nèi)容，等等。

拿到這個(gè)需求我們分三步走。

?第一步：分析需求

通過分析具體的需求可以發(fā)現(xiàn)研發(fā)人員其實(shí)要做的就是一個(gè)查詢操作。

第二步：填寫軀干

為保持簡短性，我的需求描述主要寫成：作為客戶經(jīng)理，我需要在待閱功能中可查看3類提醒事項(xiàng)，如欠費(fèi)提醒、賬單提醒、生日提醒。提醒以列表形式展現(xiàn)，點(diǎn)擊某條提醒可查看具體內(nèi)容（具體內(nèi)容是一些比較詳細(xì)的字段，如提醒名稱、提醒日期等）。

第三步：增加枝葉

像上文中所提示的那樣，把需要顯示的具體內(nèi)容放入了備注中。因?yàn)檫@些內(nèi)容并不會(huì)影響開發(fā)，如果放在需求描述中，反而會(huì)降低閱讀的速度和增加理解上的負(fù)擔(dān)。

同時(shí)很重要的一點(diǎn)：我會(huì)在備注的最后標(biāo)注需求來源、需求提出時(shí)間、需求提出人。因?yàn)橐郧坝龅竭^一種情況：產(chǎn)品開發(fā)完成后，由于時(shí)間比較久，很多需求的來源都淡忘了，此時(shí)也就無法得知當(dāng)初為什么要留下這個(gè)功能，為什么會(huì)有這個(gè)字段。若不幸遇到項(xiàng)目需求確認(rèn)人離開，同時(shí)文檔中沒有留下任何確認(rèn)過的需求來源的記錄。在產(chǎn)品驗(yàn)收時(shí)，若甲方對(duì)產(chǎn)品需求提出任何異議，就很難予以應(yīng)對(duì)，也無法對(duì)應(yīng)當(dāng)時(shí)的需求責(zé)任人。

總結(jié)分析

同保持文檔的簡短性一樣，在需求變更后，針對(duì)需求文檔的后期維護(hù)也是梳理需求文檔時(shí)非常重要的一點(diǎn)。因?yàn)樵诋a(chǎn)品的開發(fā)階段，會(huì)遇到零零散散的提升用戶體驗(yàn)或修改功能的需求提出，若不及時(shí)記錄，到最后產(chǎn)品驗(yàn)收時(shí)才發(fā)現(xiàn)漏做需求，會(huì)讓自己陷入一種非常窘迫的境地。在與研發(fā)人員不斷溝通和磨合后，我總結(jié)了幾點(diǎn)需求變更后，如何梳理需求文檔的經(jīng)驗(yàn)分享給大家。

1. 一定要及時(shí)把變更的需求寫入需求文檔中，不要拖到下次再寫。
2. 用高亮的顏色標(biāo)出變更的細(xì)節(jié)，如需要顯示的字段內(nèi)容。
3. 對(duì)于做了刪改的需求要標(biāo)明原因以及時(shí)間。

以上3點(diǎn)是關(guān)于需求文檔一些建議，在實(shí)際的文檔梳理中非常受用。但偶爾也會(huì)遇到研發(fā)同志過于忙碌忘記看文檔，時(shí)間一長有可能會(huì)出現(xiàn)需求變更忘記開發(fā)的情況。于是我專門為變更的需求準(zhǔn)備了一個(gè)文檔。文檔中描述有具體需求內(nèi)容、需求來源、提出時(shí)間和上線時(shí)間。拿著文檔跟蹤開發(fā)進(jìn)度，可以避免變更的需求忘記開發(fā)的情況。

以上是關(guān)于梳理需求文檔的一些經(jīng)驗(yàn)總結(jié)。其實(shí)在工作中，無論是文檔、郵件，還是面對(duì)面溝通，“簡潔精煉”都是一項(xiàng)非常受用的工作技能。希望我的經(jīng)驗(yàn)分享會(huì)對(duì)你有幫助。

#作者信息#

田捷，微信：TJ567765。亞信科技（中國）有限公司一名PO（Product Owner，產(chǎn)品負(fù)責(zé)人），場(chǎng)景并負(fù)責(zé)過多個(gè)項(xiàng)目，主要有智能終端版CRM、智能終端版ESOP、實(shí)名信息采集等項(xiàng)目。擅長電信領(lǐng)域軟件服務(wù)應(yīng)用的產(chǎn)品策劃。在電信領(lǐng)域的需求梳理以及原型設(shè)計(jì)方面積累了一些經(jīng)驗(yàn)。

在日常生活中，喜歡逛手機(jī)中的各種應(yīng)用，主動(dòng)發(fā)現(xiàn)最新、最好用的交互設(shè)計(jì)以及最流行的界面模式，分析手機(jī)APP的受眾人群和用戶需求。善于自我反省和總結(jié)，喜歡結(jié)交朋友，交流思想。

本文選自《產(chǎn)品經(jīng)理：48位一線互聯(lián)網(wǎng)產(chǎn)品經(jīng)理的智慧與實(shí)戰(zhàn)》

未經(jīng)書面授權(quán)，禁止轉(zhuǎn)載，違者追究法律責(zé)任。