一. 敏捷與Scrum起步

1.1 敏捷起源

相比于瀑布模型的“一次把事情做完，統(tǒng)計(jì)交付”，敏捷方法是多次把事情做完的一種增量交付過(guò)程。敏捷方法有自己的特點(diǎn)。擁抱變化，適應(yīng)變化但發(fā)布周期里一般不接受需求變化。期待變化，對(duì)市場(chǎng)需求和市場(chǎng)趨勢(shì)變化靈活響應(yīng)。用戶的反饋，即能不能為用戶帶來(lái)價(jià)值。團(tuán)隊(duì)文化和氛圍建立使得開(kāi)發(fā)團(tuán)隊(duì)更有效率。唯快不破，輕文檔且頻繁發(fā)布。承諾導(dǎo)向，按承諾交付需求。

敏捷方法的基本原理是項(xiàng)目開(kāi)發(fā)中的細(xì)節(jié)無(wú)法完全提前想明白，世界變化太快，價(jià)值的高低會(huì)不斷變化，不確定性太多，用戶自己都不知道自己想要什么。因此我們不大可能在一開(kāi)始就能面面俱到全部想清楚，敏捷方法是一個(gè)漸進(jìn)明晰的過(guò)程，保持開(kāi)放透明，更高效溝通。

敏捷方法工作方式：小塊東西，有規(guī)律的組裝。按需求和功能拆分5-9人小團(tuán)隊(duì)，2-4周時(shí)間增量交付需求。

1.2 敏捷宣言

互聯(lián)網(wǎng)項(xiàng)目管理的核心是透明及適應(yīng)和調(diào)整。

敏捷宣言：

1. 個(gè)體與交互重于過(guò)程和工具
2. 可用的軟件重于完備的文檔
3. 客戶協(xié)作重于合同談判
4. 響應(yīng)變化重于遵循計(jì)劃

敏捷方法十二原則：

• 原則一：盡早的，持續(xù)的交付有價(jià)值的軟件來(lái)讓客戶滿意
• 原則二：即時(shí)到了開(kāi)發(fā)后期，仍然歡迎改變需求，敏捷用變化來(lái)為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)
• 原則三：經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期
  到幾個(gè)月，交付的時(shí)間間隔越短越好
• 原則四：在整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一
  起工作
• 原則五：圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境
  和支持，并且信任他們能夠完成工作
• 原則六：在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳達(dá)信息的方法，
  就是面對(duì)面的交談
• 原則七：工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)
• 原則八：敏捷過(guò)程提倡可持續(xù)的開(kāi)發(fā)速度。責(zé)任人、開(kāi)發(fā)者和用戶應(yīng)
  該能夠保持一個(gè)長(zhǎng)期的、恒定的開(kāi)發(fā)速度
• 原則九：不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力
• 原則十：簡(jiǎn)單 —— 使未完成的工作最大化的藝術(shù) —— 是根本的
• 原則十一：最好的構(gòu)架、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)
• 原則十二：每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反
  省，然后相應(yīng)地對(duì)自己的行為進(jìn)行調(diào)整

1.3 Scrum流程

Scrum流程中有幾個(gè)重要的角色。首先是產(chǎn)品負(fù)責(zé)人。TA決定產(chǎn)品的范圍/使命/路線圖，定義產(chǎn)品功能，接受和拒絕產(chǎn)品，管理Backlog，決定團(tuán)隊(duì)方向，排列需求優(yōu)先級(jí)，決定發(fā)布日期和驗(yàn)收標(biāo)準(zhǔn)。其次是Scrum Master，TA負(fù)責(zé)引入Scrum價(jià)值觀和實(shí)踐，確保Scrum流程貫徹，幫助，支持，引導(dǎo)團(tuán)隊(duì)，而不是管理和控制，幫助提高生產(chǎn)率，為團(tuán)隊(duì)排除障礙，協(xié)調(diào)對(duì)外的溝通，保證團(tuán)隊(duì)不受干擾。最后是團(tuán)隊(duì)，由5-9人全職成員組成?？缏毮埽洪_(kāi)發(fā)，測(cè)試，UED。團(tuán)隊(duì)負(fù)責(zé)根據(jù)需求進(jìn)行任務(wù)拆分和估算。

1.3.1 Sprint計(jì)劃會(huì)

計(jì)劃會(huì)理解需求，決定這次迭代做什么。參與人有團(tuán)隊(duì)，Scrum Master，Product Owner。議程：討論產(chǎn)品Backlog中高優(yōu)先級(jí)項(xiàng)，團(tuán)隊(duì)挑選部分為該Sprint目標(biāo)并做估算（含概要設(shè)計(jì)）。做任務(wù)拆分需要兩輪，第一輪分解估算：Epic分解為故事，排列優(yōu)先級(jí)，估算（故事點(diǎn)）；第二輪分解估算：故事分解為任務(wù)，理清依賴關(guān)系，并估算（理想時(shí)間）。

1.3.2 每日站會(huì)

10-15分鐘時(shí)間回答三個(gè)問(wèn)題：昨天干了什么，今天要做什么，遇到什么問(wèn)題。站會(huì)時(shí)更新白板：Sprint Backlog，Sprint（TODO，InProgress，Test），DONE。

1.3.3 Sprint評(píng)審會(huì)

向PO和干系人展示產(chǎn)品，只展示100%完成的部分，收集來(lái)自干系人的反饋意見(jiàn)。

1.3.4 回顧會(huì)

持續(xù)評(píng)估，并改進(jìn)和優(yōu)化流程，在開(kāi)放的氛圍中解決問(wèn)題。進(jìn)行總結(jié)：質(zhì)量，成本，效率，經(jīng)驗(yàn)，最佳實(shí)踐。以期在下一次迭代中做的更好。最后完成文檔歸檔工作。

