前端项目如何准确预估个人工时

看来很多小伙伴对这个问题感兴趣，大家不要忽视了压工时这个事。

1. 
   
2. 使他的KPI更好看
   
3. 不清楚做这个东西实际要多长时间
   
4. 因为第2点的原因，他也无法去争取合理时间
   
5. 部分人看着下属加班，有种大权在握，言出法随的畅快感
   

• 
  
• 无形中会打击你的自信心，当自信心全无的时候，要么是职业生涯结束，要么是变成人人都跑来拿捏一手的角色
  
• 轻易妥协，会让你的说的话，可信度降低。毕竟，别人随便说一下，激一下，你就妥协了，那很容易就让人觉得，你就是随意乱说一个时间
  
• 这会妨碍你对自己真实能力的认知和评估
  

• 
  
• 偶尔有少量任务，被压了少量工时，个人认为是可以接受的，毕竟不可能一切都能按规划走
  
• 大量工作被压工时，那就告知延期风险，你的工作速度应该保持不变，完不成，就让项目延期。如何解决延期问题？那是领导的事情，不是一个小码农应该操心的。
  

• 
  
• 首先，工作该是什么速度，就是什么速度，不要替领导着急着赶进度
  
• 其次，反馈这有延期风险，建议领导增派人手。（记得先和其他成员通个气）
  
• 该提加班就提加班，调休或加班工资是你应得的，累了就调休，你是人，不是机器
  

• 
  
• 加缓冲时间不是工作不饱和
  
• 8小时工作日，你不可能每分每秒都在写代码，谁也做不到。
  
• 你不可能熟悉每个API，总有要你查资料的时候，而查资料，可能你查了4-5个地方，才总结出正确用法，这需要额外的时间
  
• 你的工作随时可能被人打断，比如：开会，喝水，同事问你问题等等，这都会耗费你的时间
  
• 你拉取代码，提交代码，思考实现方式，和业务进一步确认需求细节，和UI沟通交互细节，自测，造mock数据，这都需要时间
  
• 如果没有缓冲时间，一个任务延期，可能会导致，后续N个任务都延期。
  
• 即使从项目角度分析，足够的缓冲时间，有利于降低项目延期风险
  

• 
  
• 比如：开会，比如插入了一个紧急工作任务，这种较长时间的打断，那就将这些被占用的时间，写进工作日志，即时向项目组反馈，要求原本的工作任务加工时或延迟开始
  
• 被同事问问题。几句话能说清楚的，那不妨和他直说。几句话说不清楚的，那只能等你有空的时候，再给他解答。要优先考虑完成自己的工作任务。
  

可能有的小伙伴，可能被别人激一下，被人以质疑的语句问一下，后续就被人牵着鼻子走了。有很大因素是因为不敢承认某方面的工作能力暂有欠缺。其实大方的承认即可，有问题，那就暴露问题，如果项目组其他成员会，那就让他来教你，这也属于沟通协作。如果没人会，那说明这是一个需要集思广益的公共问题。

可能有同学觉得自己就是个小码农甚至因为自己是外包，不敢发表自己的想法和见解，其实大可不必，只要你就事论事，有理有据，完全可以大方说出来，你不说出来，你永远只能从自己的角度看这个问题，你无法确认自己是对的还是错的。错了咱改，对了继续保持。既不贬低别人，也不看轻自己，以平常心讨论即可。

明确自己的定位，就是个普通码农，普通干活的，项目延期了，天塌了也是领导想办法解决。自己不会的就反馈，别人不会自己会的，那就友好分享。不会的，不要羞于请教。干不过来了，及时告知领导，让其协调解决。坦坦荡荡，不卑不亢。

1. 
   
2. 此方法是在没有技术阻碍的前提条件下预估，如果有技术障碍，请先解决技术阻碍
   
3. 此方法需要根据个人实际情况调整
   
4. 这里以普通的以vue,element-plus,axios为基础技术的管理系统为例
   
5. 这些都是个人见解，欢迎在评论区提出不同观点
   
6. 请先以一个普通的CRUD界面，测算自己的基本编码速度
   

• 
  
• 不要duang的一下，对整个界面/模块进行评估，应该对行列，表单项，逻辑点，进行评估，然后将总的时间加起来，就是这个界面的预估工时
  
• 要至少多估20%的时间，一个是因为你很难持续性的投入(比如：有人突然问你问题，上厕所，喝水，或有事请假)
  
• 请将一天的工作时间最多算6.5小时(因为你可能需要开会，可能被其他事情打断，可能有时不在状态，同时也算是给自己留点思考时间)
  
• 尽量不要在过了一遍需求之后，立马评估工时(不要被项目经理或业务的节奏带偏)，而是要自己再思考一遍需求，想想大概的实现逻辑，重难点等等，尽量不要当天给出工时评估
  
• 如果是给别人评估工时，那尽可能给别人多评点工时
  
• 工期紧的时候，加人有必要，但1个人干7天的活，7个人未必能1天干完
  
• 有公共组件和没有公共组件完成同样的功能，所需要的时间可能天差地别, 因此，请确保先完成公共组件的开发
  
• 请先将业务逻辑理顺，把工作进行拆分，直至自己能正确预估的范围内
  

• 
  
• 思考实现方式
  
• 静态UI界面还原与响应式
  
• 业务逻辑实现
  
• 动态UI交互
  
• 后端接口mock
  
• 后端接口对接
  
• 自测
  

1. 
   
2. 整体项目搭建以及规范与约束确认
   
3. 整体页面结构，路由结构搭建
   
4. 统一UI风格，以及公共组件实现
   
5. 具体的界面实现
   

1，2点应该由项目组长完成
3点应该由项目组长以及技术较强的组员共同完成

• 
  
• 敏捷开发就是强调一个快字
  
• 敏捷开发就是不断的压榨工时
  
• 敏捷开发就是不停的加班
  

• 
  
• 测试在项目之初就介入，编写完测试用例之后，共享给开发，方便开发自测
  
• 将一个完整的项目进行合理拆分，拆分为若干独立小迭代
  
• 每个小迭代完成之后，进行提测以及收集用户试用反馈，尽早反馈，以及尽早发现问题
  
• 在小迭代提测期间，应该让开发略作修整（改bug或修整）和总结(总结共性问题，避免下阶段，再重复出现这些共性问题)，而非让开发立马进入下阶段开发，否则容易造成，开发一边赶下阶段需求，一边赶上阶段bug
  
• 个人认为敏捷开发，重点在于敏捷，灵巧好掉头，分阶段交付，及早发现问题，拥抱需求变化。而非简单的抽着鞭子让程序员加班赶工996或007
  

如何精确评估开发时间的 4 个小套路？ - 知乎 (zhihu.com)