前端項(xiàng)目如何準(zhǔn)確預(yù)估個(gè)人工時(shí)

作者：悟空和大王

https://juejin.cn/post/7330071686489636904

分享一篇前端人員比較感興趣的話題，如何評(píng)估工時(shí)。

正文

看來(lái)很多小伙伴對(duì)這個(gè)問(wèn)題感興趣，大家不要忽視了壓工時(shí)這個(gè)事。

領(lǐng)導(dǎo)為什么會(huì)壓工時(shí)？

1. 使他的KPI更好看
2. 不清楚做這個(gè)東西實(shí)際要多長(zhǎng)時(shí)間
3. 因?yàn)榈?點(diǎn)的原因，他也無(wú)法去爭(zhēng)取合理時(shí)間
4. 部分人看著下屬加班，有種大權(quán)在握，言出法隨的暢快感

碼農(nóng)為什么不要輕易答應(yīng)壓工時(shí)?

• 無(wú)形中會(huì)打擊你的自信心，當(dāng)自信心全無(wú)的時(shí)候，要么是職業(yè)生涯結(jié)束，要么是變成人人都跑來(lái)拿捏一手的角色
• 輕易妥協(xié)，會(huì)讓你的說(shuō)的話，可信度降低。畢竟，別人隨便說(shuō)一下，激一下，你就妥協(xié)了，那很容易就讓人覺(jué)得，你就是隨意亂說(shuō)一個(gè)時(shí)間
• 這會(huì)妨礙你對(duì)自己真實(shí)能力的認(rèn)知和評(píng)估

被壓工時(shí)了怎么辦?

• 偶爾有少量任務(wù)，被壓了少量工時(shí)，個(gè)人認(rèn)為是可以接受的，畢竟不可能一切都能按規(guī)劃走
• 大量工作被壓工時(shí)，那就告知延期風(fēng)險(xiǎn)，你的工作速度應(yīng)該保持不變，完不成，就讓項(xiàng)目延期。如何解決延期問(wèn)題？那是領(lǐng)導(dǎo)的事情，不是一個(gè)小碼農(nóng)應(yīng)該操心的。

沒(méi)怎么壓工時(shí)，但把工作時(shí)間延長(zhǎng)了？

• 首先，工作該是什么速度，就是什么速度，不要替領(lǐng)導(dǎo)著急著趕進(jìn)度
• 其次，反饋這有延期風(fēng)險(xiǎn)，建議領(lǐng)導(dǎo)增派人手。（記得先和其他成員通個(gè)氣）
• 該提加班就提加班，調(diào)休或加班工資是你應(yīng)得的，累了就調(diào)休，你是人，不是機(jī)器

為什么要給自己留緩沖時(shí)間？加緩沖時(shí)間是工作不飽和？

• 加緩沖時(shí)間不是工作不飽和
• 8小時(shí)工作日，你不可能每分每秒都在寫代碼，誰(shuí)也做不到。
• 你不可能熟悉每個(gè)API，總有要你查資料的時(shí)候，而查資料，可能你查了4-5個(gè)地方，才總結(jié)出正確用法，這需要額外的時(shí)間
• 你的工作隨時(shí)可能被人打斷，比如：開(kāi)會(huì)，喝水，同事問(wèn)你問(wèn)題等等，這都會(huì)耗費(fèi)你的時(shí)間
• 你拉取代碼，提交代碼，思考實(shí)現(xiàn)方式，和業(yè)務(wù)進(jìn)一步確認(rèn)需求細(xì)節(jié)，和UI溝通交互細(xì)節(jié)，自測(cè)，造mock數(shù)據(jù)，這都需要時(shí)間
• 如果沒(méi)有緩沖時(shí)間，一個(gè)任務(wù)延期，可能會(huì)導(dǎo)致，后續(xù)N個(gè)任務(wù)都延期。
• 即使從項(xiàng)目角度分析，足夠的緩沖時(shí)間，有利于降低項(xiàng)目延期風(fēng)險(xiǎn)

工作總是被人打斷怎么辦？