1.4 物件

1.4.1 Product Backlog

Backlog類似傳統(tǒng)的系統(tǒng)需求，涵蓋整個(gè)系統(tǒng)的需求并按優(yōu)先級(jí)排序。PO負(fù)責(zé)準(zhǔn)備和維護(hù)，新需求可以任意時(shí)間添加進(jìn)來(lái)。每個(gè)需求組成部分包含：需求，驗(yàn)收標(biāo)準(zhǔn)（怎樣才算做完了以及要注意的細(xì)節(jié)），估算（故事點(diǎn)），優(yōu)先級(jí)排列（每個(gè)Sprint開(kāi)始時(shí)調(diào)整優(yōu)先級(jí)，可以是絕對(duì)數(shù)值）。

1.4.2 Sprint Backlog

是Product Backlog子集，包含一個(gè)Sprint要完成的工作，它有效避免導(dǎo)致整個(gè)產(chǎn)品推遲或失敗的問(wèn)題出現(xiàn)。Sprint實(shí)施的中間階段一般不能改變，但在有必要的情況下Team可以更改內(nèi)容

1.4.3 燃盡圖

燃盡圖有助于預(yù)測(cè)問(wèn)題，有助于生產(chǎn)力評(píng)價(jià)，有助于對(duì)個(gè)人或總體的任務(wù)進(jìn)行跟蹤。

二. 敏捷應(yīng)用

2.1 第一部分

敏捷宣言可以解讀為一種透明化，適應(yīng)變化，快速反饋，夠用即可和團(tuán)隊(duì)成員充分信任的流程。而項(xiàng)目管理服務(wù)的目的是關(guān)注團(tuán)隊(duì)的痛點(diǎn)和項(xiàng)目的痛點(diǎn)。做一個(gè)團(tuán)隊(duì)需要的工作模式，解決痛點(diǎn)，驅(qū)動(dòng)流程和組織的優(yōu)化

Scrum價(jià)值觀和基礎(chǔ)：

• 誠(chéng)實(shí)
• 開(kāi)放
• 勇氣
• 尊重
• 專注
• 信任
• 授權(quán)

2.1.1 Scrum角色

Product Owner負(fù)責(zé)定義產(chǎn)品的范圍/使命/路線圖，定義產(chǎn)品功能，接受或拒絕產(chǎn)品，負(fù)責(zé)產(chǎn)品backlog，排列優(yōu)先級(jí)，每個(gè)sprint根據(jù)需要調(diào)整功能列表和優(yōu)先級(jí)，決定團(tuán)隊(duì)的方向（不是團(tuán)隊(duì)如何達(dá)到目標(biāo)，也不是團(tuán)隊(duì)的工作速度），PO不做任務(wù)估算。

Scrum Master負(fù)責(zé)引入Scrum價(jià)值觀和實(shí)踐，確保Scrum流程的貫徹，幫助，支持，引導(dǎo)，而不是管理，控制。幫助提高團(tuán)隊(duì)生產(chǎn)率，排除團(tuán)隊(duì)的障礙，協(xié)調(diào)溝通并保護(hù)團(tuán)隊(duì)不受外部干擾。

互聯(lián)網(wǎng)開(kāi)發(fā)過(guò)程需要產(chǎn)品，交互，視覺(jué)，Scrum Team，開(kāi)發(fā)，測(cè)試和運(yùn)維協(xié)作完成。

2.1.2 產(chǎn)品需求列表

產(chǎn)品需求列表定義為一系列按優(yōu)先順序排列的，預(yù)期的產(chǎn)品功能列表。它具有以下屬性：

1. 詳略得當(dāng)：漸進(jìn)明細(xì)，文檔夠用就好
2. 按優(yōu)先級(jí)排序：唯一優(yōu)先級(jí)，從優(yōu)先級(jí)最高的開(kāi)始開(kāi)發(fā)
3. 估算過(guò)：用故事點(diǎn)或者時(shí)間
4. 統(tǒng)一的：一個(gè)產(chǎn)品多個(gè)團(tuán)隊(duì)或多個(gè)產(chǎn)品多個(gè)團(tuán)隊(duì)同樣適用
5. 夠用就好：適合自己的并逐漸演進(jìn)的
6. 定期梳理

2.1.3 需求描述：用戶故事

格式為：作為XXX，我想要XXX，這樣我可以XXX。必須滿足INVEST原則：

1. 獨(dú)立的 Independent
2. 可協(xié)商 Negotiable
3. 有價(jià)值 Valuable
4. 可估算 Estimatable
5. 可測(cè)試 Testable

2.1.4 規(guī)劃估算

要進(jìn)行估算必須理解兩個(gè)要素：團(tuán)隊(duì)每個(gè)迭代的產(chǎn)能和每個(gè)需求的估計(jì)工作量?？梢杂霉适曼c(diǎn)或者時(shí)間。規(guī)劃后發(fā)現(xiàn)做不完怎么辦？可以使用項(xiàng)目鐵三角進(jìn)行評(píng)估，然后優(yōu)先完成20%價(jià)值最大的需求。一次上線對(duì)應(yīng)一個(gè)版本。

2.2 第二部分

2.2.1 Sprint

