需求，大家常掛在嘴邊。測試的以沒有需求而煩惱，開發(fā)的也以沒有明確的需求而尷尬。有一種說法，80%的缺陷直接或間接地來自需求，這可能是二八原理的估算，無論8成也好，6成也好，需求的重要性已達(dá)到共識。
　　但事實(shí)上，目前很少有公司能做好需求管理。其原因大約有如下幾點(diǎn)：
　　1.需求管理是個復(fù)雜麻煩的過程。需求本沒有，是先有了市場，有了用戶的需要驅(qū)動才衍生出來的，所以說需求最初來自用戶的需要。而收集這些用戶的需要復(fù)雜性可想而知。對產(chǎn)品而言，要投入大量的市場調(diào)查，然后做數(shù)據(jù)統(tǒng)計，然后才可以得到最初的需求。對于項(xiàng)目，大部分客戶可能只會告訴你他想要什么功能，而不能準(zhǔn)確的描述這個功能。最初的需求經(jīng)過專職人員的解讀再生成，才能變成技術(shù)能實(shí)現(xiàn)的需求（詳細(xì)設(shè)計），然后再根據(jù)詳細(xì)設(shè)計生成開發(fā)用例，與功能點(diǎn)相對應(yīng)。
　　需求來源不止是用戶，還包括其他的共利益者，有市場人員，產(chǎn)品人員，開發(fā)測試人員和質(zhì)量管人員。他們都有權(quán)提出需求的變更和新需求，更加加大了需求收集的復(fù)雜性。
　　2.需求管理是個投入大而看不見收益的行為。往往市場人員做了大量的市場調(diào)查，提交一個需求數(shù)據(jù)，老板覺得這些結(jié)果連自己用屁股都想的出來，所以不希望繼續(xù)增加這額外的投入。另外，需求采集使項(xiàng)目周期延長，增加了大量的成本，也是老板不愿看到的。需求驅(qū)動開發(fā)，而利益驅(qū)動老板，把做需求的人力投入到市場銷售中，效果顯得更有效。
　　3.需求不可能被完全定性。有些是隱性的，有些是約定速成的。另外，需求會不斷發(fā)生著變化。當(dāng)用戶期望值變高了，軟件所依賴的環(huán)境變化了，有新的領(lǐng)域出現(xiàn)了等，所以軟件在不斷地升級中完善著需求。
　　4.需求需要多個部門協(xié)調(diào)完成。上面說的所有共利益者，有與需求有著密不可分的關(guān)系。只有建立起一套需求的管理流程，才能協(xié)調(diào)好各部門人員的寫作關(guān)系，而目前這方面的工作很少被人重視，甚至提起。也就當(dāng)大家都弄不明白需求的時候，測試的埋怨開發(fā)的，開發(fā)的埋怨產(chǎn)品的，產(chǎn)品的沒辦法，找老板拍板。
　　5.不得不說的山西煤老板的心理。新聞上經(jīng)常報道煤礦事故，可為什么屢禁不止呢？這就是暴發(fā)戶煤老板的心理，他所關(guān)注的是一天產(chǎn)出多少煤給他帶來多少利益，而安全生產(chǎn)能帶來直接利益嗎？雖然存在著事故危險，但數(shù)錢的感覺抵消了他們的擔(dān)憂，況且死幾個人，只是賠一些錢，再送些給當(dāng)?shù)氐墓賳T和記者也就沒事了。而軟件公司的老板也是這種心理，他覺得靠自己空想出來的需求，一樣開發(fā)，一樣賺錢。
　　我覺得需求應(yīng)該這樣管理：
　　1.明確需求采集渠道。由市場調(diào)查反映用戶需要，由產(chǎn)品人員整理，加上其它共利益者的需求，生成原始需求。然后提交技術(shù)部門做后續(xù)工作。
　　2.部門健全，明確責(zé)任。不要以為公司小就可省去一些職位。需求分析師，架構(gòu)師等不可省略，更不能讓底層的經(jīng)驗(yàn)不多者擔(dān)任此角色。
　　3.借用一種需求管理工具，來管理從需求采集，分析，變更，查詢等。
　　4.需求要細(xì)分到具體功能點(diǎn)。只有這樣的需求才能生成開發(fā)用例或者測試用例。
　　5.我覺得理論歸理論，操作起來一樣很難，可能任何一種管理方法都離不開整個公司的文化，團(tuán)隊(duì)建設(shè)，氛圍等。

    項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html