• 比如：開(kāi)會(huì)，比如插入了一個(gè)緊急工作任務(wù)，這種較長(zhǎng)時(shí)間的打斷，那就將這些被占用的時(shí)間，寫進(jìn)工作日志，即時(shí)向項(xiàng)目組反饋，要求原本的工作任務(wù)加工時(shí)或延遲開(kāi)始
• 被同事問(wèn)問(wèn)題。幾句話能說(shuō)清楚的，那不妨和他直說(shuō)。幾句話說(shuō)不清楚的，那只能等你有空的時(shí)候，再給他解答。要優(yōu)先考慮完成自己的工作任務(wù)。

大方的承認(rèn)自己的不足，能力多大，就做多少事，明確自己的定位

可能有的小伙伴，可能被別人激一下，被人以質(zhì)疑的語(yǔ)句問(wèn)一下，后續(xù)就被人牽著鼻子走了。有很大因素是因?yàn)椴桓页姓J(rèn)某方面的工作能力暫有欠缺。其實(shí)大方的承認(rèn)即可，有問(wèn)題，那就暴露問(wèn)題，如果項(xiàng)目組其他成員會(huì)，那就讓他來(lái)教你，這也屬于溝通協(xié)作。如果沒(méi)人會(huì)，那說(shuō)明這是一個(gè)需要集思廣益的公共問(wèn)題。

可能有同 學(xué)覺(jué)得自己就是個(gè)小碼農(nóng)甚至因?yàn)樽约菏峭獍?，不敢發(fā)表自己的想法和見(jiàn)解，其實(shí)大可不必，只要你就事論事，有理有據(jù)，完全可以大方說(shuō)出來(lái)，你不說(shuō)出來(lái)，你永遠(yuǎn)只能從自己的角度看這個(gè)問(wèn)題，你無(wú)法確認(rèn)自己是對(duì)的還是錯(cuò)的。 錯(cuò)了咱改，對(duì)了繼續(xù)保持。 既不貶低別人，也不看輕自己，以平常心討論即可。

明確自己的定位，就是個(gè)普通碼農(nóng)，普通干活的，項(xiàng)目延期了，天塌了也是領(lǐng)導(dǎo)想辦法解決。自己不會(huì)的就反饋，別人不會(huì)自己會(huì)的，那就友好分享。不會(huì)的，不要羞于請(qǐng)教。干不過(guò)來(lái)了，及時(shí)告知領(lǐng)導(dǎo)，讓其協(xié)調(diào)解決。坦坦蕩蕩，不卑不亢。

前提

1. 此方法是在沒(méi)有技術(shù)阻礙的前提條件下預(yù)估，如果有技術(shù)障礙，請(qǐng)先解決技術(shù)阻礙
2. 此方法需要根據(jù)個(gè)人實(shí)際情況調(diào)整
3. 這里以普通的以vue,element-plus,axios為基礎(chǔ)技術(shù)的管理系統(tǒng)為例
4. 這些都是個(gè)人見(jiàn)解，歡迎在評(píng)論區(qū)提出不同觀點(diǎn)
5. 請(qǐng)先以一個(gè)普通的CRUD界面，測(cè)算自己的基本編碼速度

為啥評(píng)估會(huì)不準(zhǔn)確

自我評(píng)估時(shí)

領(lǐng)導(dǎo)給你評(píng)估時(shí)