Sprint迭代沖刺有幾個(gè)特點(diǎn)。首先它是以時(shí)間盒形式組織的，每個(gè)Sprint中的需求強(qiáng)制排定優(yōu)先級(jí)，在整個(gè)開(kāi)發(fā)期間展示進(jìn)度，避免不必要的完美主義，增強(qiáng)可預(yù)測(cè)性，促進(jìn)結(jié)束。采用盡可能短的迭代，短有很多好處：容易做計(jì)劃和承諾，反饋和調(diào)整的次數(shù)多，投入產(chǎn)出比更高，產(chǎn)出的錯(cuò)誤更少，更快的恢復(fù)和重新開(kāi)始。但短也有壞處，如果需求拆分的不好，可能會(huì)讓用戶體驗(yàn)變差，開(kāi)發(fā)團(tuán)隊(duì)可能需要重復(fù)修改，直觀上會(huì)覺(jué)得是一種浪費(fèi)。在Sprint開(kāi)發(fā)期間，我們要凍結(jié)需求來(lái)控制變更，開(kāi)始之后盡可能不允許有任何變更對(duì)沖刺產(chǎn)生影響。這就要求我們啟動(dòng)迭代開(kāi)發(fā)之前要澄清需求：需求是否澄清清楚？還是一時(shí)沒(méi)想清楚的沖動(dòng)？需求的變更還要考慮經(jīng)濟(jì)性：變更后會(huì)產(chǎn)生什么后果？能不能等到下一個(gè)版本？實(shí)際開(kāi)發(fā)中完全凍結(jié)很難，因此一方面我們要留好時(shí)間應(yīng)對(duì)，另一方面需求一定要準(zhǔn)備充分。

2.2.2 Daily Scrum

即每日站會(huì)。它的作用在于同事間互相的壓力，促進(jìn)團(tuán)隊(duì)協(xié)作并關(guān)注在少數(shù)事情上。團(tuán)隊(duì)每天在站會(huì)上做出承諾，提出阻礙的問(wèn)題，這也是一種探針：每日站會(huì)中出現(xiàn)的問(wèn)題往往也會(huì)出現(xiàn)在日常項(xiàng)目實(shí)施過(guò)程中。

有時(shí)候站會(huì)也會(huì)出現(xiàn)一些常見(jiàn)問(wèn)題，比如沒(méi)什么可說(shuō)的，其他人說(shuō)的內(nèi)容我不關(guān)心和時(shí)間太長(zhǎng)等等。要組織大家都喜歡的每日站會(huì)，就要找到團(tuán)隊(duì)關(guān)心的點(diǎn)，并在合適的時(shí)間引入，站會(huì)主要回答好3個(gè)問(wèn)題：昨天干了什么，今天想干什么，有什么問(wèn)題

2.2.3 Sprint Planning

Sprint計(jì)劃會(huì)上主要回答2個(gè)問(wèn)題：接下來(lái)Sprint交付的增量中要包含什么內(nèi)容，以及要如何完成交付增量所需要的工作。計(jì)劃會(huì)還有其他作用，比如儀式感和承諾。計(jì)劃會(huì)中有可能出現(xiàn)團(tuán)隊(duì)不承諾或者少承諾的問(wèn)題，這個(gè)時(shí)候要相信團(tuán)隊(duì)的選擇和判斷，讓團(tuán)隊(duì)說(shuō)明理由，通過(guò)這種方法讓風(fēng)險(xiǎn)和問(wèn)題透明。

如果是多團(tuán)隊(duì)Sprint計(jì)劃會(huì)議，那么每個(gè)團(tuán)隊(duì)時(shí)間錯(cuò)開(kāi)，并保持相同的節(jié)奏，比如同一天的不同時(shí)候。或者多個(gè)團(tuán)隊(duì)一起開(kāi)，解決跨團(tuán)隊(duì)討論的問(wèn)題要立刻找其他團(tuán)隊(duì)討論。

2.2.4 Sprint Review

Sprint總結(jié)會(huì)的作用是反饋，總結(jié)，終結(jié)和調(diào)整。要看經(jīng)濟(jì)性來(lái)決定是否需要召開(kāi)。對(duì)于非開(kāi)發(fā)團(tuán)隊(duì)的Sprint評(píng)審而言，一般需要進(jìn)行需求評(píng)審，交互評(píng)審和視覺(jué)評(píng)審。

2.2.5 Sprint Retrospective

Sprint回顧會(huì)的目的是檢視前一個(gè)Sprint中關(guān)于人，關(guān)系，過(guò)程和工具的情況如何，并找出并加以排序做得好的和潛在需要改進(jìn)的主要方面，同時(shí)制定改進(jìn)Scrum團(tuán)隊(duì)工作方式的計(jì)劃。如果沒(méi)人吐槽，場(chǎng)面很平靜，那么我們的團(tuán)隊(duì)可能需要先建立信任感，建立安全環(huán)境；反過(guò)來(lái)如果吐槽的太多，那么我們需要對(duì)事不對(duì)人。總結(jié)會(huì)是對(duì)產(chǎn)品的回顧，相關(guān)改進(jìn)措施要放入backlog；回顧會(huì)是對(duì)團(tuán)隊(duì)的回顧。

三. 996是萬(wàn)靈丹嗎

3.1 996

996產(chǎn)生的問(wèn)題比較多，首先是團(tuán)隊(duì)效率低下：摸魚(yú)或者周六遲到早退，事情反而做的更慢，也會(huì)使得某些同學(xué)萌生退意。996產(chǎn)生的原因也很多，比如競(jìng)爭(zhēng)趕工，攀比，苦肉計(jì)等等。不是所有的項(xiàng)目開(kāi)發(fā)都要996，也有一些解法妙方，比如匿名問(wèn)卷調(diào)查，比如破除迷思，比如固定、有限可預(yù)期沖刺：每季度最后一個(gè)月996或者為了某個(gè)短期目標(biāo)不超過(guò)三個(gè)月，最后，合理評(píng)估人力，加人。

3.2 人總是不夠

