前端進階之路：如何高質量完成產品需求開發

寫在前面

做爲一個互聯網前端老鳥，這麼些年下來，作過的項目也很多。從最初的個人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進行批評教育，實在不行就換人。

關注線上質量

這一點很是重要，但又是容易被忽略的一點。需求發佈上線，是個重要的里程碑，但並不意味着需求的終點，還得時刻關注如下事項：

• 功能是否正常運行？

• 各項指標是否正常？好比產品上報數據、性能監控數據、錯誤監控數據等。

• 有哪些能夠優化的點？優先級多高？

• 。。。

只管功能開發，一旦需求上線，馬上作甩手掌櫃，一樣是缺少責任意識的表現。試想一下，若是你是團隊的老大，你會放心把重要的需求交給一個「甩手掌櫃」嗎。

寫在後面

本文中，筆者主要從一個前端工程師的角度出發，談了一些「高質量完成需求」的經驗。裏面提到的很多內容，放到其餘崗位也是適用的。鑑於篇幅緣由，不少細節都是點到爲止，並無深刻展開。

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