功能	領(lǐng)導(dǎo)認(rèn)為的	領(lǐng)導(dǎo)忘記的	領(lǐng)導(dǎo)認(rèn)為的時(shí)間	實(shí)際時(shí)間
加個(gè)字段	加個(gè)顯示字段而已，實(shí)際只要3分鐘吧	碼農(nóng)要找到對(duì)應(yīng)代碼，查看代碼上下文，或許還涉及樣式的修改，后端接口可能還沒(méi)有這個(gè)字段, 還要自測(cè)	20分鐘	2小時(shí)
做個(gè)純列表頁(yè)面	前端只要把后端的字段顯示出來(lái)就好了吧，肯定會(huì)很快	可能沒(méi)有直接可用的組件，即使有，前端可能需要查組件文檔，看具體用法, 還得處理loading狀態(tài)，空狀態(tài)，然后還得查看后端接口文檔，看哪些字段需要額外處理，最后還得自測(cè)，甚至可能在真正對(duì)接前，需要自己造mock接口	2小時(shí)	8小時(shí)
編輯/新增界面	就寫個(gè)表單，前端把數(shù)據(jù)提交給后端就完事了	前端需要理解業(yè)務(wù)邏輯，需要做數(shù)據(jù)校驗(yàn)，對(duì)于類似下拉數(shù)據(jù)，圖片上傳，可能還要和后端溝通，數(shù)據(jù)從哪里取，分別表示什么意思，怎么上傳圖片，提交數(shù)據(jù)后，成功后要怎么做，以及失敗的異常處理，用戶填了一半數(shù)據(jù)之后，刷新了界面，應(yīng)該如何處理，后端接口沒(méi)出來(lái)前，需要自己mock接口，用來(lái)自測(cè)	4小時(shí)	3天
一個(gè)響應(yīng)式界面	就一個(gè)普通界面應(yīng)該不至于有什么難度吧	忽略了這是一個(gè)響應(yīng)式界面，前端需要與UI設(shè)計(jì)師溝通，確認(rèn)在不同情況，界面如何響應(yīng)，以及思考如何實(shí)現(xiàn)，如果業(yè)務(wù)數(shù)據(jù)還會(huì)對(duì)界面的響應(yīng)式產(chǎn)生影響，那還得進(jìn)一步深入分析	8小時(shí)	3天
實(shí)現(xiàn)多語(yǔ)言功能	多語(yǔ)言，不就是用編碼代替原本的文字嘛，根本不需要額外的時(shí)間處理吧	前端需要考慮多語(yǔ)言數(shù)據(jù)從哪里來(lái)，多語(yǔ)言切換之后對(duì)原本布局的影響，多語(yǔ)言切換之后，表單錯(cuò)誤提示的處理方式	不給額外時(shí)間	3-4天
做個(gè)3/4環(huán)	直接使用圖表插件，調(diào)下API就出來(lái)了	前端可能需要進(jìn)行數(shù)據(jù)轉(zhuǎn)換，需要查看圖表插件的文檔，圖表插件可能沒(méi)有現(xiàn)成的，需要通過(guò)搜索引擎找類似的示例，然后模仿實(shí)現(xiàn)，甚至圖表插件根本無(wú)法實(shí)現(xiàn)這種效果，需要用其他技術(shù)實(shí)現(xiàn)	3小時(shí)	4天
前期一個(gè)連續(xù)的類似界面	上一個(gè)界面和這個(gè)類似，把上個(gè)界面的代碼復(fù)制過(guò)來(lái)，改改字段和接口，應(yīng)該能很快完成	很多界面看著一樣，但實(shí)際業(yè)務(wù)邏輯差別很大，只是界面表現(xiàn)形式類似，有些字段是動(dòng)態(tài)顯示/隱藏的，有些可以固定寫，表單字段的驗(yàn)證邏輯，可能也不一樣。并且上一個(gè)界面的代碼都還沒(méi)寫，還沒(méi)測(cè)試，這里還有很多不確定因素，直接復(fù)制還可能導(dǎo)致，同一個(gè)錯(cuò)誤，在多個(gè)界面同時(shí)出現(xiàn)	2-3小時(shí)	前一個(gè)界面花了多久，這個(gè)界面可能還是花了差不多的時(shí)間
仿照xx官網(wǎng)的效果，做個(gè)靜態(tài)界面	好多網(wǎng)站都是這個(gè)效果，這應(yīng)該是爛大街的效果吧	某個(gè)效果可能是知識(shí)盲區(qū)，需要查資料	2天	1周，甚至可能做不了
參考公司內(nèi)部其他系統(tǒng)界面，實(shí)現(xiàn)類似界面	現(xiàn)成的東西，這系統(tǒng)也上線好久了，應(yīng)該把代碼復(fù)制過(guò)來(lái)，稍微改改就OK了吧	當(dāng)前這個(gè)人從未接觸過(guò)這個(gè)系統(tǒng)，對(duì)這個(gè)系統(tǒng)一點(diǎn)都不了解，了解需要時(shí)間，可能另外的項(xiàng)目有自己的框架，和當(dāng)前系統(tǒng)的框架不同，無(wú)法直接使用, 另外一個(gè)項(xiàng)目無(wú)法直接給項(xiàng)目代碼給你，只能讓人給你講解，但講解人沒(méi)時(shí)間或不是隨時(shí)都有時(shí)間，或就是隨意講講，另一個(gè)項(xiàng)目的這個(gè)界面，可能是經(jīng)過(guò)多人集思廣益，多輪討論與重構(gòu)才最終得到了這個(gè)效果	5小時(shí)	3-5天
用低代碼平臺(tái)實(shí)現(xiàn)個(gè)界面	就是拖拖組件的事情，代碼都不用寫，應(yīng)該很快	組件可能沒(méi)有，有組件可能某些業(yè)務(wù)邏輯在這個(gè)低代碼平臺(tái)難以實(shí)現(xiàn)，需要咨詢低代碼平臺(tái)的提供方，但低代碼提供方，幾個(gè)人需要服務(wù)幾十個(gè)人，無(wú)法優(yōu)先給你解答，即使解答了，可能給出的方案不通用(或者他們還需要繼續(xù)問(wèn)他們內(nèi)部團(tuán)隊(duì)的人)，遇到下個(gè)類似的情況，原來(lái)的解決方案又無(wú)效了。難以調(diào)試或無(wú)法調(diào)試，前端原本的知識(shí)儲(chǔ)備，在低代碼平臺(tái)，僅剩原始的js語(yǔ)法有效	2天	3周

