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