現(xiàn)在所處的研發(fā)期項(xiàng)目，目前遇到的問題有以下幾點(diǎn)

• 測(cè)試環(huán)境的不穩(wěn)定，造成測(cè)試干擾
• 版本質(zhì)量標(biāo)準(zhǔn)不明確，QA無(wú)法自主判斷缺陷是否該提成bug
• 研發(fā)流程混亂
• 修復(fù)bug時(shí)間安排混亂

簡(jiǎn)單先總結(jié)幾點(diǎn)問題較為明顯的。接下來(lái)對(duì)于上方幾點(diǎn)進(jìn)行一一思考。

• 測(cè)試環(huán)境的不穩(wěn)定，造成測(cè)試干擾。

  分析：

  • 策劃私底下和程序、UI或者美術(shù)等溝通需求，需求變動(dòng)且QA不知情。
  • 游戲基礎(chǔ)模塊初版未制作完成且測(cè)試通過，策劃便將了后續(xù)內(nèi)測(cè)時(shí)的玩法活動(dòng)提上了日程，因?yàn)橥娣ɑ顒?dòng)與基礎(chǔ)模塊間存在耦合，所以導(dǎo)致在開發(fā)玩法活動(dòng)時(shí)影響到基礎(chǔ)游戲模塊的測(cè)試。

  解決思路：QA與策劃多溝通達(dá)成共識(shí)：如果需求有所變動(dòng)，在通知程序等其他職能時(shí)，也應(yīng)該知會(huì)QA；同時(shí)在排期的安排上，需要各個(gè)職能leader進(jìn)行開會(huì)商討，每個(gè)職能從自己的職能角度出發(fā)，考慮研發(fā)內(nèi)容安排在當(dāng)前版本進(jìn)度是否能完成、各種風(fēng)險(xiǎn)項(xiàng)、以及開發(fā)風(fēng)險(xiǎn)預(yù)案等

• 版本質(zhì)量標(biāo)準(zhǔn)不明確，QA無(wú)法自主判斷缺陷是否該提成bug

  分析：

  • 在當(dāng)前版本研發(fā)內(nèi)容確定后，策劃未明確當(dāng)前的驗(yàn)收標(biāo)準(zhǔn)，只給QA一個(gè)需求文檔、通知QA該功能做完可以開始測(cè)試。
    標(biāo)準(zhǔn)不明確，QA只能將所有不合理的地方提成bug，策劃再審閱一遍；這樣做明顯拉低了效率，浪費(fèi)了兩個(gè)人的時(shí)間。如果標(biāo)準(zhǔn)明確，那么上述的兩件事所花費(fèi)的時(shí)間完全能夠節(jié)省下來(lái)。
    正確的應(yīng)該，例如：需求文檔A中寫著1-10條需求，策劃說我們這一版本先做1-5需求、保證玩法功能沒bug、UI美術(shù)等效果不缺失、體驗(yàn)先不管，剩余的下一版本我們迭代提需求單再做。同時(shí)，分配給UI的需求制作單也要掛上對(duì)應(yīng)負(fù)責(zé)的QA，在需求制作完畢后，UI應(yīng)該將設(shè)計(jì)稿貼出來(lái)。這樣QA對(duì)于界面UI才有一個(gè)明確的標(biāo)準(zhǔn)，而不是每次都要去找UI要圖。

• 研發(fā)流程混亂

  分析：

  • 提需求流程不規(guī)范無(wú)標(biāo)準(zhǔn)
  • 需求制作完成后，策劃通知QAleader后，才開始安排人著手測(cè)試，這時(shí)QA才剛剛開始介入需求，看需求文檔，此時(shí)的文檔分析意義已經(jīng)不大了。
  • 項(xiàng)目缺少文檔分析流程
  • 需求變動(dòng)QA不知情
  • 需求評(píng)審流程不規(guī)范無(wú)標(biāo)準(zhǔn)，甚至有點(diǎn)混亂
  • 不同經(jīng)驗(yàn)的策劃需求文檔的編寫，質(zhì)量差別過大。

  解決思路：上述說到的這些，其實(shí)還不足以表達(dá)項(xiàng)目的混亂。最主要的原因點(diǎn)在于項(xiàng)目立項(xiàng)時(shí)未進(jìn)行合理的溝通以及項(xiàng)目規(guī)劃。最簡(jiǎn)單的解決方法，QA將項(xiàng)目缺陷以及需要改進(jìn)處總結(jié)完成后，和各職能leader開會(huì)進(jìn)行討論

• 修復(fù)bug時(shí)間安排混亂

  分析：
  研發(fā)前期處于鋪量的狀態(tài)很正常，但是我們也需要提前將bug的優(yōu)先級(jí)劃分標(biāo)準(zhǔn)定下，同時(shí)修復(fù)bug的時(shí)間每周也應(yīng)該劃分出一個(gè)集中的時(shí)間修復(fù)高優(yōu)先級(jí)的bug。而不是說讓QA全部提成高優(yōu)先級(jí)，程序看到時(shí)在開發(fā)新內(nèi)容的過程中順便修復(fù)。只要游戲還沒上線，便會(huì)有源源不斷的開發(fā)需求，如果不合理重流程上安排修復(fù)時(shí)間，那么bug便會(huì)一直在，影響整個(gè)項(xiàng)目質(zhì)量以及進(jìn)度。

結(jié)語(yǔ)

曾經(jīng)希望提出想法改良項(xiàng)目流程，讓大家工作更加有條理效率，但是最后發(fā)現(xiàn)上司太過固執(zhí)己見墨守成規(guī)，同時(shí)不愿意傾聽大家一起項(xiàng)目中遇到的各種問題，所以最后打算自己思考記錄總結(jié)，作為自己成長(zhǎng)的一部分吧~
當(dāng)然每個(gè)項(xiàng)目，每個(gè)情況不一樣，我們改善流程要從項(xiàng)目本身出發(fā)。
才進(jìn)入行業(yè)1年 ，還是一個(gè)菜鳥，這篇隨筆可能想法太過天真，見笑了