項(xiàng)目管理實(shí)踐總結(jié):這可能是最為詳細(xì)、并被驗(yàn)證過的敏捷項(xiàng)目管理實(shí)踐總結(jié)了
編輯導(dǎo)讀:一個(gè)大型項(xiàng)目從立項(xiàng)到完成會(huì)需要多方合作,涉及到很多人員的調(diào)動(dòng),工作也會(huì)比較的繁瑣。作為一個(gè)產(chǎn)品經(jīng)理,如何做好項(xiàng)目管理呢?本文作者根據(jù)自身工作經(jīng)歷,總結(jié)了一些經(jīng)驗(yàn),和大家分享。
19年到21年,2年多的時(shí)間我和團(tuán)隊(duì)一起搭建了一套BI平臺(tái)。我們完成了80多個(gè)迭代,1300多個(gè)特性,85%以上的迭代未出現(xiàn)任何延期,2年半時(shí)間保持穩(wěn)定輸出2周一個(gè)迭代。團(tuán)隊(duì)在敏捷項(xiàng)目迭代中成為標(biāo)桿。
這其中,一套科學(xué)有效的敏捷項(xiàng)目管理方法發(fā)揮了至關(guān)重要的作用。
項(xiàng)目管理貫穿于產(chǎn)品的全流程管理,因此我把他分為了5個(gè)模塊,分別為需求管理、需求評(píng)審、研發(fā)前準(zhǔn)備、研發(fā)中、上線后的回顧。接下來,我將從這5個(gè)模塊分別描述我們是如何進(jìn)行高效管理的。
一、 需求管理
產(chǎn)品的需求總是源源不斷的,有的來自于用戶直接的需求反饋,有的則來自于公司對(duì)產(chǎn)品的宏觀愿景。這些需求我們究竟要如何進(jìn)行管理呢?
1. 需求池管理
1)從目標(biāo)出發(fā)對(duì)需求池進(jìn)行管理
需求池的需求總是超出我們的預(yù)期的,需求不是做的越多越好,需求的目標(biāo)也不是為了把需求做完。需求的管理指的是在有限的團(tuán)隊(duì)和有限的時(shí)間范圍下,找到優(yōu)先級(jí)更高的需求,解決用戶最關(guān)心的問題,滿足用戶的最大價(jià)值和公司的最大價(jià)值。
所以確定產(chǎn)品的愿景和目標(biāo),從愿景、目標(biāo)出發(fā)對(duì)需求池進(jìn)行管理而不是從功能出發(fā)進(jìn)行管理。
對(duì)于目標(biāo)的確定,首先,我們需要明確產(chǎn)品的愿景,再在產(chǎn)品整體愿景的基礎(chǔ)上確定產(chǎn)品年度目標(biāo),產(chǎn)品的roadmap,再將目標(biāo)拆解為季度和月度目標(biāo),進(jìn)行細(xì)化。一方面通過目標(biāo)確定當(dāng)年的需求方向,并因此能夠標(biāo)記出池需求的優(yōu)先級(jí),另一方面,拆解到月度范圍的目標(biāo)能讓我們有條不紊穩(wěn)步前進(jìn)。
但同時(shí),雖然我們以目標(biāo)為導(dǎo)向,大目標(biāo)一般是穩(wěn)定的,但小周期的目標(biāo)實(shí)際上是允許靈活變動(dòng)的,需要根據(jù)用戶以及當(dāng)前環(huán)境的變化做出靈活的應(yīng)對(duì)。
目標(biāo)管理是為了讓團(tuán)隊(duì)和項(xiàng)目有清晰的指引和前進(jìn)的動(dòng)力,但目標(biāo)管理本身并不是我們追求的目標(biāo),所以千萬不要覺得目標(biāo)是不可改動(dòng)的,就像敏捷宣言中所說:響應(yīng)變化高于遵循計(jì)劃才是正確的處理方式。我們需要根據(jù)客戶的影響度適當(dāng)對(duì)目標(biāo)進(jìn)行調(diào)整,同時(shí)也對(duì)需求優(yōu)先級(jí)進(jìn)行調(diào)整。
2)和用戶一起建立溝通和閉環(huán)機(jī)制
需求池的管理不僅僅能夠?qū)Ξa(chǎn)品本身的迭代進(jìn)行管理,同時(shí)也能夠和用戶之間建立關(guān)系橋梁。
一份清晰的需求清單表,應(yīng)該包括需求的描述、提出人、提出時(shí)間、產(chǎn)品評(píng)估結(jié)果,當(dāng)前進(jìn)度,優(yōu)先級(jí)等字段,這樣就能夠輔助產(chǎn)品對(duì)需求進(jìn)行管理。
同時(shí),如果需求和業(yè)務(wù)方密切合作,也應(yīng)該通過將需求清單共享給用戶查看,不斷更新需求池狀態(tài),讓用戶和項(xiàng)目組同學(xué)知道對(duì)于用戶需求的響應(yīng)狀況,建立積極的用戶關(guān)系,和用戶一起建立起溝通和閉環(huán)機(jī)制。
2. 迭代需求管理
當(dāng)我們從需求池?fù)瞥鲂枨筮M(jìn)入迭代完成原型后,并不是馬上進(jìn)入需求評(píng)審階段。
如果需求較為復(fù)雜或產(chǎn)品無法判斷需求的數(shù)量以及方案的可行性,需要產(chǎn)品在需求評(píng)審前拉起主要研發(fā)同學(xué)進(jìn)行小范圍討論,目的是確定需求方案的可落地性和迭代需求范圍。
為什么要確定迭代需求范圍呢?因?yàn)樵诿艚蓍_發(fā)中,迭代的周期是穩(wěn)定的,比如2周一個(gè)迭代,通過穩(wěn)定而較短的開發(fā)周期,一方面保證了需求響應(yīng)的及時(shí)性,也符合MVP快速市場(chǎng)驗(yàn)證的理念。同時(shí),通過穩(wěn)定的開發(fā)周期,能夠提高研發(fā)同學(xué)對(duì)需求評(píng)估的精準(zhǔn)度(迭代周期穩(wěn)定,需求數(shù)量較為穩(wěn)定,通過越多的相似規(guī)模的需求實(shí)際開發(fā)時(shí)間作為樣本,對(duì)開發(fā)工作量的評(píng)估就會(huì)越來越接近實(shí)際值),以及積極的項(xiàng)目節(jié)奏氛圍。當(dāng)然,如果不是敏捷開發(fā),可能就另當(dāng)別論了。
所以,我們進(jìn)行迭代范圍的確定,也就是在正式需求評(píng)審前,將優(yōu)先級(jí)較低的需求砍掉,以免浪費(fèi)大家的時(shí)間。
二、 需求評(píng)審
1. 團(tuán)隊(duì)成員了解需求背景了嗎?
現(xiàn)在,我們來做一個(gè)測(cè)試,問問你的團(tuán)隊(duì),項(xiàng)目的定位和愿景是什么,有多少人能回答上來?你的成員們真的知道迭代為什么要規(guī)劃這些功能嗎?他們知道目標(biāo)用戶是誰、場(chǎng)景是什么、解決了用戶什么痛點(diǎn)嗎?
答案是不是有些許扎心?那我有理由懷疑你沒有做好真正的需求評(píng)審。
一個(gè)好的需求評(píng)審,需要告訴團(tuán)隊(duì)項(xiàng)目的目標(biāo),迭代的目標(biāo),同時(shí),在進(jìn)行需求講解時(shí),不僅僅需要闡述功能的流程,還需要闡述需求的背景。即什么用戶在什么場(chǎng)景下遇到了什么問題,我們提供的這個(gè)功能解決了他什么問題,滿足了用戶什么需求。
在這樣的前提下,研發(fā)同學(xué)才會(huì)知道產(chǎn)品建設(shè)的意義和價(jià)值,也才會(huì)對(duì)產(chǎn)品有認(rèn)同感,而不是覺得自己只是來開發(fā)個(gè)功能而已。也只有研發(fā)同學(xué)對(duì)產(chǎn)品有認(rèn)同感之后,才會(huì)有主人翁意識(shí),并去和產(chǎn)品一起思考如何做的更好,現(xiàn)有的方案是不是最優(yōu)的。
記住,一個(gè)好的團(tuán)隊(duì)一定是有目標(biāo)有夢(mèng)想的,咸魚一樣的團(tuán)隊(duì)是做不出極致的產(chǎn)品的。而這份目標(biāo)和夢(mèng)想的植入需要產(chǎn)品在需求評(píng)審階段就去努力。
此刻,你還以為需求評(píng)審只是為了把要做的功能流程講清楚嗎?
2. 需求的優(yōu)先級(jí)
除了講清楚需求的背景,在完成需求評(píng)審后,我們還需要對(duì)需求優(yōu)先級(jí)進(jìn)行評(píng)估。
一方面保證研發(fā)順序按照優(yōu)先級(jí)進(jìn)行,保證高優(yōu)先級(jí)需求的交付。另一方,低優(yōu)先級(jí)但可能完不成的需求,作為迭代沖刺目標(biāo),是可以根據(jù)完成情況移入下迭代,而不影響迭代的。
這里,我們的方法是,除了高中低的優(yōu)先級(jí)排序,我們還會(huì)把這些需求標(biāo)上阿拉伯?dāng)?shù)字,表明各需求整體的優(yōu)先級(jí)排序。
3. 將確定的需求錄入到相應(yīng)的項(xiàng)目管理系統(tǒng)
需求的線上管理我們之前使用jira,市面上也有一些其他的項(xiàng)目管理工具,比如騰訊的tapd 以及很久前我用過一個(gè)叫trello的工具。如果沒有,用excel 和便利貼進(jìn)行管理也是可以的。
需求的拆分,粒度是比較難的一件事兒。
從用戶的角度來說,大小規(guī)模合適的需求,是一個(gè)可以滿足某一需要達(dá)成某一業(yè)務(wù)目標(biāo)的故事,比如刪除一條任務(wù),就是能夠獨(dú)立作為一個(gè)需求單的需求。而從項(xiàng)目組研發(fā)的角度上來說,一個(gè)大小規(guī)模適當(dāng)?shù)男枨笫强梢栽趲滋鞎r(shí)間內(nèi)完成開發(fā)和測(cè)試的故事,因此,同樣刪除也是滿足的。
通過拆分這樣的小模塊,對(duì)于開發(fā)、測(cè)試和最終的發(fā)布上線都是大有裨益的,因?yàn)閷⑿枨髣澐譃檫@樣的小故事,團(tuán)隊(duì)就可以并行開發(fā)各個(gè)模塊,而無需彼此等待。也就不會(huì)出現(xiàn)需求開發(fā)堆積到后期的風(fēng)險(xiǎn)。因此我們建議將需求拆分為可以在兩三天時(shí)間內(nèi)完成開發(fā)和測(cè)試的模塊。
拆分完需求后,就需要把需求錄入線上系統(tǒng)。在需求錄入時(shí),需求的標(biāo)題需要簡(jiǎn)單直接,我們一般會(huì)采用的描述如下:
除此還需要標(biāo)注需求的優(yōu)先級(jí),需求負(fù)責(zé)人、故事點(diǎn)、開始時(shí)間、結(jié)束時(shí)間等信息。完整和簡(jiǎn)潔的信息有助于后期進(jìn)行故事墻管理。
三、 研發(fā)前準(zhǔn)備
如果需求評(píng)審結(jié)束就立即進(jìn)入研發(fā),極大可能會(huì)出現(xiàn)事倍功半和混亂的局面,所以,研發(fā)前的準(zhǔn)備工作是不可忽略的。那研發(fā)前有哪些準(zhǔn)備工作呢?
1. 技術(shù)評(píng)審會(huì)
技術(shù)評(píng)審主要由研發(fā)側(cè)發(fā)起和負(fù)責(zé),目的是前后端同學(xué)對(duì)各需求所需要的技術(shù)能力以及風(fēng)險(xiǎn)進(jìn)行對(duì)齊,尤其是當(dāng)功能復(fù)雜,對(duì)應(yīng)技術(shù)復(fù)雜的時(shí)候,充分的技術(shù)評(píng)審能夠規(guī)避迭代研發(fā)過程中可能出現(xiàn)的技術(shù)風(fēng)險(xiǎn),確保迭代進(jìn)度和質(zhì)量。
一般這時(shí)候,研發(fā)負(fù)責(zé)人需要和大家一起確定每一個(gè)需求的前后端研發(fā)同學(xué)。前后端對(duì)各自的需求進(jìn)行闡述,后端主要是接口文檔的定義(格式和地址待定)。當(dāng)項(xiàng)目需要引入新組件、新技術(shù)時(shí)還需要進(jìn)行技術(shù)預(yù)演,去熟悉新的技術(shù),評(píng)估怎么整合到系統(tǒng)、有沒有風(fēng)險(xiǎn)等。
2. 拆分研發(fā)任務(wù)和確定需求開發(fā)節(jié)奏
完成技術(shù)評(píng)審會(huì)之后,研發(fā)同學(xué)對(duì)于每一個(gè)需求的完成需要做哪些工作以及怎么做也就清楚了。這個(gè)時(shí)候就可以開始進(jìn)行研發(fā)任務(wù)的拆分了。
研發(fā)任務(wù)的拆分是為了對(duì)于每一個(gè)需求的跟進(jìn)提供切實(shí)可依的依據(jù),并在后期的項(xiàng)目故事板進(jìn)行展示,輔助項(xiàng)目能夠有序穩(wěn)步前進(jìn),而不是讓項(xiàng)目管理進(jìn)入無序的黑盒子。因此,在任務(wù)拆分的時(shí)候需要遵循幾個(gè)點(diǎn):
- 研發(fā)任務(wù)需要分別拆分前端、后端研發(fā)任務(wù),分別確定負(fù)責(zé)人進(jìn)行跟進(jìn)。
- 研發(fā)任務(wù)的粒度盡量小于3 天的開發(fā)周期,否則很難跟進(jìn)和評(píng)估風(fēng)險(xiǎn)。
- 研發(fā)任務(wù)需要標(biāo)記owner、研發(fā)開始時(shí)間、研發(fā)結(jié)束時(shí)間、故事點(diǎn)信息。
基于以上,我們又能對(duì)需求進(jìn)行一些信息的補(bǔ)充,包括:
- 根據(jù)單個(gè)需求下所屬的全部研發(fā)任務(wù)的開始時(shí)間和結(jié)束時(shí)間確定需求的提測(cè)時(shí)間,即需求的研發(fā)開始時(shí)間和結(jié)束時(shí)間。
- 確定需求的研發(fā)owner ,研發(fā)owner 對(duì)需求的開發(fā)周期負(fù)責(zé)。包括確保需求按時(shí)進(jìn)入聯(lián)調(diào),按時(shí)完成聯(lián)調(diào),按時(shí)提測(cè)。
3. 需求反講和計(jì)劃會(huì)
1)需求反講
我們經(jīng)常會(huì)聽到研發(fā)和產(chǎn)品經(jīng)理撕的事情,有些時(shí)候我們也會(huì)聽到因?yàn)榍捌谛枨鬁贤ú灰恢拢瑢?dǎo)致研發(fā)結(jié)果和產(chǎn)品需求出現(xiàn)偏差的事情。為了規(guī)避這樣的問題,我們加入了需求反講環(huán)節(jié)。
所謂的需求反講就是讓研發(fā)同學(xué)來講需求,產(chǎn)品同學(xué)聽需求。在這個(gè)過程中,需求的前后端研發(fā)負(fù)責(zé)人會(huì)先講一講整體的功能流程,同時(shí)會(huì)闡述自己需要準(zhǔn)備什么。如果信息不對(duì)稱能夠很快發(fā)現(xiàn)。當(dāng)然,如果需求很簡(jiǎn)單,也可以忽略這一環(huán)節(jié)。
2)計(jì)劃會(huì)
計(jì)劃會(huì)的目的主要是和大家一起確定迭代節(jié)奏。包括每一項(xiàng)需求的開始時(shí)間和開發(fā)結(jié)束時(shí)間(包括聯(lián)調(diào),也就是開發(fā)結(jié)束就應(yīng)該進(jìn)入測(cè)試),并由此確定全面提測(cè)時(shí)間,并由測(cè)試同學(xué)確定測(cè)試完成封版的時(shí)間以及發(fā)布的時(shí)間。
如果前面的任務(wù)拆分都做的很好,每一項(xiàng)任務(wù)前后端都評(píng)估了時(shí)間,同時(shí)大家對(duì)需求理解沒有問題,在這樣的前提下,計(jì)劃會(huì)其實(shí)是很快的。
如果考慮會(huì)議太多,其實(shí)可以將計(jì)劃會(huì)和需求反講放到一起進(jìn)行。
計(jì)劃會(huì)結(jié)束后,整體迭代中的需求節(jié)奏,迭代發(fā)布節(jié)奏基本也就確定了。這時(shí)候作為項(xiàng)目經(jīng)理,可以整理郵件,將迭代目標(biāo),計(jì)劃發(fā)送知會(huì)全員。
4. 完成故事墻
故事墻顧名思義是一面墻或者白板,線上或線下都可以。而墻上則是迭代中的用戶故事以及研發(fā)任務(wù),項(xiàng)目管理中通過把這些故事和任務(wù)貼到故事墻上并根據(jù)進(jìn)度挪動(dòng),從而實(shí)現(xiàn)項(xiàng)目中的進(jìn)度管理。
1)故事墻的結(jié)構(gòu)
頂部是項(xiàng)目進(jìn)度的敘事主線,通過一個(gè)個(gè)的活動(dòng)階段將故事和任務(wù)組織起來。并通過對(duì)正常狀態(tài)和風(fēng)險(xiǎn)項(xiàng)的細(xì)分,有效的反映出故事和人物的變化性,讓項(xiàng)目成員對(duì)項(xiàng)目進(jìn)度能夠有效把控。
迭代目標(biāo)的展示是為了讓項(xiàng)目組同學(xué)目標(biāo)一致前進(jìn),也能明白大家做的事情的意義和價(jià)值。
我們把所有規(guī)劃到迭代中的需求以及對(duì)應(yīng)的研發(fā)任務(wù)放到規(guī)劃中,分兩列放置。
當(dāng)需求下的任務(wù)啟動(dòng)開發(fā)后,就可以將任務(wù)拖動(dòng)到實(shí)現(xiàn)中,當(dāng)任務(wù)狀態(tài)進(jìn)入聯(lián)調(diào)中時(shí),我們就需要把需求和任務(wù)一起拖動(dòng)到聯(lián)調(diào)中狀態(tài)。為了方便查看,進(jìn)入聯(lián)調(diào)后會(huì)建議大家把需求和對(duì)應(yīng)任務(wù)放到一起開始進(jìn)行拖動(dòng),如果你的故事墻是便簽紙制作,這個(gè)時(shí)候你可以把需求和任務(wù)疊到一起進(jìn)行拖動(dòng)。
接著需求進(jìn)入到測(cè)試、待發(fā)布的流程,并最終隨版本全部發(fā)布上線。
在實(shí)際操作中我們發(fā)現(xiàn)在進(jìn)程中部分需求可能出現(xiàn)風(fēng)險(xiǎn)延遲,因此我們?cè)诳v向上又將需求劃分為正常進(jìn)度和風(fēng)險(xiǎn)項(xiàng),一旦需求或任務(wù)出現(xiàn)風(fēng)險(xiǎn)就需要將需求和任務(wù)拖入到風(fēng)險(xiǎn)項(xiàng)一行,解除后可回到正常一行。
當(dāng)然,根據(jù)需要你也可以增加更多的狀態(tài)欄來輔助管理,比如我們之前的故事墻是這樣的。敏捷教練甚至?xí)陧敳看蛴〕龃蠹业念^像,來讓大家有更明確的團(tuán)隊(duì)歸屬感。
2)故事卡片
故事墻由一個(gè)個(gè)的需求和任務(wù)卡片組成,對(duì)于故事卡片來講,需要包括如下內(nèi)容:故事標(biāo)題、故事描述、優(yōu)先級(jí)、負(fù)責(zé)人、開始時(shí)間、結(jié)束時(shí)間、狀態(tài)
而對(duì)于任務(wù)來說則需要包括:
任務(wù)標(biāo)題,依賴的需求、負(fù)責(zé)人、開始時(shí)間、結(jié)束時(shí)間、狀態(tài)、故事點(diǎn)信息。
通過這些信息,我們能夠清晰的看到每一天應(yīng)該做哪些需求,哪些需求應(yīng)該進(jìn)入測(cè)試,哪些需求出現(xiàn)延期,需求的負(fù)責(zé)人是誰。從而對(duì)需求的完成進(jìn)度,項(xiàng)目的節(jié)奏能夠有較強(qiáng)的把控力。
四、 研發(fā)階段的項(xiàng)目推進(jìn)
1. 站立會(huì)
研發(fā)正式開始后,為了正常推進(jìn)項(xiàng)目進(jìn)度,我們會(huì)進(jìn)行每日站立會(huì)。
站立會(huì)階段主要需要明確每一個(gè)成員的進(jìn)度和計(jì)劃,以及同步風(fēng)險(xiǎn)。即項(xiàng)目成員昨天完成了什么,今日要做什么,當(dāng)前是否有風(fēng)險(xiǎn)項(xiàng)或項(xiàng)目阻塞,每人不會(huì)超過1分鐘。
站立會(huì)上若遇到需要解決的問題,我們會(huì)督促大家會(huì)議結(jié)束后立馬小范圍拉上相關(guān)人員討論解決,而不會(huì)在站立會(huì)上直接解決,因?yàn)槿绻谡玖?huì)上解決,會(huì)讓整個(gè)站立會(huì)的時(shí)間拉的特別長,耽誤其他同學(xué)的時(shí)間。
成員在同步的同時(shí),需要同步拖動(dòng)卡片的位置改變卡片狀態(tài)。這樣,站立會(huì)結(jié)束,目前各個(gè)需求以及任務(wù)對(duì)應(yīng)的開發(fā)狀態(tài)和進(jìn)度也就一目了然了。
2. 需求的驗(yàn)收
隨著需求不斷被交付,產(chǎn)品逐漸進(jìn)入測(cè)試階段。在這個(gè)過程中,除了研發(fā)要做好開發(fā)和自測(cè),測(cè)試同學(xué)要做好功能測(cè)試,也需要產(chǎn)品經(jīng)理在各個(gè)環(huán)節(jié)深度參與,把控質(zhì)量。
為了從源頭上阻斷功能開發(fā)和產(chǎn)品理解不一致,我們一般會(huì)在研發(fā)完成聯(lián)調(diào)后先讓產(chǎn)品經(jīng)理先做功能測(cè)試,這個(gè)過程中主要看功能主流程是否跑通,是否和需求開發(fā)一致。產(chǎn)品測(cè)試通過,則可轉(zhuǎn)測(cè)試狀態(tài),并知會(huì)測(cè)試同學(xué)開始功能測(cè)試。
為了保證各流轉(zhuǎn)環(huán)節(jié)的無縫銜接。我們采用的方式是群知會(huì),比如研發(fā)完成聯(lián)調(diào)后群里@產(chǎn)品進(jìn)行開發(fā)環(huán)境測(cè)試,產(chǎn)品測(cè)試通過后群里立馬@測(cè)試同學(xué)可開始測(cè)試,以保證流程的順暢。雖然我們通過jira或者郵件都可以實(shí)現(xiàn)轉(zhuǎn)單以及通知,但從溝通的實(shí)效性以及流程的完整性上,我們更建議通過群通知方式進(jìn)行。
如果因?yàn)殚_發(fā)群消息太多會(huì)淹沒消息,甚至可以單獨(dú)開一個(gè)測(cè)試群,專門周知測(cè)試流程周轉(zhuǎn)。
測(cè)試同學(xué)在收到測(cè)試單以后開始進(jìn)行測(cè)試,并將發(fā)現(xiàn)的問題和對(duì)應(yīng)研發(fā)同學(xué)溝通后提單bug。修改并測(cè)試完成后將需求改為待發(fā)布狀態(tài)。
進(jìn)入全面提測(cè)階段后,還需要邀請(qǐng)UED同學(xué)進(jìn)行交互、視覺還原度測(cè)試,并及時(shí)將發(fā)現(xiàn)的問題反饋給項(xiàng)目組。
3. 迭代發(fā)布
迭代發(fā)布代表著產(chǎn)品研發(fā)完成終于可以上線了,但一旦功能存在問題,上線就會(huì)給用戶造成較為糟糕的體驗(yàn)和印象,因此迭代正式發(fā)布前的驗(yàn)收也至關(guān)重要。
一般情況下,測(cè)試同學(xué)按照封版時(shí)間完成測(cè)試后發(fā)出測(cè)試驗(yàn)收郵件,產(chǎn)品在收到郵件后開始進(jìn)行全局產(chǎn)品驗(yàn)收。驗(yàn)收無誤則可知會(huì)大家產(chǎn)品驗(yàn)收通過,進(jìn)入發(fā)布狀態(tài)。
此時(shí),研發(fā)同學(xué)需要召集運(yùn)維同學(xué)進(jìn)行發(fā)布評(píng)審,各研發(fā)同學(xué)報(bào)備準(zhǔn)備無誤,各項(xiàng)準(zhǔn)備就緒,運(yùn)維同學(xué)確定發(fā)布的具體時(shí)間點(diǎn),即可發(fā)布。
五、上線后的回顧會(huì)
在項(xiàng)目迭代中,并不是產(chǎn)品上線后就大功告成可以撒手不管了,產(chǎn)品上線后我們需要去進(jìn)行回顧和持續(xù)跟進(jìn),回顧的目的不是為了糾錯(cuò),還是為了從過程中不斷的學(xué)習(xí)和進(jìn)步。
1. 關(guān)注上線后產(chǎn)品的質(zhì)量
首先,需要關(guān)注產(chǎn)品的質(zhì)量和用戶反饋,第一時(shí)間去觀察用戶的行為和反饋,并將用戶反饋納入需求池進(jìn)行管理。
同時(shí),也需要通過指標(biāo)客觀進(jìn)行觀測(cè),看看用戶對(duì)新功能的使用情況。
2. 回顧和關(guān)注工作計(jì)劃是否合理。
工作計(jì)劃的合理有序是保證項(xiàng)目推進(jìn)有序的必要條件,如果不合理是哪里不合理,就需要考慮如何在下一個(gè)迭代中進(jìn)行調(diào)整。針對(duì)這一塊我們可以看的包括需求燃盡圖、迭代需求完成率、需求變更率等報(bào)表。
需求燃盡圖反映了在迭代下需求完成的趨勢(shì)。正常情況下,需求完成數(shù)是勻速上升的,如果出現(xiàn)前期上升緩慢,則表明需求極有可能堆積在后期交付,故事和任務(wù)可能都拆的過大,項(xiàng)目存在極大風(fēng)險(xiǎn)。若前期上升速度過快,則可能是需求評(píng)估不準(zhǔn),導(dǎo)致需求提前完成,或前期堆積的都是小需求。
迭代完成率指的是,迭代實(shí)際完成的需求數(shù)或故事點(diǎn)數(shù)占規(guī)劃需求數(shù)或故事點(diǎn)數(shù)的比率。度量研發(fā)團(tuán)隊(duì)在核定的時(shí)間內(nèi)穩(wěn)定交付需求的能力。
需求變更率則主要指由于前期考慮不周導(dǎo)致需求的大變更,或研發(fā)中臨時(shí)撤換需求。在客戶需求變更或特殊情況下,我們?cè)试S一定情況的需求變更,擁抱變化,但同時(shí),頻繁的需求變更也會(huì)對(duì)研發(fā)團(tuán)隊(duì)帶來交付和資源上的壓力,因此并不建議這樣的操作。
同時(shí),由于前期需求考慮不充分導(dǎo)致的頻繁需求變更,還會(huì)讓研發(fā)團(tuán)隊(duì)對(duì)產(chǎn)品產(chǎn)生不信任感,降低項(xiàng)目的凝聚力。
3. 關(guān)注過程是否有序
比如開發(fā)的節(jié)奏是否根據(jù)大家估算的開始時(shí)間、結(jié)束時(shí)間進(jìn)行推進(jìn),是否及時(shí)提測(cè),整體需求的延遲交付率是怎樣的等等。
產(chǎn)品從需求到上線,整體是多方協(xié)作共同的結(jié)果,如果一方在過程中無序,就會(huì)形成多米諾連鎖反應(yīng),造成項(xiàng)目的混亂。經(jīng)常看到有些項(xiàng)目的現(xiàn)象是,研發(fā)團(tuán)隊(duì)延遲提測(cè),壓縮測(cè)試時(shí)間,導(dǎo)致測(cè)試不充分情況下上線,測(cè)試不充分又導(dǎo)致產(chǎn)品問題沒有被發(fā)現(xiàn)而影響用戶體驗(yàn),最終,用戶體驗(yàn)受損,產(chǎn)品品牌受損,造成不可挽回的損失。
六、誰對(duì)項(xiàng)目管理負(fù)責(zé)
項(xiàng)目管理是一件繁瑣而專業(yè)的工作,一般稍微大型的公司和團(tuán)隊(duì)都會(huì)配有專業(yè)的項(xiàng)目經(jīng)理,如果是敏捷開發(fā)還會(huì)配置敏捷教練。但無論如何,項(xiàng)目管理一定不是某一個(gè)人的事情,而是需要團(tuán)隊(duì)一起努力的結(jié)果。
一方面,產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理需要進(jìn)行配合管理,同時(shí),研發(fā)端也需要有一個(gè)研發(fā)經(jīng)理能夠協(xié)助產(chǎn)品和項(xiàng)目經(jīng)理一起進(jìn)行管理。
產(chǎn)品經(jīng)理對(duì)產(chǎn)品全流程最終交付負(fù)責(zé),因此,產(chǎn)品經(jīng)理其實(shí)需要時(shí)刻關(guān)注團(tuán)隊(duì),同時(shí)配合項(xiàng)目經(jīng)理的一切推進(jìn)工作。
項(xiàng)目經(jīng)理需要積極推動(dòng)項(xiàng)目有序進(jìn)行,遇到阻礙需要及時(shí)同步產(chǎn)品,督促或幫助團(tuán)隊(duì)解決問題。甚至在遇到資源問題時(shí)項(xiàng)目經(jīng)理也需要幫助進(jìn)行協(xié)調(diào),始終為團(tuán)隊(duì)的穩(wěn)定產(chǎn)出,凝聚力而努力。
研發(fā)經(jīng)理作為研發(fā)端的負(fù)責(zé)人,需要對(duì)研發(fā)過程及交付負(fù)責(zé),因此需要帶領(lǐng)研發(fā)團(tuán)隊(duì)一起完成各節(jié)點(diǎn)事項(xiàng),配合項(xiàng)目經(jīng)理工作。否則也可能導(dǎo)致研發(fā)側(cè)的無序。
而因每個(gè)團(tuán)隊(duì)特點(diǎn)和配置都不一樣,為了明確成員的角色和職責(zé),便于管理的順利進(jìn)行。所以需要公開明確團(tuán)隊(duì)各角色及職責(zé)范圍,并作為項(xiàng)目約定之一執(zhí)行下去。
七、小結(jié)
根據(jù)我們上面的整體的流程總結(jié),可以用一張流程圖做一下整體的描述,供大家參考。每一個(gè)環(huán)節(jié)我已經(jīng)在上面分開細(xì)講。
主體流程是穩(wěn)定的,但我們始終要記住,流程的制定是為了服務(wù)于項(xiàng)目、服務(wù)于人,因此,并沒有一成不變的流程,也沒有萬能的解藥,而需要我們?cè)陧?xiàng)目管理中不斷的調(diào)整、優(yōu)化、回顧和學(xué)習(xí),并摸索出一套適合自己項(xiàng)目的管理方法。
同時(shí),流程是死的,人是活的。我們始終要學(xué)會(huì)擁抱變化,高效靈活的溝通永遠(yuǎn)高于死板的流程,應(yīng)變和解決業(yè)務(wù)的態(tài)度永遠(yuǎn)高于對(duì)流程的遵守。時(shí)時(shí)刻刻為用戶、為產(chǎn)品著想,發(fā)揮出人的能動(dòng)性,是我們始終要去倡導(dǎo)的。
最后,特別感謝一下這個(gè)項(xiàng)目中我們最可愛的敏捷教練萍姐姐,為我們的敏捷開發(fā)保駕護(hù)航,她同時(shí)也指導(dǎo)了我的總結(jié)文章;感謝原研發(fā)負(fù)責(zé)人彪哥,以產(chǎn)品結(jié)果為導(dǎo)向,帶領(lǐng)研發(fā)的兄弟們團(tuán)結(jié)一致,才讓我們的項(xiàng)目組更加團(tuán)結(jié)產(chǎn)品做的更好;也感謝團(tuán)隊(duì)的 每一個(gè)小伙伴,每一個(gè)人都是積極、努力、富有主人翁意識(shí)的配合我們工作,才讓我們的項(xiàng)目推進(jìn)更加有序。
感謝每一個(gè)小伙伴的認(rèn)真、努力和團(tuán)結(jié),讓我有一段愉快的旅程。
本文由 @糖糖是老壇酸菜女王 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。