?????????
隨著
IT
日新月異的發(fā)展，現(xiàn)如今回頭再瀏覽一下曾經(jīng)光輝的程序員
1.0release
時代，曾經(jīng)光輝但卻原始。
?????????
既然現(xiàn)在的項目開發(fā)已經(jīng)脫離了原始的自給自足時代，進入手工作坊或者工業(yè)時代，那必不可少的就要有團隊內(nèi)的交流和團隊與團隊的交流。尤其要提到的是項目前期的規(guī)劃人員在得到用戶需求以后交付實施之前（這個關(guān)節(jié)是用戶需求與實際開發(fā)的一個接軌過程），會出現(xiàn)頻繁的團隊間信息傳遞。此時項目的一個關(guān)鍵的問題產(chǎn)生了，國內(nèi)大多數(shù)軟件公司在此時已經(jīng)默認這個項目是有價值去做的，但是，由于項目提出人只是感覺到應(yīng)該出一個這樣的項目，至于業(yè)務(wù)點啦，針對性啦等等這些很重要的工作點尚沒有被明確地提出來，或者提出了一部分也只是根據(jù)他們實際實施中常碰到的問題提出來的，（此時能做到這一點應(yīng)該說已經(jīng)很不錯了，已經(jīng)可以肯定的說你這個項目是有實施價值的，能為客戶有目的地去產(chǎn)生價值，至于項目發(fā)布后是不是這樣那的就是另一回事了）這些需求還不是很到位，打個比喻，就象一個人說話一樣，他潛意識可能知道是什么但是用語言表達的時候打了折扣，所以就需要需求分析人員去進一步發(fā)掘。如果能從客戶提交的需求里，或者在頭腦風(fēng)暴之類的會議中，能找到促使項目產(chǎn)生而隱藏的真正原因那就更加地理想了。
?????????
但在我們實際的開發(fā)中往往不是這樣的，由于從客戶交付需求到開發(fā)，往往要經(jīng)過一個篩選的過程，所以開發(fā)人員接收到的資料和用戶初期提出的相比，已經(jīng)面目全非了。但是此時如果假設(shè)提供給開發(fā)人員的資料已經(jīng)很全面、很詳細，資料里的內(nèi)容
“
所見即所得
”
，這也可以算做比較完美的。但是實際開發(fā)中往往是開發(fā)人員在拿到這份資料的時候反而不如客戶直接對他說我就想要個什么什么的東東，而實際開發(fā)中這樣的情況是不會有的，所以開發(fā)人員會反復(fù)問那個需求也尚沒有完全清楚的需求人員，經(jīng)驗豐富的
IT
人會靈活解決這個問題，但也不會避免要出現(xiàn)和客戶再確定的情況。而此時如果這個需求人員也不是很在行，那災(zāi)難就來了，需求人員會在開發(fā)人員的要求下直接與客戶交流，在此之前可能會有相當(dāng)長一段時間處于膠著狀態(tài)。
??????
我認為在現(xiàn)階段的情況下適合擔(dān)任需求分析的團隊了至少要有一個人是經(jīng)驗老道的，起領(lǐng)頭作用，外界輸入的信息是要經(jīng)過該團隊人員去加工篩選的，而不是用戶提什么就列出來什么。很可笑的事情是，在開始編碼前，需求是由表示層的人員來向開發(fā)人員來闡述。更可笑的是，需求人員在向開發(fā)人員闡述需求的時候模棱兩可、表達含糊直至旁人說出來答案，然后很謙虛地附和一聲，不了了之、濫竽充數(shù)。
??????
以上意見僅供參考，實屬虛構(gòu)、如有雷同、純屬巧合。