總原則

• 不要duang的一下，對(duì)整個(gè)界面/模塊進(jìn)行評(píng)估，應(yīng)該對(duì)行列，表單項(xiàng)，邏輯點(diǎn)，進(jìn)行評(píng)估，然后將總的時(shí)間加起來(lái)，就是這個(gè)界面的預(yù)估工時(shí)
• 要至少多估20%的時(shí)間，一個(gè)是因?yàn)槟愫茈y持續(xù)性的投入(比如：有人突然問(wèn)你問(wèn)題，上廁所，喝水，或有事請(qǐng)假)
• 請(qǐng)將一天的工作時(shí)間最多算6.5小時(shí)(因?yàn)槟憧赡苄枰_(kāi)會(huì)，可能被其他事情打斷，可能有時(shí)不在狀態(tài)，同時(shí)也算是給自己留點(diǎn)思考時(shí)間)
• 盡量不要在過(guò)了一遍需求之后，立馬評(píng)估工時(shí)(不要被項(xiàng)目經(jīng)理或業(yè)務(wù)的節(jié)奏帶偏)，而是要自己再思考一遍需求，想想大概的實(shí)現(xiàn)邏輯，重難點(diǎn)等等，盡量不要當(dāng)天給出工時(shí)評(píng)估
• 如果是給別人評(píng)估工時(shí)，那盡可能給別人多評(píng)點(diǎn)工時(shí)
• 工期緊的時(shí)候，加人有必要，但1個(gè)人干7天的活，7個(gè)人未必能1天干完
• 有公共組件和沒(méi)有公共組件完成同樣的功能，所需要的時(shí)間可能天差地別, 因此，請(qǐng)確保先完成公共組件的開(kāi)發(fā)
• 請(qǐng)先將業(yè)務(wù)邏輯理順，把工作進(jìn)行拆分，直至自己能正確預(yù)估的范圍內(nèi)

前端有哪些地方需要耗費(fèi)工時(shí)

• 思考實(shí)現(xiàn)方式
• 靜態(tài)UI界面還原與響應(yīng)式
• 業(yè)務(wù)邏輯實(shí)現(xiàn)
• 動(dòng)態(tài)UI交互
• 后端接口mock
• 后端接口對(duì)接
• 自測(cè)

前端項(xiàng)目應(yīng)該分成幾步實(shí)現(xiàn)

