IT工程師數位筆記本

寫在前面

作為一個互聯網前端老鳥，這么些年下來，做過的項目也不少。從最初的我的QQ中心、QQ圈子，到后面的QQ群項目、騰訊課堂。從幾個人的項目，到近百號人的項目都經歷過。

這期間，實現了很多的產品需求，也積累了一些經驗。這里稍作總結，希望能給新入行的前端小伙伴們一些參考。

做好需求的關鍵點

要說如何做好一個需求，展開來講，可以寫好幾篇文章，這里只挑重點來講。

最基本的，就是把握好3W：what、when、how。

• what：做什么？
• when：完成時間？
• how：如何完成？

需求場景假設

為了下文不至于太過枯燥，這里進行需求場景的模擬，下文主要圍繞這個“需求”，從what、when、how 三個點展開來講。

假設現在有個論壇的項目，產品經理小C提了個需求 “給論壇增加評論功能” 。作為 前端工程師 的小A接到需求后，該如何高質量的完成這個需求。

• 項目名稱：興趣論壇。
• 項目組主要成員：前端工程師小A，后臺工程師小B，產品經理小C。
• 產品需求：給論壇增加評論功能。

備注：此時我們腦海里浮現的應該是下面這張圖。

What：做什么？

可能有同學要拍案而起了：Are you kidding me？不就加個評論功能嗎，我還能不知道該做啥？

答案很殘酷：是的。

根據過往經驗，不少前端同學，包括一些前端老司機，做需求的時候，的確不知道自己究竟要做什么。導致這種情況發生的原因有哪些呢？

1. 產品經理：提的需求不明確。
2. 前端工程師：沒做好需求確認。

情況1：產品需求不明確

說到產品需求不明確，前端的兄弟們估計可以坐一起開個訴苦大會，因為實在太常見了。典型的有“拍腦門需求”、“一句話需求”、“貼個圖求照抄需求”。

回到之前的例子：給論壇增加個評論功能。

別看連原型圖都貼出來了，其實這就是個典型的“需求不明確”。比如：

• 是否需要支持富文本輸入？
• 是否需要支持社會化分享？
• 發表評論后，評論怎么展示？
• 。。。

也許經過一番確認，最終的需求會是下圖所示。遇到這種情況，一定要做好需求確認，避免后期無意義的返工和延期。

情況2：未做好需求確認

再次強調一下，無論何時，一定要做好需求確認。再有經驗、再負責的產品經理，也幾乎不可能提出“100%明確”的需求。

同樣，回到上面的需求。

現在已經確認了，需要支持富文本輸入、需要展示評論，這就夠了嗎？其實不夠，還有很多需求細節需要進一步確認。比如：

• 評論最大支持輸入多少個字？（非常重要，關乎后臺存儲方案的設計）
• 1個中文算1個字，多少個英文字母算1個字？（產品語言、技術語言 之間的溝通轉換）
• 輸入內容過長，如何進行錯誤提示？（交互細節）
• 輸入內容過長，是否允許提交評論？如允許，是對評論內容進行截斷后提交？（容錯）
• 用戶未輸入內容的情況下，評論框內默認提示文案是什么？（交互細節）
• 。。。

可以、需要確認的內容太多，這里就不贅述。

看到這里，讀者朋友們應該明白，為什么前面會說，幾乎不存在“100%明確”的需求。

很多需求細節，同時也跟技術實現細節強相關，不能苛求產品經理都考慮到。這種情況下，作為開發者的我們應該主動找出問題，并與產品經理一起將細節敲定下來。

When：完成時間？

一個同時有前端、后端參與的需求，精簡后的需求生命周期，大概是這樣的：

需求提出-->開發-->聯調-->提交測試->需求發布

一個需求的實際發布時間，大部分時候取決于實際的開發工作量。如何評估開發工作量呢？最基本的，就是明確“做什么”，這也就是上一小節強調的內容。

這里我們假設：

1. 需求已經明確，小A的開發工作量是3天，小B的開發工作量是3天。
2. 假設小A 9月1號投入開發

那么，是不是9月3號下班前需求就可以發布了？

答案顯然是：不能。

要得出一個靠譜的完成時間，至少需要明確以下內容：

• 前端、后臺 各自的工作量。
• 前端、后臺 投入研發的時間點。
• 前端、后臺 聯調的工作量、時間點。
• 需求提交測試的時間。
• 需求測試的工作量。

最終，需求的完成時間點可能如下：（跟預期的出入很大）

對于需求完成時間的評估，實際情況遠比上面說的要更復雜。比如需要考慮節假日、成員休假、多個需求并行開發、需求存在外部依賴項等。以后有機會再展開來講。

How：如何完成？

