前言
今年Q1，我負責內部一個技術專案的產品、專案管理以及質量和運營工作，目前專案第一階段規劃的需求都交付了。
我將做這個專案過程中的一些經歷和感受總結了下，就是今天這篇文章的內容。
思維導圖
需求的三個來源
先來聊聊需求相關的事情吧。
一般來說，像企業內部的一些技術專案，立項的前提幾乎都是有相關的訴求，彙總分析後得到了可落地執行的需求。
從專案角度來說，需求的來源無非下列三個部分。
立項階段內部規劃的需求
上面提到了，一般內部的技術專案都是從日常工作中收集的一些相關團隊訴求或線上問題，需要針對性的進行處理。
對這些訴求進行分析後，通過抽取共性和權重較高的部分，整理成可落地執行的需求，然後通過專案立項來落地交付。
使用者訪談得到的業務痛點
除了對日常的問題和其他團隊的訴求進行分析之外，專案立項後保持和使用者的聯絡也很重要。
因為立項階段規劃的需求只代表過去，但使用者的訴求是一直變化的。因此和使用者保持積極的聯絡，多做訪談，也是更好看展工作的前提。
使用者訪談時，有一點要注意：明確做訪談的目的，瞭解使用者的真實訴求和痛點。可以參考如下三點：
- 使用者面臨的痛點背景是什麼？
- 使用者希望解決的是什麼問題？
- 有哪些解決問題的方案（最好多準備幾個，在技術評估階段進行選型）？
投產使用收集的反饋建議
對需求進行立項排期後，要做到按時交付上線，讓使用者儘快的使用起來，從使用者的反饋得到真實的評價。
使用者一般會對很多功能提出一些使用上的建議，或者會冒出來一些新的訴求。
這都很正常，最怕的是交付的東西不是使用者想要的，或者無法很好的解決使用者面臨的問題。
專案的生命週期
接下來聊聊專案的生命週期。像這種企業內部的專案，我將其生命週期劃分為四大階段：
立項調研
立項調研階段，主要工作是確定整體規劃，對需求進行分析，確定優先順序，要投入的資源以及交付時間。
其中最核心的部分還是需求，知道要做什麼，什麼時候完成，用什麼解決方案，這一切都依賴於需求本身。
需求採集
需求採集階段要做的事情，上面已經介紹過了需求的三個來源，這裡說點別的。
立項階段內部規劃的需求，主要來源於日常工作中遇到的問題。我的習慣是將這些問題都進行記錄，在每週的週會或者專門拉個會議來討論這些問題，是否需要解決，優先順序是什麼，評估解決方案的可行性。
這裡要注意的是，會議要儘可能收斂，明確要討論的主題，儘可能將問題在會議中都解決掉。
使用者訪談得到的業務痛點，這點其實蠻有意思。業務團隊或者說使用者並不總是很清晰的知道自己要什麼，他們可能會說很多他們希望的訴求，但不一定都是優先順序很高或者值得做的。
訪談時要記住一點，多問面臨的問題和痛點，不要問他們想要什麼，這是你自己該思考並解決的問題。
投產使用收集的反饋建議，這個也挺有意思。從使用者訴求到轉化為可實現的具體需求，再到研發交付，過程中總會有點偏差。而且業務一直在變化，使用者的訴求也是不斷變化的。
我的做法是一方面通過專門的溝通對接群來實時響應使用者的反饋建議；另一方面，專門開了一個反饋建議的入口，讓使用者能隨時將建議反饋給我們。通過定時任務推送到專門的群裡，便於及時響應。
排期研發
這個階段，我個人的經驗是需要注意如下六點：
1）選擇合適的迭代模型
像這種需求多變且來源較多的專案，瀑布迭代模型就顯得很不適用。儘快的交付和獲得使用者反饋，並進行快速響應迭代，比按部就班的交付更容易拿到好結果。
2）構建完善的專案文件
我負責的這個專案，選擇了敏捷的交付模式，但敏捷不代表不需要文件或者輕文件了。完善的專案文件依然是很重要的。
經驗之談，所有口頭的約定都是不可信的，你也不能指望團隊裡所有人都具備良好的職業素養和風險以及質量意識。
關於構建專案文件的具體內容，可參考我之前的文章：《如何設計良好的技術專案文件結構》
3）需求優先順序定時排期
談到了需求是多變的，那在需求排期時候就不能一錘定音，而是需要定時去覆盤已交付的需求以及待交付的需求。
有些需求實際上交付的並不是很好，而需求的優先順序也是需要跟隨專案的具體進度和使用者反饋來實時變化的。
當然，每個迭代週期中，還是不建議去做需求變更和緊急需求插入，這是對交付能力的一種傷害。
4）構建質量是核心卡點
對於需求不確定的專案，不能要求需求的質量有多高或者多麼可靠，那麼在研發階段或者說質量構建階段，要做好卡點。
並不是說一定要做單元測試或者多高的單測覆蓋率，但codereview和快速的自動化驗證還是很有必要的。
至於我們熟知的像冒煙測試、提測評審等流程，還是需要的。選擇了敏捷迭代模式，不意味著要犧牲質量。
5）風險需要實時的跟進
專案迭代過程中，總會出現很多問題或者影響交付的風險，比如緊急需求插入、幫使用者排查問題、資源投入或者專案優先順序的調整，都會影響專案的交付質量。唯一能做的就是實時跟進風險，靈活應變。
6）交付質量要保證可控
從測試角度來講，要保障交付質量肯定少不了規範的流程、方案評審測試case評審、提測卡點、多輪測試以及線上驗證等很多工作。
但從另一方面來講，選擇了敏捷迭代交付，勢必要在某些方面做一些犧牲。
我個人的經驗，是可以容忍帶著一些問題上線，但前提是不影響使用者正常使用。像一些P2-P3的BUG，可以選擇在下個迭代或者小版本的優化來解決。
當然，可以選擇延期上線釋出，但需要確定的是這樣做不會讓使用者對你的交付能力和交付效率有所懷疑。其中得失，還是根據具體情況自己評估吧。
交付上線
關於專案交付線上釋出，我想聊下面三點：
1）快速交付可用的MVP產品
面對需求多變的專案，快速交付可用的MVP產品讓使用者使用起來，是最重要的一件事，悶頭憋大招反而很容易錯失機會。
2）重視上線後的使用者反饋建議
業務一直在變化，使用者的訴求也是不斷變化的。一方面需要實時響應使用者的反饋建議；另一方面，使用者的反饋和建議才是讓產品變得更好的源驅動力。多聽聽使用者說什麼，不要替使用者做決定。
3）覆盤歸因是提高交付質量的祕訣
覆盤歸因，我在前面專門寫過一篇文章來談這件事。參考：《覆盤歸因，提高交付質量的祕訣》
專案交付的四大要點
關於專案交付的要點，我試著從下面四點來聊聊我的一些看法。
交付能力
交付能力看著是個很玄的東西，我的理解是能否按期交付使用者可接受的MVP產品。保持交付節奏很重要，讓使用者感受到產品是不斷進化的更好的，這樣使用者做小白鼠的心裡牴觸才不會很大。
交付質量
交付質量一定要保持可控！怎麼理解這句話，實際上就是要保證質量的下限。
可以容忍帶著一些問題上線，但前提是不影響使用者正常使用。像一些P2-P3的BUG，可以選擇小版本優化來解決。
當然，可以選擇延期上線釋出，但需要確定的是這樣做不會讓使用者對你的交付能力和交付效率有所懷疑。其中得失，還是根據具體情況自己評估吧。
交付效率
除了按期交付和保障質量可控，在有限的時間和資源投入背景下，提高交付效率就很有必要了。
我在具體實踐中，用到的一些提效手段有下面幾種：
- 需求評審和排期要快速精準（儘量半小時搞定）；
- CICD是必不可少的提效手段（這個考驗公司的技術基建能力）；
- 快速的自動化驗證能節省很多時間（完善的專案文件能提高驗證的效率）；
- 線上問題及時響應和完備的告警監控機制（既考驗技術基建能力又考驗職業素養）；
使用者滿意度
上面講了很多內容，但你會發現我一直在提到使用者滿意度相關的事情。我認為使用者滿意度，可以分為三個境界：
最好的方式是你發現業務有痛點，快速主動的解決痛點，超預期交付；次一點，業務提需求，按期保質交付；最次的方式是你覺得需要這個，花了很多資源去做，悶頭憋大招，結果沒人鳥你。