1. 整體項(xiàng)目搭建以及規(guī)范與約束確認(rèn)
2. 整體頁(yè)面結(jié)構(gòu)，路由結(jié)構(gòu)搭建
3. 統(tǒng)一UI風(fēng)格，以及公共組件實(shí)現(xiàn)
4. 具體的界面實(shí)現(xiàn)

1，2點(diǎn)應(yīng)該由項(xiàng)目組長(zhǎng)完成 3點(diǎn)應(yīng)該由項(xiàng)目組長(zhǎng)以及技術(shù)較強(qiáng)的組員共同完成

常見(jiàn)的公共組件工時(shí)

組件	工時(shí)
查詢按鈕	60 分鐘
提交按鈕	60 分鐘
confirm按鈕	60 分鐘
下拉按鈕	60 分鐘
分頁(yè)表格	360 分鐘
JSON配置分頁(yè)表格	240 分鐘
動(dòng)態(tài)表單	360 分鐘
JSON動(dòng)態(tài)表單	360 分鐘
模態(tài)框	90 分鐘
抽屜組件	90 分鐘
select組件	90 分鐘
tree組件	120 分鐘
cascade組件	90 分鐘
日期選擇組件	60 分鐘
日期范圍選擇組件	120 分鐘
axios封裝	360 分鐘
卡片組件	60 分鐘
面包屑組件	60 分鐘

列表頁(yè)拆分與編碼工時(shí)預(yù)估

image.png

首先做總體拆分，分成3大部分

1. 頭部的搜索表單

image.png

每個(gè)表單項(xiàng)30分鐘左右，每個(gè)功能按鈕40分鐘左右

因此這里是1個(gè)表單項(xiàng)（30分鐘），2個(gè)功能按鈕(80分鐘)，總計(jì)110分鐘

1. 中間的工具欄

image.png

P.S. 這里沒(méi)算右側(cè)工具條，只算了左側(cè)功能按鈕

因?yàn)槭橇斜眄?yè)，添加角色這個(gè)按鈕，只考慮是個(gè)簡(jiǎn)單按鈕加個(gè)點(diǎn)擊事件，至于點(diǎn)擊按鈕之后的角色添加界面的工時(shí)不放在列表頁(yè)評(píng)估，而是在添加角色界面單獨(dú)評(píng)估，因此添加角色按鈕算30分鐘

批量操作按鈕，應(yīng)該使用公共組件的下拉按鈕組件，以及與分頁(yè)表格組件配合實(shí)現(xiàn)，因此算40-60分鐘

因此這里整體應(yīng)該總計(jì)在70分鐘內(nèi)

1. 主體的分頁(yè)表格

應(yīng)該使用公共組件的分頁(yè)表格組件實(shí)現(xiàn)

• 普通列（直接顯示字段值的列，和簡(jiǎn)單轉(zhuǎn)換的列）每列算20分鐘
• 操作列按每個(gè)操作按鈕另算
• 復(fù)雜轉(zhuǎn)換列按40-60分鐘算
• 排序列按40-60分鐘算
• 分頁(yè)表格組件調(diào)用30分鐘

從界面看，這里有6列，checkbox列和序號(hào)列，是分頁(yè)表格組件實(shí)現(xiàn)的，無(wú)需再算工時(shí)，除操作列和創(chuàng)建時(shí)間外，其他都屬于普通列算20分鐘每列，創(chuàng)建時(shí)間列算40分鐘，因此總共100分鐘

操作列角色成員，角色權(quán)限和修改，都需要打開(kāi)一個(gè)抽屜界面（抽屜界面里的東西另算，不算在列表頁(yè)中），刪除需要調(diào)后端接口以及確認(rèn)，因此

• 角色成員按鈕: 20分鐘
• 角色權(quán)限按鈕: 20分鐘
• 修改按鈕: 20分鐘
• 刪除按鈕: 30分鐘

總計(jì): 100 + 20*3 + 30 = 190分鐘

因此整個(gè)列表頁(yè)工時(shí)