問(wèn)題情景：從0開(kāi)始的項(xiàng)目如何組建團(tuán)隊(duì)，項(xiàng)目缺乏負(fù)責(zé)人，出現(xiàn)人員流失等等。有以下解決方法：提升招聘速度，比如內(nèi)部推薦，或者通過(guò)社招，實(shí)習(xí)和外包等手段招人。另外團(tuán)隊(duì)建設(shè)和團(tuán)隊(duì)關(guān)懷也很重要，有助于提升部門向心力。

3.3 需求總是在變

問(wèn)題情景：

1. 需求評(píng)審?fù)辏踔辽暇€前還在不停加需求，改需求
2. 需求不清楚，不細(xì)化，開(kāi)發(fā)到一半要調(diào)整
3. 市場(chǎng)運(yùn)營(yíng)臨時(shí)活動(dòng)
4. 老大或客戶的緊急需求
5. 線上bug hotfix打亂節(jié)奏

結(jié)果就是經(jīng)常推翻重做，導(dǎo)致心理挫折，或者經(jīng)常加班加點(diǎn)，團(tuán)隊(duì)疲于奔命。且新需求可能帶來(lái)更多bug。怎樣來(lái)解決這個(gè)問(wèn)題呢？

3.3.1 需求不夠明確

首先如果需求不夠明確，那么我們就要對(duì)需求與交互評(píng)審細(xì)化。

3.3.1.1 第一道防線

構(gòu)筑第一道防線：核心產(chǎn)品組，由項(xiàng)目經(jīng)理，產(chǎn)品經(jīng)理和交互設(shè)計(jì)師等核心人員組成。他們的任務(wù)就是定需求，過(guò)交互，進(jìn)行市場(chǎng)調(diào)研。

3.3.1.2 嚴(yán)格明確需求與交互評(píng)審

需求設(shè)計(jì)階段，進(jìn)行需求評(píng)審?？梢远啻芜M(jìn)行。先進(jìn)行一次小評(píng)審，產(chǎn)品組一致通過(guò)，沒(méi)有問(wèn)題。再進(jìn)行大評(píng)審，全員一致通過(guò)，沒(méi)有問(wèn)題。參與人員：

1. 策劃
2. 交互
3. 視覺(jué)
4. 開(kāi)發(fā)
5. 測(cè)試
6. 運(yùn)營(yíng)等負(fù)責(zé)人

評(píng)審目標(biāo)是確認(rèn)需求的優(yōu)先級(jí)，需求的價(jià)值，并初判可實(shí)現(xiàn)性。評(píng)審形式為集中會(huì)議，超出團(tuán)隊(duì)容量的需求提前砍掉，減少交互工作量。

交互設(shè)計(jì)階段，組織交互評(píng)審，仍然是先小評(píng)審：產(chǎn)品組一致通過(guò)，沒(méi)有問(wèn)題。然后再大評(píng)審：需要確認(rèn)清楚才能進(jìn)行全體交互評(píng)審。產(chǎn)品，開(kāi)發(fā)，QA一致通過(guò)，沒(méi)有問(wèn)題即可。

計(jì)劃階段，模塊負(fù)責(zé)人依據(jù)優(yōu)先級(jí)和工作量做計(jì)劃并建JIRA。然后進(jìn)入開(kāi)發(fā)階段，開(kāi)發(fā)完畢，提測(cè)前兩天進(jìn)行聯(lián)調(diào)。提測(cè)前兩天進(jìn)行冒煙測(cè)試，開(kāi)發(fā)冒煙完成才能提測(cè)。測(cè)試完成后上預(yù)發(fā)布版本（上線前兩天），最后，進(jìn)行上線，線上若有重大問(wèn)題直接回滾。上線回歸驗(yàn)證完，上線完成。

3.3.1.3 評(píng)審會(huì)議管理小技巧

會(huì)前：確定是會(huì)議評(píng)審還是郵件評(píng)審，評(píng)審材料至少提前一天發(fā)出，便于參會(huì)人提前了解評(píng)審內(nèi)容，所有關(guān)鍵評(píng)審員都要確認(rèn)可以參加評(píng)審會(huì)議，開(kāi)會(huì)前收到所有關(guān)鍵評(píng)審員的反饋（可選），提前思考，準(zhǔn)備問(wèn)題，能大幅降低會(huì)議時(shí)間。

會(huì)中：按照會(huì)議議程有序進(jìn)行，所有comments用相應(yīng)工具記錄下來(lái)方便會(huì)后跟蹤，保證會(huì)議高效，每個(gè)議題應(yīng)控制時(shí)間。除主持人，其他人不許帶電腦，整個(gè)會(huì)議最好1小時(shí)以內(nèi)，不要超過(guò)2小時(shí)。若發(fā)現(xiàn)critical或者block級(jí)別問(wèn)題，立即商議是否需要二次評(píng)審，不能得過(guò)且過(guò)，要確保充分討論完成才能進(jìn)入下一環(huán)節(jié)

會(huì)后：產(chǎn)品經(jīng)理根據(jù)評(píng)審會(huì)上接受的建議進(jìn)行更新。所有會(huì)上沒(méi)有結(jié)論的議題，會(huì)后有公告，并將更新后的材料發(fā)出再次郵件確認(rèn)，所有關(guān)鍵評(píng)審員對(duì)更新的材料進(jìn)行再次審核，沒(méi)有異議才算完成。執(zhí)行流程確認(rèn)后，可以做個(gè)簡(jiǎn)單的checklist幫助輔助確認(rèn)。

3.3.2 需求頻繁變更