完成需求容易，如果要高質量完成，那就需要費點功夫了。同樣的，只挑一些重要的來講

• 明確需求、關鍵時間點
• 嚴控開發、自測、提測質量
• 及時暴露風險
• 推動解決問題
• 關注線上質量

明確需求/關鍵時間點

這塊的重要性，再怎么強調也不為過。前面已經講過了，這里不再贅述。

嚴控開發、自測、提測質量

作為一名合格的前端工程師，對自己的開發質量負責，這是最基本的要求。

要時常問自己：

• 開發：是否嚴格按照需求文檔完成功能的開發。
• 聯調：在與后臺同學聯調前，是否已經對照測試用例，對自己的模塊進行了嚴格的自測。
• 提測：提測前，是否已自測、聯調通過；測試正式介入前，產品是否提前部署到測試環境，并進行初步的驗證。

嚴格把控開發、自測、提測質量，這不但是能力，更是一種負責任的態度。如果能做到這點，不單節省大家的時間，還可以讓其他人覺得自己比較“靠譜”。

備注：以下截圖，是筆者之前一個需求的自測用例（非完整版）。同樣是評論功能，自測用例將近50個。

及時暴露風險

風險意識非常重要。在需求完成的過程中，經常會有各種意外的小插曲出現。對于前端同學，常見的有：

• 視覺稿/交互稿未按時提供。
• 需求變更。
• 工作量評估不足。
• 后臺接口未按時、按質完成。
• bug有好多，但修改不及時。

上面列舉的項，都可能導致需求發布delay，要時刻要保持警惕。一旦出現可能可能導致delay的風險，要及時做好同步，準備好應對措施。

打個比方：

前面說到，小A 評估了3天的開發工作量。等到開發的第2天，發現之前工作量評估少了，至少需要4天才能完成。

這個時候，該怎么辦呢？

相信不少同學都是這樣處理的：咬咬牙，加加班，4天的活3天干，實在完不成了再說。

這樣處理潛在的問題不小：

1. 給自己增加了過重的負擔。
2. 沒能讓問題及早的暴露解決。
3. 可能打亂項目的整體節奏。

更好的處理方式是：及時跟項目組成員同步風險，并落實確認相應解決方案。比如適當調整排期、砍掉部分優先級不高的功能等。

推動解決問題

對于一個職場人能力的評判，“解決問題”的能力，是很重要的一個評估標準。解決問題的能力如何體現呢？

舉個例子，提測過程中，出現了不少bug，對于小A來說，該怎么辦呢？這里分兩種情況：

• bug主要是小A的。
• bug主要是小B的。

第一種情況很簡單，自己的坑自己填，抓緊時間改bug，并做好事總結，降低后續需求的bug率。

第二種情況呢？如果小B比較配合，主動快速修復bug，那沒什么好說的。但萬一不是呢？

遇到這種情況，小A可能會想：“又不是我的bug，干嘛操那份閑心，需求如果delay的話，那也是小B的問題，跟我無關。”

可能不少同學的想法跟小A一樣，這在筆者看來，略顯消極，處理方式顯得不夠“職業化”。

為什么呢？

同在一個項目組，得要有團隊意識、整體意識。需求延期，首先是所有需求相關人的責任，是要一起打板子的。然后，才會對具體的責任人進行問責。

回到前面的場景，小A更好的處理方式是：做好溝通工作，主動推進問題解決。

1. 了解小B沒有及時改bug的原因：有可能太忙、bug不好改、沒有意識到那是自己的bug。
2. 如可能，提供必要幫助：比如跟項目經理申請，這段時間小B集中精力改bug，暫不開發新需求
3. 風險同步：如果小B真的不稱職，盡快知會項目負責人，對小B進行批評教育，實在不行就換人。

關注線上質量

這一點非常重要，但又是容易被忽略的一點。需求發布上線，是個重要的里程碑，但并不意味著需求的終點，還得時刻關注以下事項：

• 功能是否正常運行？
• 各項指標是否正常？比如產品上報數據、性能監控數據、錯誤監控數據等。
• 有哪些可以優化的點？優先級多高？
• 。。。

只管功能開發，一旦需求上線，立刻做甩手掌柜，同樣是缺乏責任意識的表現。試想一下，如果你是團隊的老大，你會放心把重要的需求交給一個“甩手掌柜”嗎。

寫在后面

本文中，筆者主要從一個前端工程師的角度出發，談了一些“高質量完成需求”的經驗。里面提到的不少內容，放到其他崗位也是適用的。鑒于篇幅原因，很多細節都是點到為止，并沒有深入展開。

方法論再多，最終還是需要人去落實。作為一名前端工程師，加強責任意識，主動承擔，勤于總結，做社會主義合格的接班人。