列表頁(yè)需要mock 1個(gè)接口，列表接口，算20分鐘

110 + 70 + 190 + 20 = 390 分鐘 = 6.5小時(shí)

再在390分鐘的基礎(chǔ)上再多加20% = 390*1.2 = 468 分鐘 = 7.8 小時(shí)

P.S.

1. 添加角色/角色成員/角色權(quán)限這是獨(dú)立界面，需要單獨(dú)計(jì)算時(shí)間。計(jì)算方式也與上面的類似
2. 沒(méi)有單獨(dú)計(jì)算自測(cè)時(shí)間，個(gè)人認(rèn)為理想情況應(yīng)該對(duì)1個(gè)界面，加2-3小時(shí)自測(cè)時(shí)間
3. 沒(méi)有計(jì)算聯(lián)調(diào)時(shí)間，聯(lián)調(diào)時(shí)間應(yīng)該另算
4. 沒(méi)有計(jì)算UI還原時(shí)間，對(duì)于復(fù)雜UI界面或UI還原度要求高的界面，應(yīng)該單獨(dú)計(jì)算UI還原時(shí)間
5. 對(duì)于復(fù)雜的業(yè)務(wù)邏輯，可以將業(yè)務(wù)邏輯拆解為一條條的業(yè)務(wù)邏輯項(xiàng)，每個(gè)業(yè)務(wù)邏輯項(xiàng)以40分鐘左右每條作為參考實(shí)現(xiàn)時(shí)間
6. 沒(méi)有考慮思考時(shí)間，對(duì)于復(fù)雜的業(yè)務(wù)邏輯，或者沒(méi)做過(guò)的界面形態(tài)，或者復(fù)雜的界面形態(tài)等，必須將思考時(shí)間計(jì)算進(jìn)來(lái)，或者說(shuō)，在已經(jīng)基本想明白怎么去實(shí)現(xiàn)的基礎(chǔ)上，再去評(píng)估工時(shí)

被誤解的敏捷開(kāi)發(fā)模式

錯(cuò)誤的敏捷開(kāi)發(fā)

• 敏捷開(kāi)發(fā)就是強(qiáng)調(diào)一個(gè)快字
• 敏捷開(kāi)發(fā)就是不斷的壓榨工時(shí)
• 敏捷開(kāi)發(fā)就是不停的加班

正確的敏捷開(kāi)發(fā)

• 測(cè)試在項(xiàng)目之初就介入，編寫完測(cè)試用例之后，共享給開(kāi)發(fā)，方便開(kāi)發(fā)自測(cè)
• 將一個(gè)完整的項(xiàng)目進(jìn)行合理拆分，拆分為若干獨(dú)立小迭代
• 每個(gè)小迭代完成之后，進(jìn)行提測(cè)以及收集用戶試用反饋，盡早反饋，以及盡早發(fā)現(xiàn)問(wèn)題
• 在小迭代提測(cè)期間，應(yīng)該讓開(kāi)發(fā)略作修整（改bug或修整）和總結(jié)(總結(jié)共性問(wèn)題，避免下階段，再重復(fù)出現(xiàn)這些共性問(wèn)題)，而非讓開(kāi)發(fā)立馬進(jìn)入下階段開(kāi)發(fā)，否則容易造成，開(kāi)發(fā)一邊趕下階段需求，一邊趕上階段bug
• 個(gè)人認(rèn)為敏捷開(kāi)發(fā)，重點(diǎn)在于敏捷，靈巧好掉頭，分階段交付，及早發(fā)現(xiàn)問(wèn)題，擁抱需求變化。而非簡(jiǎn)單的抽著鞭子讓程序員加班趕工996或007

相關(guān)文章

如何精確評(píng)估開(kāi)發(fā)時(shí)間的 4 個(gè)小套路？- 知乎 (zhihu.com) [1]

推薦閱讀  點(diǎn)擊標(biāo)題可跳轉(zhuǎn)

1、兩年經(jīng)驗(yàn)前端社招中大廠面經(jīng)（下）

2、Three.js 快速入門指南

3、談判 Offer 的十條準(zhǔn)則(下)