若需求頻繁變更，那么就需要建立一定的需求變更流程來(lái)約束。發(fā)起人先跟產(chǎn)品經(jīng)理討論，然后確認(rèn)方案，進(jìn)行交互稿或交互設(shè)計(jì)。然后召集各方負(fù)責(zé)人進(jìn)行需求討論。各方確認(rèn)是否同意變更。如果變更多或者重大，影響工期，則需要郵件群發(fā)給開(kāi)發(fā)組周知。如果變更小，JIRA跟蹤即可。JIRA依照流程走：交互稿，視覺(jué)方案確認(rèn)，然后交前端或相關(guān)開(kāi)發(fā)。

另一種方式是需求凍結(jié)，即約定上線窗口，錯(cuò)過(guò)窗口要等下一次，這樣形成規(guī)范讓大家有計(jì)劃提需求。

3.3.3 線上bug處理

線上bug的處理會(huì)帶來(lái)以下問(wèn)題：會(huì)占用開(kāi)發(fā)和測(cè)試大量時(shí)間，并影響常規(guī)版本的開(kāi)發(fā)時(shí)間和質(zhì)量。所有的hotfix統(tǒng)一郵件報(bào)QA確認(rèn)，QA或需求方發(fā)現(xiàn)bug建立jira，QA分析并判斷是否hotfix，然后相應(yīng)負(fù)責(zé)人sign-off。對(duì)hotfix設(shè)立優(yōu)先級(jí)（P0:立即修復(fù)上線，P1:考慮一個(gè)周期中集中修復(fù)一堆P1bug，打包上線），考慮bug的影響范圍評(píng)估嚴(yán)重程度。確認(rèn)要hotfix的bug后，QA建立hotfix的jira記錄，注意每次解決的問(wèn)題單獨(dú)建jira。一定要培養(yǎng)好clean hotfix的好習(xí)慣。盡可能少改動(dòng)代碼，只包含引起hotfix的一次改動(dòng)，不可夾帶私貨，不能修復(fù)其他無(wú)關(guān)bug。如果一次hotfix要改動(dòng)的代碼很多，考慮做成小版本的形式，留足充分的測(cè)試時(shí)間，QA設(shè)計(jì)冒煙測(cè)試用例，開(kāi)發(fā)冒煙通過(guò)后提測(cè)。hotfix來(lái)自客戶報(bào)的bug，要避免引入新功能從線上分支拉入hotfix分支，然后開(kāi)發(fā)，自測(cè)，然后提測(cè)。模塊負(fù)責(zé)人做code review，進(jìn)行bug原因分析，修復(fù)影響分析并分析漏測(cè)原因。測(cè)試通過(guò)后開(kāi)發(fā)負(fù)責(zé)人發(fā)上線郵件，上線完成，線上驗(yàn)證。最后針對(duì)此bug周會(huì)上做總結(jié)。

3.4 如何提升產(chǎn)品質(zhì)量

問(wèn)題情景：產(chǎn)品質(zhì)量不好，bug多。開(kāi)發(fā)覺(jué)得測(cè)試是測(cè)試團(tuán)隊(duì)的工作。接近上線甚至上線后，才發(fā)現(xiàn)和需求落差大。

對(duì)此有兩種解決方案。一是產(chǎn)品走查，由產(chǎn)品經(jīng)理，交互和視覺(jué)在提測(cè)后，上線前進(jìn)行檢查：實(shí)際產(chǎn)品與設(shè)計(jì)稿是否有差異？是否有需求設(shè)計(jì)不合理之處？并提出：bug，需求變更或新需求。二是Bug Bash，最好在QA第二輪測(cè)試結(jié)束通過(guò)后，由產(chǎn)品策劃，交互，視覺(jué)走查，進(jìn)行Bug大掃除。

四. 實(shí)戰(zhàn)案例：網(wǎng)易大數(shù)據(jù)

4.1 內(nèi)部創(chuàng)業(yè)：從0到1

從產(chǎn)品背景看，網(wǎng)易項(xiàng)目有3種。技術(shù)型項(xiàng)目較為純粹，團(tuán)隊(duì)成員主要是開(kāi)發(fā)和QA。To C產(chǎn)品則包含產(chǎn)品，設(shè)計(jì)，開(kāi)發(fā)，QA，市場(chǎng)，運(yùn)營(yíng)和客服等角色。To B產(chǎn)品則包含產(chǎn)品，設(shè)計(jì)，開(kāi)發(fā)，QA，市場(chǎng)，銷售，售前，售后，實(shí)施和客服。

項(xiàng)目管理使命就是幫助整個(gè)團(tuán)隊(duì)流程，溝通，協(xié)作等優(yōu)化，幫助各專業(yè)角色推進(jìn)相關(guān)工作，一起完成目標(biāo)，專注于項(xiàng)目最重要的東西：團(tuán)隊(duì)KPI達(dá)成（產(chǎn)品交付，銷售成果），幫助產(chǎn)品業(yè)務(wù)成功。項(xiàng)目管理有三大體系：業(yè)務(wù)全鏈路項(xiàng)目管理，教練和網(wǎng)易項(xiàng)目管理體系。

4.1.1 企業(yè)級(jí)產(chǎn)品業(yè)務(wù)全鏈路項(xiàng)目管理

4.1.1.1 戰(zhàn)略管理

可以考慮設(shè)計(jì)沖刺，快速完成MVP來(lái)驗(yàn)證需求。戰(zhàn)略管理一版包含如下環(huán)節(jié)：

• 市場(chǎng)調(diào)研
• 戰(zhàn)略分析
• 商業(yè)模式設(shè)計(jì)
• 戰(zhàn)略與目標(biāo)選擇
• 戰(zhàn)略與目標(biāo)執(zhí)行

4.1.1.2 產(chǎn)品設(shè)計(jì)

