摘要:本文闡述了筆者對(duì)研發(fā)過(guò)程管理的認(rèn)識(shí),并對(duì)新的需求模塊開(kāi)發(fā)工作提出了自己的流程方法.
管理,顧名思義,管的是人,理的是事.研發(fā)過(guò)程管理的目的是以較好的方式組織工程師,以較快的速度和較高的質(zhì)量完成產(chǎn)品.但實(shí)際的過(guò)程中往往呈現(xiàn)出一些"混沌"的現(xiàn)象,由于工作流程的不清晰,一方面導(dǎo)致員工對(duì)完成某件事情沒(méi)有明確的流程,而另一方面,這種不清晰,也導(dǎo)致了資源的爭(zhēng)奪、步驟的忽略、事項(xiàng)的遺忘等等.其結(jié)果,看上去工作熱熱鬧鬧,實(shí)際上混亂無(wú)序.如果沒(méi)有合適的流程與制度,這種管理上的混亂,也隨著人員的增多如滾雪球般增大.
筆者認(rèn)為,不論哪種管理方法、思想,具體落實(shí)的時(shí)候,都是制定一系列的工作流程與制度.只不過(guò)好的管理,其流程能夠提高工作的效率和有序性,好的制度能夠使員工的生產(chǎn)率更高.
套用一句偉人名言,實(shí)踐是檢測(cè)流程好壞的唯一標(biāo)準(zhǔn).要讓流程能夠發(fā)揮作用,必須定義明確,具有良好的可操作性,凡是可以用流程規(guī)范的地方,都應(yīng)制定相應(yīng)的流程.這種例子也多不盛舉,最明顯的例子是工業(yè)生產(chǎn)的制作工序,第一道工序是什么,第二道工序是什么,每一道工序要達(dá)到什么標(biāo)準(zhǔn),規(guī)定得非常明確.可想而知,如果其中某道工序規(guī)定模糊,那么不同的人的操作結(jié)果可能各不相同,最終導(dǎo)致產(chǎn)品的缺陷.又如法律法規(guī),美國(guó)的法律規(guī)定總統(tǒng)任期內(nèi)無(wú)法執(zhí)政,由副總統(tǒng)接任,如果總統(tǒng)、副總統(tǒng)都不在了,那么就由下議院議長(zhǎng)臨時(shí)代理,至選舉出新的總統(tǒng),下議院議長(zhǎng)也不在了由參議院議長(zhǎng)代理.如果他們?nèi)辉诘那闆r下,就只能軍管了,由國(guó)防部長(zhǎng)代理.細(xì)致的流程,應(yīng)盡量考慮到過(guò)程中的種種可能性,并制定規(guī)范,這樣的流程最具有可操作性,當(dāng)然在指定的時(shí)候,也要考慮效率的問(wèn)題.同樣,如果實(shí)踐中發(fā)現(xiàn)某些流程存在問(wèn)題,也應(yīng)該有修正制度,否則就容易陷入僵化的境地.
具體到軟件的研發(fā),要制定的流程就太多了,比如:新功能模塊的開(kāi)發(fā)流程、風(fēng)險(xiǎn)問(wèn)題的處理流程、大Bug的處理流程,小Bug的處理流程、資源沖突的處理流程(比如碼流儀)hh.
以新功能模塊的開(kāi)發(fā)流程為例,業(yè)界也有許多理論:RUP、XP、瀑布、迭代、原型、敏捷方法hh.但對(duì)實(shí)踐來(lái)說(shuō),都比較粗,在具體的實(shí)施中,必須進(jìn)行一定的修整.筆者在分析研究了XP方法后,針對(duì)實(shí)際情況,提出如下流程:
目的:
a. 提高代碼質(zhì)量,減少Bugs,降低后期維護(hù)量
b. 提高知識(shí)共享度與組員技能水平
c. 降低人員流動(dòng)帶來(lái)的風(fēng)險(xiǎn),如出差、調(diào)離、辭職
d. 形成必需文檔
e. 加強(qiáng)反饋與溝通
步驟:
1. 當(dāng)新的需求來(lái)到的時(shí)候,開(kāi)始本流程
需求:
2. 由Team Leader或者其授權(quán)者瀏覽、了解需求,做需求初步評(píng)價(jià):
a) 如其中存在平臺(tái)性技術(shù)難點(diǎn),則走預(yù)研攻關(guān)流程,不走本流程
b) 填寫(xiě)需求評(píng)估文檔:可行性、大致進(jìn)度、開(kāi)發(fā)要求,要點(diǎn)
3. 負(fù)責(zé)人組織需求分析討論會(huì)議
a) 討論方式:全體、局部與微型會(huì)議(微型會(huì)議是指最相關(guān)的3人左右,做在座位上開(kāi)會(huì),推薦)
b) 安排一個(gè)開(kāi)發(fā)者與一個(gè)審查者(負(fù)責(zé)人可為其中之一),要求審查者的經(jīng)驗(yàn)、技能較高或者相當(dāng)開(kāi)發(fā)者
c) 如有必要,則拆分為較小的模塊,對(duì)每個(gè)小模塊進(jìn)行后面的步驟
4. 開(kāi)發(fā)者對(duì)需求做進(jìn)一步深入了解,將其中抽象、不明的東西具體化,出需求草案,草案中可帶有疑問(wèn).
5. 審查者獨(dú)立審查需求草案
6. 審查者與開(kāi)發(fā)者共同討論需求草案
a) 2人約個(gè)時(shí)間,開(kāi)發(fā)者協(xié)助審查者審查
b) 指出其中需求不明之處
c) 討論其中的疑問(wèn),如不明確,則咨詢(xún)需求提出者
d) 盡量討論現(xiàn)場(chǎng)一次性確定疑問(wèn),以避免過(guò)程反復(fù)
7. 開(kāi)發(fā)者根據(jù)審查結(jié)果修正草案,之后將正式需求發(fā)送給Team L