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

做好需求的關鍵點

码报开奖结果本期 www.iwqgw.icu 要說如何做好一個需求,展開來講,可以寫好幾篇文章,這里只挑重點來講。

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

  • what:做什么?

  • when:完成時間?

  • how:如何完成?

需求場景假設

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

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

  • 項目名稱:興趣論壇。

  • 項目組主要成員:前端工程師小A,后臺工程師小B,產品經理小C。

  • 產品需求:給論壇增加評論功能。

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

_

What:做什么?

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

答案很殘酷:**是的**。

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

  1. 產品經理:提的需求不明確。

  2. 前端工程師:沒做好需求確認。

情況1:產品需求不明確

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

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

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

  • 是否需要支持富文本輸入?

  • 是否需要支持社會化分享?

  • 發表評論后,評論怎么展示?

  • 。。。

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

_1

情況2:未做好需求確認

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

同樣,回到上面的需求。

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

  • 評論最大支持輸入多少個字?(非常重要,關乎后臺存儲方案的設計)

  • 1個中文算1個字,多少個英文字母算1個字?(產品語言、技術語言 之間的溝通轉換)

  • 輸入內容過長,如何進行錯誤提示?(交互細節)

  • 輸入內容過長,是否允許提交評論?如允許,是對評論內容進行截斷后提交?(容錯)

  • 用戶未輸入內容的情況下,評論框內默認提示文案是什么?(交互細節)

  • 。。。

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

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

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

_2

When:完成時間?

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

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

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

這里我們假設:

  1. 需求已經明確,小A的開發工作量是3天,小B的開發工作量是3天。

  2. 假設小A 9月1號投入開發

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

答案顯然是:**不能**。

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

  • 前端、后臺 各自的工作量。

  • 前端、后臺 投入研發的時間點。

  • 前端、后臺 聯調的工作量、時間點。

  • 需求提交測試的時間。

  • 需求測試的工作量。

最終,需求的完成時間點可能如下:(跟預期的出入很大)

_

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

How:如何完成?

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

  • 明確需求、關鍵時間點

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

  • 及時暴露風險

  • 推動解決問題

  • 關注線上質量

明確需求/關鍵時間點

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

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

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

要時常問自己:

  • 開發:是否嚴格按照需求文檔完成功能的開發。

  • 聯調:在與后臺同學聯調前,是否已經對照測試用例,對自己的??榻辛搜細竦淖圓?。

  • 提測:提測前,是否已自測、聯調通過;測試正式介入前,產品是否提前部署到測試環境,并進行初步的驗證。

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

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

_

及時暴露風險

風險意識非常重要。在需求完成的過程中,經?;嵊懈髦忠饌獾男〔邇魷?。對于前端同學,常見的有:

  • 視覺稿/交互稿未按時提供。

  • 需求變更。

  • 工作量評估不足。

  • 后臺接口未按時、按質完成。

  • bug有好多,但修改不及時。

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

打個比方:

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

這個時候,該怎么辦呢?

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

這樣處理潛在的問題不?。?/p>

  1. 給自己增加了過重的負擔。

  2. 沒能讓問題及早的暴露解決。

  3. 可能打亂項目的整體節奏。

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

推動解決問題

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

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

  • bug主要是小A的。

  • bug主要是小B的。

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

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

遇到這種情況,小A可能會想:“又不是我的bug,干嘛操那份閑心,需求如果delay的話,那也是小B的問題,跟我無關?!?/p>

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

為什么呢?

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

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

  1. 了解小B沒有及時改bug的原因:有可能太忙、bug不好改、沒有意識到那是自己的bug。

  2. 如可能,提供必要幫助:比如跟項目經理申請,這段時間小B集中精力改bug,暫不開發新需求

  3. 風險同步:如果小B真的不稱職,盡快知會項目負責人,對小B進行批評教育,實在不行就換人。

關注線上質量

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

  • 功能是否正常運行?

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

  • 有哪些可以優化的點?優先級多高?

  • 。。。

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

寫在后面

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

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

來源:云棲社區_程序猿小卡

上一篇: 母雞與前端工程師

下一篇: CSS架構:最新最佳實踐(摘錄)

分享到: 更多
吉祥三公游戏下载 倍投方案 稳赚 北京pc28在线预测 龙虎预测软件免费 原创36码网址 网络mg电子游戏 pk10app计划软 11选五5技巧稳赚 分分中彩票 可以开房间的炸金花游戏 雪缘园即时比分 大乐透怎么加倍投注 腾讯分分彩计划软 二十一点游戏中文版 pk10冠军大小稳赢压发 买作弊器被骗的人多吗?