要進(jìn)行用戶研究和市場(chǎng)研究。后者包含產(chǎn)品需求，市場(chǎng)運(yùn)營(yíng)需求和銷售需求。市場(chǎng)研究會(huì)形成需求池，然后對(duì)需求池中的需求排好優(yōu)先級(jí)。進(jìn)行需求評(píng)審，交互設(shè)計(jì)和交互評(píng)審。兩條線：視覺(jué)設(shè)計(jì)-視覺(jué)評(píng)審，技術(shù)方案設(shè)計(jì)-技術(shù)評(píng)審。產(chǎn)品設(shè)計(jì)最后還包含競(jìng)品調(diào)研和產(chǎn)品宣傳。

4.1.1.3 研發(fā)

包含迭代計(jì)劃會(huì)，開(kāi)發(fā)（Bug的hotfix流程），冒煙，提測(cè)，測(cè)試，預(yù)發(fā)，上線和需求驗(yàn)證。

4.1.1.4 運(yùn)營(yíng)

包含客戶支持，內(nèi)容運(yùn)營(yíng)，客戶運(yùn)營(yíng)（用戶留存/增長(zhǎng)，需求挖掘），現(xiàn)在還有更進(jìn)一步的基于數(shù)據(jù)分析的精細(xì)運(yùn)營(yíng)，這種產(chǎn)品運(yùn)營(yíng)需要執(zhí)行以下幾個(gè)步驟：

1. 確認(rèn)目標(biāo)
2. 確認(rèn)指標(biāo)
3. 數(shù)據(jù)規(guī)劃
4. 數(shù)據(jù)準(zhǔn)備（埋點(diǎn)）
5. 數(shù)據(jù)整理
6. 報(bào)表制作
7. 日常監(jiān)控（驗(yàn)證需求）
8. 挖掘問(wèn)題
9. 決策

4.1.1.5 市場(chǎng)

包含：

1. SEM
2. 廣告/公關(guān)：文稿策劃，媒體管理
3. 市場(chǎng)活動(dòng)
4. 商務(wù)合作：政府協(xié)會(huì)，客戶合作，合作伙伴（挑選合作伙伴，討論合作模式，確定合作框架，簽訂合作戰(zhàn)略合同，合作質(zhì)量考核），渠道，品牌（品牌定位，品牌設(shè)計(jì)與包裝，品牌宣傳），線上運(yùn)營(yíng)（新媒體，流量）

4.1.1.6 銷售

• 銷售線索
  1. 商機(jī)挖掘（電話，拜訪）
  2. 售前需求確認(rèn)
  3. 解決方案設(shè)計(jì)
  4. 方案評(píng)估（需求評(píng)估，外包評(píng)估，采購(gòu)評(píng)估）
  5. poc測(cè)試/試用（實(shí)施部署/試用流程）
  6. 商務(wù)談判（方案確認(rèn)報(bào)價(jià)）
  7. 項(xiàng)目投標(biāo)選型（投標(biāo)策略，標(biāo)書，投標(biāo)分析）
• 銷售支持
  1. 銷售工具包
  2. CRM
  3. 合同管理
• 實(shí)施售后

4.1.1.7 人力資源

人力資源組織架構(gòu)：

1. 招聘

• 需求梳理
• JD撰寫
• 發(fā)布渠道
• 面試
• 入職

2. 培育

• 學(xué)習(xí)環(huán)境打造
• 培訓(xùn)

3. 任職管理

• 晉升
• 崗位安排

4. 激勵(lì)

• 福利
• 加薪

4.1.2 項(xiàng)目管理可以做什么

把團(tuán)隊(duì)當(dāng)成一家小公司，把全局盤點(diǎn)清楚。深入盤點(diǎn)各環(huán)節(jié)，各項(xiàng)目組織間可以互相學(xué)習(xí)，沉淀。初創(chuàng)產(chǎn)品可了解商業(yè)化完整版圖，盤點(diǎn)自己缺了什么。明確各環(huán)節(jié)與各角色的協(xié)作流，有助于大家團(tuán)隊(duì)合作，不斷優(yōu)化，提升。

4.2 以網(wǎng)易大數(shù)據(jù)為例

傳統(tǒng)企業(yè)數(shù)據(jù)現(xiàn)狀痛點(diǎn)是企業(yè)包含了很多環(huán)節(jié)，每個(gè)環(huán)節(jié)都會(huì)產(chǎn)生數(shù)據(jù)，但卻無(wú)法將這些數(shù)據(jù)融合起來(lái)產(chǎn)生價(jià)值：

1. 供應(yīng)鏈：供應(yīng)鏈數(shù)據(jù)
2. 生產(chǎn)：生產(chǎn)數(shù)據(jù)
3. 倉(cāng)儲(chǔ)：倉(cāng)儲(chǔ)數(shù)據(jù)
4. 物流：生產(chǎn)數(shù)據(jù)
5. 通路：通路數(shù)據(jù)
6. 銷售：銷售數(shù)據(jù)

4.2.1 大數(shù)據(jù)團(tuán)隊(duì)背景

團(tuán)隊(duì)的目標(biāo)是內(nèi)部平臺(tái)產(chǎn)品化與對(duì)外商業(yè)化，提供中大型傳統(tǒng)企業(yè)大數(shù)據(jù)解決方案。網(wǎng)易大數(shù)據(jù)包含猛犸大數(shù)據(jù)平臺(tái)和有數(shù)敏捷分析平臺(tái)。猛犸大數(shù)據(jù)平臺(tái)為穩(wěn)定的一站式數(shù)據(jù)開(kāi)發(fā)平臺(tái)，覆蓋數(shù)據(jù)傳輸，計(jì)算及作業(yè)流調(diào)度。有數(shù)敏捷分析平臺(tái)是敏捷的BI數(shù)據(jù)分析平臺(tái)，可創(chuàng)建交互式可視化報(bào)表和儀表盤，有強(qiáng)大的定制和擴(kuò)展能力，滿足個(gè)性化需求。網(wǎng)易還具有海量數(shù)據(jù)資產(chǎn)，深度加工網(wǎng)易19年積累的互聯(lián)網(wǎng)大數(shù)據(jù)，提供企業(yè)智能決策解決方案。

