問題描述：
ericzhangali：
用三個角色來描述：開發(fā)部門，測試部門，客戶。
公司和客戶合作的方式是根據(jù)客戶一個模糊的需求做出原型，由客戶使用后一次次提出修改意見，一次次修改后由客戶決定何時可以量產(chǎn)。
目前的流程是：
1）開發(fā)人員有新版本直接release給客戶，以改動大小和多少決定是否送測試部門測試。
2）客戶收到版本后評測，把修改意見反饋給開發(fā)人員。
3）測試部門收到測試需求后測試，并把測試結(jié)果反饋給開發(fā)人員。
出現(xiàn)的問題是：
1）如果開發(fā)人員決定需要送測，往往也是在送測的同時已經(jīng)release給客戶。測試是否失去了部分意義。
2）開發(fā)人員只關(guān)注客戶反饋的需求和bug，并不關(guān)心測試部門反饋的bug。測試是否失去了部分意義。
3）測試人員不了解客戶需求，測試工作無法把握重點。
4）如果流程管理認(rèn)為測試部門應(yīng)該把握release產(chǎn)品的質(zhì)量，要求每次release前都要送測，是否合理。（背景是經(jīng)常客戶要求很急，上午的電話或mail，下午就要新版本。）
希望討論的問題除了上面的之外還有，
1）項目經(jīng)理/產(chǎn)品經(jīng)理如何協(xié)調(diào)這三者的關(guān)系？
2）與客戶打交道的窗口是在開發(fā)部門合適還是在質(zhì)量部門（測試部門）合適？
（雖然與測試緊密相關(guān)，但揣測一下，覺得還是發(fā)在項目管理區(qū)。）
精彩回復(fù)：
AlexLJM：
1）如果開發(fā)人員決定需要送測，往往也是在送測的同時已經(jīng)release給客戶。測試是否失去了部分意義。
這種是Alpha和Beta測試同時進(jìn)行。其實關(guān)注點不同，不能就說就沒意義。
2）開發(fā)人員只關(guān)注客戶反饋的需求和bug，并不關(guān)心測試部門反饋的bug。測試是否失去了部分意義。
如果開發(fā)不關(guān)心測試的意見，那按照我們這里的話來說就是瞎忙活。測試最終的目的是為了更好的為產(chǎn)品質(zhì)量服務(wù)。其實我們有時候的角色也有點Client。把1）和2）和起來看。這產(chǎn)品就根本不需要測試跟進(jìn)。
3）測試人員不了解客戶需求，測試工作無法把握重點。
沒有需求的測試是盲目的。盲目的測試有時候不僅提高不了產(chǎn)品質(zhì)量還會給整個產(chǎn)品帶來副作用。不過很多公司都沒有書面需求的習(xí)慣。這個時候就要測試人員具有需求分析的能力甚至要親自收集客戶的意見。
4）如果流程管理認(rèn)為測試部門應(yīng)該把握release產(chǎn)品的質(zhì)量，要求每次release前都要送測，是否合理。（背景是經(jīng)常客戶要求很急，上午的電話或mail，下午就要新版本。）
按照我公司的流程。這個版本是不可能出去的，除非研發(fā)自己承擔(dān)后果。（我公司產(chǎn)品release一般需要QA部門的簽字）
1）項目經(jīng)理/產(chǎn)品經(jīng)理如何協(xié)調(diào)這三者的關(guān)系？
項目經(jīng)理更多的是要對產(chǎn)品負(fù)責(zé)，產(chǎn)品經(jīng)理則要對客戶負(fù)責(zé)。項目經(jīng)理負(fù)責(zé)研發(fā)/測試的梳理和協(xié)調(diào)工作。產(chǎn)品經(jīng)理負(fù)責(zé)客戶的說服/說明以及協(xié)調(diào)工作。這里面其實就是項目經(jīng)理和產(chǎn)品經(jīng)理之間溝通問題。
2）與客戶打交道的窗口是在開發(fā)部門合適還是在質(zhì)量部門（測試部門）合適？
不知道其他公司怎么處理。我公司基本上研發(fā)/測試都有與客戶打交道的機(jī)會。測試部門甚至以后會成半個客服部門。我覺得無論研發(fā)還是測試，都應(yīng)該多了解市場，多了解客戶的想法。具體到打交道，一個項目的研發(fā)/測試主要負(fù)責(zé)人一起出發(fā)。呵呵。
鹿鳴：
按照標(biāo)準(zhǔn)的開發(fā)流程，任何不經(jīng)過測試的產(chǎn)品，都不能發(fā)給客戶。
沒有測試部門的確認(rèn)，軟件產(chǎn)品的質(zhì)量問題由項目組負(fù)責(zé)，測試部門不承擔(dān)任何的責(zé)任。
如果開發(fā)部門不支持測試部門的工作，測試部門有權(quán)利不測試產(chǎn)品。
“測試人員不了解客戶需求，測試工作無法把握重點。”這個問題問的很好，每一個測試人員對此都會迷茫，主要是時間和經(jīng)驗的關(guān)系，小軟件好把握，但大的系統(tǒng)，如果沒有經(jīng)過系統(tǒng)的培訓(xùn)是很難了解軟件過程的。所以真正測試行業(yè)軟件的時候，都需要有相關(guān)行業(yè)經(jīng)驗的參加測試小組或做為顧問。測試小組也需要進(jìn)行一定 的培訓(xùn)。（我測試過很多比較大的家伙，了解那些東西就要花費(fèi)很長的時間，實際很多的項目，測試3、4次才知道里面的東西具體是怎么運(yùn)作的）。
上面是測試部門的一些事情。下面說說管理方面的。
在實際過程中，測試部門一般都比較的弱勢，除非公司特別重視產(chǎn)品的質(zhì)量。很多的時候，留給測試的時間都不夠，在軟件行業(yè)的都知道，項目很少有按時完成的， 基本都會拖期，這個時候影響最大的其實就是測試。如果客戶急著要，即使產(chǎn)品沒有經(jīng)過嚴(yán)格的檢驗一般也都發(fā)出去了。
項目經(jīng)理的責(zé)任就是嚴(yán)格的掌握開發(fā)時間，了解客戶的需求，和測試部門進(jìn)行協(xié)調(diào)，準(zhǔn)備好一切測試部門的相關(guān)資料。（現(xiàn)在程序員都在趕進(jìn)度，基本沒有文檔，所以在測試前寫測試用例是基本不可能的，反正至少在我工作過的公司，無論是程序員的設(shè)計還是測試人員的用例等，都是事后補(bǔ)的，這是沒有辦法的事情）。
在很多的時候，測試部門可以說是代表客戶利益的，但真正成熟的軟件公司，分工都很詳細(xì)，比如有專門的需求設(shè)計人員，負(fù)責(zé)和客戶打交道；還有專門的售后服務(wù)技術(shù)支持人員；通常測試部門只負(fù)責(zé)產(chǎn)品的質(zhì)量，不會和客戶發(fā)生關(guān)系。
AlexLJM：
在很多的時候，測試部門可以說是代表客戶利益的，但真正成熟的軟件公司，分工都很詳細(xì)，比如有專門的需求設(shè)計人員，負(fù)責(zé)和客戶打交道；還有專門的售后服務(wù)技術(shù)支持人員；通常測試部門只負(fù)責(zé)產(chǎn)品的質(zhì)量，不會和客戶發(fā)生關(guān)系。
我們公司以前就是這樣做的。可惜在定位一些問題要不要改善的時候，經(jīng)常要經(jīng)過一個流程才能反饋回結(jié)果，有時候這個結(jié)果根本就不符合我們的需要。后來痛定思痛，決定減少這個流程。
鹿鳴：
測試部門測試完畢簽字確認(rèn)后，實際就已經(jīng)和項目沒有什么關(guān)系了。除非有太大的質(zhì)量問題出現(xiàn)，表明是測試部門的責(zé)任，這個時候會由公司給予測試部門相應(yīng)的處罰，與客戶或項目組無關(guān)。
至于客戶的問題，應(yīng)該有技術(shù)支持人員（通常由開發(fā)人員兼職或轉(zhuǎn)職）解決。
技術(shù)支持人員解決不了的問題，如果原項目組還存在，反饋給項目組；項目組解決不了的，就告訴客戶下一版本解決，能拖則拖，拖到客戶忘了為止。
如果項目組不存在，而問題真的很多，客戶還必須使用這個軟件。那真是太好了，趕緊重新組織項目組，開發(fā)2.0，又能掙一筆錢，哈哈。
AlexLJM：
技術(shù)支持人員解決不了的問題，如果原項目組還存在，反饋給項目組；項目組解決不了的，就告訴客戶下一版本解決，能拖則拖，拖到客戶忘了為止。
如果項目組不存在，而問題真的很多，客戶還必須使用這個軟件。那真是太好了，趕緊重新組織項目組，開發(fā)2.0，又能掙一筆錢，哈哈。
ericzhangali：
同意樓上兩位說的流程。但是感覺目前的情況是把測試工作劃分一部分到客戶的相關(guān)部門。客戶認(rèn)同的方式似乎就是發(fā)版本給他，他測試，提交bug list和修改意見，修改后再發(fā)給他，他再測試。。。直到他滿意，這里面的一次次release我個人覺得不是很正式。在時間壓力大的時候或改動很微小的 時候，這種不是很正式的release是不是一定要送測，在VSS上打label，然后得到一份不是很關(guān)注的測試報告呢？因為同時版本也已發(fā)給了客戶，也 許很快，客戶也反饋了報告。
往往有一個現(xiàn)象就是客戶提交的bug list和測試部門提交的差別很大。倒不認(rèn)為這是alpha和beta同時進(jìn)行。
這種方式確實測試部門不承擔(dān)責(zé)任。由開發(fā)部門/人員承擔(dān)。
至于測試人員了解需求的問題，情況是，對每個客戶，產(chǎn)品的功能大致是相同的，測試人員也是比較了解的，也有老手寫好的full test用例和simple test用例。但每個具體的客戶可能外觀要求不同，有的功能細(xì)節(jié)有不一致，甚至不同客戶關(guān)注的問題點也不同。我是指這個情況測試人員不了解，這個情況只有 直接和客戶聯(lián)系的開發(fā)人員了解。但開發(fā)人員又沒有太多時間跟測試人員詳細(xì)說。
如果把窗口轉(zhuǎn)移到測試部門，不知道客戶會不會有意見。他們可能更希望和直接的開發(fā)人員聯(lián)系，提出需求。
ericzhangali：
兩位可能不太了解我的情況，我口才有限，覺得有些表達(dá)不清楚。呵呵。
我覺得可以理解成原型法的一個挖掘需求階段，但又不完全是挖掘需求。
大致的過程是：
當(dāng)接到一個新的客戶時，我們按照他們要求的功能和UI大致做一個實現(xiàn)，砍到我們認(rèn)為我們的solution暫時做不到的，或行為和我們的solution差別比較大的就勸說按我們的方式做。得到這個實現(xiàn)后，客戶就不斷地測試，遞交bug list和需要修改的需求，我們就不斷地給他新版本。
這個過程可能超過一個月，頻率可能一兩天或兩三天就發(fā)出一個新版。同時我們自己的測試部門也做測試，發(fā)現(xiàn)的問題，優(yōu)先處理嚴(yán)重的。直到客戶覺得基本達(dá)到其要求，他才會量產(chǎn)、小批的給他的客戶試用。然后反饋試用出的問題和需求，我們再做修改。這個頻率一般不高。再然后，他才正式量產(chǎn)。
我覺得，小批生產(chǎn)前的是不是屬于正式的發(fā)布？是否一樣地需要嚴(yán)格按流程管理？
AlexLJM：
我覺得，小批生產(chǎn)前的是不是屬于正式的發(fā)布？是否一樣地需要嚴(yán)格按流程管理？
當(dāng)然不算正式發(fā)布，頂多算個驗收測試。看你說的情況，嚴(yán)格按照流程管理只會增加管理成本，導(dǎo)致項目延期。
鹿鳴：
現(xiàn)在規(guī)模軟件開發(fā)，重視的是開發(fā)流程，努力找到一種適普和容易控制的開發(fā)方法。但理論和實踐是有差別的，所以才有一個不斷調(diào)整的過程。這樣，根據(jù)不同的實際情況，可以對軟件開發(fā)流程有自己的理解和方法。
現(xiàn)在流行的剪裁rup就是為了適應(yīng)各種不同的情況而實施的。所以很難說哪個好或不好。但通常情況下，流行的方法都是經(jīng)過理論和大量實踐，所以一般都適合于各種情況。
至于你們公司，是否有修改的可能和必要？如果沒有，那么當(dāng)前這種開發(fā)情況就是最合適的。否則可以找咨詢公司，為你們公司的實際情況設(shè)計一套開發(fā)方案，這涉及大量的細(xì)節(jié)，這里簡略的討論實在不是很合適。
ericzhangali：
呵呵。質(zhì)量流程部門堅持要每次release前都送測，他們好象不在乎送測的意義有多少。看你說的情況，嚴(yán)格按照流程管理只會增加管理成本，導(dǎo)致項目延期，說服不了測試部門。
我覺得對release的定義模糊。
客戶工程師一個電話打來說改一個bug，馬上發(fā)個新版，是不是一次release。
如果只要有送出就要經(jīng)過測試的話，我覺得還是由測試部門和客戶打交道吧，接收需求，研發(fā)修改，提交測試，再送出。至于時間，由測試部門去和客戶協(xié)調(diào)。
wbsndts：
按照這樣的現(xiàn)實情況，談需求的窗口不應(yīng)該是研發(fā)部門了。
ericzhangali：
唉，規(guī)則都是人制定的，也都是人執(zhí)行的，混吧。
由于測試的人遠(yuǎn)離客戶，他們不清楚客戶的需求的關(guān)注的權(quán)重，往往他們報來的bug和客戶提出的bug相差很遠(yuǎn)。我們只能優(yōu)先考慮客戶的bug，而漸漸疏遠(yuǎn)公司流程中測試活動的產(chǎn)物。
這日子只能先這樣過了。。。