實(shí)踐經(jīng)驗(yàn)：

1. 重要性與方向
2. 多部門協(xié)作
3. 銷售業(yè)務(wù)開(kāi)展
4. 產(chǎn)品打磨
5. 缺人與資源

4.3 業(yè)務(wù)打磨

4.3.1 目標(biāo)（戰(zhàn)略）管理

團(tuán)隊(duì)需要解決的問(wèn)題包括：

1. 對(duì)外產(chǎn)品形態(tài)
2. 銷售與市場(chǎng)策略，組織結(jié)構(gòu)，
3. 老大，產(chǎn)品，團(tuán)隊(duì)技術(shù)出身，不知道如何推動(dòng)業(yè)務(wù)
4. 不知道方向?yàn)楹危?/li>

改進(jìn)方法：

1. 引入專家
2. 主管周會(huì)，產(chǎn)品周會(huì)，產(chǎn)品站會(huì)，業(yè)務(wù)站會(huì)，月會(huì)
3. 核心成員凝聚在一起，達(dá)成共識(shí)，信息互通

流程：

1. 明確目標(biāo)
2. 市場(chǎng)研究
3. 設(shè)計(jì)商業(yè)模式
4. 執(zhí)行
5. 反饋

4.3.2 搭班子，組班委

首先進(jìn)行需求梳理，人力盤點(diǎn)，組織架構(gòu)設(shè)計(jì)，做到適才試用，建立各級(jí)管理層，給予現(xiàn)有成員發(fā)揮的空間。其次是招到靠譜，比自己優(yōu)秀的人，除了技術(shù)，也要考慮管理與綜合能力。

4.3.3 設(shè)計(jì)沖刺之需求管理

困難在于方向不可能一下子想清楚，而產(chǎn)品需要證明市場(chǎng)價(jià)值。對(duì)此采用小步迭代方式創(chuàng)建MVP，小迭代2-3周，快速驗(yàn)證需求。不一定完全實(shí)現(xiàn)，可以原型，仿真，包裝，美觀。讓老大快速取得信心，爭(zhēng)取資源。這么做的優(yōu)點(diǎn)是時(shí)間短，只做對(duì)客戶最有價(jià)值部分，反而想的清楚?？焖偃〉梅答伣o老大和客戶。團(tuán)隊(duì)容易進(jìn)入奮斗模式。

4.3.4 業(yè)務(wù)驅(qū)動(dòng)測(cè)試

這塊的問(wèn)題是測(cè)開(kāi)比太低，產(chǎn)品質(zhì)量無(wú)法保證。這塊的改進(jìn)方法主要有產(chǎn)品組走查+bug bash，超管全回歸（預(yù)發(fā)布系統(tǒng)），人工看報(bào)表，然后過(guò)渡到日志排查系統(tǒng)，再過(guò)渡到自動(dòng)化。業(yè)務(wù)倒逼，真實(shí)場(chǎng)景。

4.3.5 推動(dòng)業(yè)務(wù)

1. 不斷深入思考：沒(méi)有成績(jī)單-銷售線索不足-如何提升轉(zhuǎn)化找到精準(zhǔn)需求
2. 一步步優(yōu)化試錯(cuò)：展會(huì)-協(xié)會(huì)-SEM-電銷

4.4 流程建立與管理

項(xiàng)目的痛點(diǎn)在于多版本并行且延期嚴(yán)重。對(duì)此我們的應(yīng)對(duì)方式是縮短迭代周期，逐步改進(jìn)。一次做好一件事，把時(shí)間周期明確下來(lái)，大幅縮短交付時(shí)間，最后從2周開(kāi)發(fā)，2周測(cè)試改進(jìn)到8天開(kāi)發(fā)，7天測(cè)試。實(shí)施全流程JIRA管理，包括版本時(shí)間計(jì)劃，需求管理，任務(wù)拆解，迭代計(jì)劃，日常監(jiān)控，產(chǎn)品走查，測(cè)試，預(yù)發(fā)走查，上線走查。全面使用JIRA收集過(guò)程數(shù)據(jù)。每個(gè)版本分解為story（需求）并進(jìn)一步分解為task（任務(wù)）。用儀表盤管理需求，監(jiān)控進(jìn)度，執(zhí)行流程。每日發(fā)JIRA日?qǐng)?bào)，精準(zhǔn)知道各種維度的數(shù)據(jù)統(tǒng)計(jì)，每個(gè)人任務(wù)數(shù)量。

4.5 創(chuàng)造合作氛圍

進(jìn)行部門融合。建立大群，文檔庫(kù)，知識(shí)分享學(xué)習(xí)。各種公司活動(dòng)一起協(xié)作，創(chuàng)造合作氛圍。打造品牌：網(wǎng)易大數(shù)據(jù)和數(shù)據(jù)科學(xué)中心。安排好座位：老大在中心并向外擴(kuò)散。

業(yè)務(wù)成就：

1. 半年時(shí)間內(nèi)從虛擬合作組織到形成數(shù)據(jù)科學(xué)中心
2. 明確中大型客戶大數(shù)據(jù)解決方案
3. 完成業(yè)務(wù)團(tuán)隊(duì)組建，產(chǎn)品核心人物的豐滿
4. 半年內(nèi)拿下標(biāo)桿客戶，跑通全鏈路項(xiàng)目管理，驗(yàn)證商業(yè)模式

4.5.1 企業(yè)級(jí)內(nèi)部創(chuàng)業(yè)心得總結(jié)

1. 戰(zhàn)略討論：對(duì)的方向和對(duì)的需求
2. 管理者要把整個(gè)團(tuán)隊(duì)，環(huán)節(jié)，流程理清，才能更好推動(dòng)工作
3. 找比自己更聰明專業(yè)的人，完善團(tuán)隊(duì)構(gòu)建
4. 遇到問(wèn)題，深入思考，細(xì)化分析每個(gè)環(huán)節(jié)，逐步優(yōu)化戰(zhàn)略，產(chǎn)品和業(yè)務(wù)
5. 打造創(chuàng)業(yè)公司精神：緊迫感和快速試錯(cuò)
6. 業(yè)務(wù)市場(chǎng)敏銳度，大局觀
7. 好玩最重要

五. 實(shí)戰(zhàn)案例：網(wǎng)易云音樂(lè)

5.1 業(yè)務(wù)快速發(fā)展下的項(xiàng)目管理變革

這是一款音樂(lè)app，業(yè)務(wù)包含音樂(lè)，電臺(tái)，視頻和商城四大部分。特點(diǎn)是個(gè)性推薦，歌單，有趣的評(píng)論和極致的用戶體驗(yàn)。然而團(tuán)隊(duì)在初創(chuàng)時(shí)也遇到過(guò)問(wèn)題，例如需求無(wú)法完整交付，復(fù)雜的溝通和團(tuán)隊(duì)信任危機(jī)。這就分別需要任務(wù)管理流程調(diào)整，重新定義團(tuán)隊(duì)和增強(qiáng)團(tuán)隊(duì)信任來(lái)一一應(yīng)對(duì)。

5.2 任務(wù)管理流程調(diào)整

變革前現(xiàn)狀是以職能組為單位劃分，團(tuán)隊(duì)規(guī)模變大后遇到很多問(wèn)題：

1. 聯(lián)調(diào)階段發(fā)現(xiàn)任務(wù)遺漏
2. 需求方很委屈
3. 團(tuán)隊(duì)沖突增強(qiáng)
4. 強(qiáng)化了職能墻

仔細(xì)分析后發(fā)現(xiàn)，原來(lái)團(tuán)隊(duì)小，職能負(fù)責(zé)人還能把關(guān)所有需求。職能角色少，復(fù)雜度不高，直接由策劃創(chuàng)建任務(wù)可行，一定程度上高效。后來(lái)為何玩不轉(zhuǎn)？是因?yàn)閳F(tuán)隊(duì)變大，職能內(nèi)部多了小組細(xì)分，人數(shù)翻番，且分工細(xì)化，職能角色增多，任務(wù)涉及的角色增多。

解決思路：

1. 以終為始：所有人都關(guān)注需求而非任務(wù)
2. 解放策劃：找更適合的人做任務(wù)拆解
3. 引入團(tuán)隊(duì)參與：提高大家參與感，改變輻射狀管理模式

如何引發(fā)改變：

1. 觀察和記錄問(wèn)題
2. 與關(guān)鍵干系人溝通
3. 提供解決方案

變革后，項(xiàng)目版本由項(xiàng)目經(jīng)理創(chuàng)建，由版本負(fù)責(zé)人負(fù)責(zé)。需求由策劃創(chuàng)建，需求技術(shù)負(fù)責(zé)人負(fù)責(zé)。子任務(wù)由需求技術(shù)負(fù)責(zé)人創(chuàng)建，由開(kāi)發(fā)負(fù)責(zé)。

如果有人不買賬怎么辦？這時(shí)首先要取得技術(shù)總監(jiān)和職能組長(zhǎng)關(guān)鍵干系人認(rèn)可。然后團(tuán)結(jié)支持者，取得產(chǎn)品團(tuán)隊(duì)支持，初期選取支持者做嘗試，并為搖擺者解決困惑，具體定義需求技術(shù)負(fù)責(zé)人的職責(zé)。最后包圍頑固者。

帶來(lái)的變化：

1. 任務(wù)遺漏情況減少
2. 弱化職能墻，為組建虛擬團(tuán)隊(duì)提供基礎(chǔ)
3. 提高團(tuán)隊(duì)的項(xiàng)目管理意識(shí)和能力

5.3 重新定義團(tuán)隊(duì)

團(tuán)隊(duì)?wèi)?yīng)該跨職能，有完整交付需求的能力。組建業(yè)務(wù)團(tuán)隊(duì)相對(duì)獨(dú)立，可以簡(jiǎn)化跨組溝通。團(tuán)隊(duì)需要相對(duì)穩(wěn)定長(zhǎng)期存在，就要考慮業(yè)務(wù)的穩(wěn)定性。團(tuán)隊(duì)劃分時(shí)應(yīng)該要綜合考慮組織對(duì)人員動(dòng)態(tài)調(diào)配能力以及團(tuán)隊(duì)的獨(dú)立性。

變革后組建了跨職能虛擬業(yè)務(wù)團(tuán)隊(duì)，建立了包含客戶端，交互，視覺(jué)和算法的公共資源池。重新定義計(jì)劃方式，前后端兩周迭代，所有組的迭代周期對(duì)齊，客戶端版本手動(dòng)對(duì)齊。

開(kāi)展計(jì)劃會(huì)，會(huì)前進(jìn)行需求和交互評(píng)審，定義優(yōu)先級(jí)，開(kāi)發(fā)評(píng)估工作量。會(huì)中簡(jiǎn)單陳述需求，確定需求優(yōu)先級(jí)，排定需求發(fā)布安排，包括提測(cè)點(diǎn)，發(fā)布點(diǎn)和版本。會(huì)后梳理需求和版本，分解任務(wù)，確認(rèn)排期。