领导为什么会压工时?
-
使他的KPI更好看
-
不清楚做这个东西实际要多长时间
-
因为第2点的原因,他也无法去争取合理时间
-
部分人看着下属加班,有种大权在握,言出法随的畅快感
码农为什么不要轻易答应压工时?
-
无形中会打击你的自信心,当自信心全无的时候,要么是职业生涯结束,要么是变成人人都跑来拿捏一手的角色
-
轻易妥协,会让你的说的话,可信度降低。毕竟,别人随便说一下,激一下,你就妥协了,那很容易就让人觉得,你就是随意乱说一个时间
-
这会妨碍你对自己真实能力的认知和评估
被压工时了怎么办?
-
偶尔有少量任务,被压了少量工时,个人认为是可以接受的,毕竟不可能一切都能按规划走
-
大量工作被压工时,那就告知延期风险,你的工作速度应该保持不变,完不成,就让项目延期。如何解决延期问题?那是领导的事情,不是一个小码农应该操心的。
没怎么压工时,但把工作时间延长了?
-
首先,工作该是什么速度,就是什么速度,不要替领导着急着赶进度
-
其次,反馈这有延期风险,建议领导增派人手。(记得先和其他成员通个气)
-
该提加班就提加班,调休或加班工资是你应得的,累了就调休,你是人,不是机器
为什么要给自己留缓冲时间?加缓冲时间是工作不饱和?
-
加缓冲时间不是工作不饱和
-
8小时工作日,你不可能每分每秒都在写代码,谁也做不到。
-
你不可能熟悉每个API,总有要你查资料的时候,而查资料,可能你查了4-5个地方,才总结出正确用法,这需要额外的时间
-
你的工作随时可能被人打断,比如:开会,喝水,同事问你问题等等,这都会耗费你的时间
-
你拉取代码,提交代码,思考实现方式,和业务进一步确认需求细节,和UI沟通交互细节,自测,造mock数据,这都需要时间
-
如果没有缓冲时间,一个任务延期,可能会导致,后续N个任务都延期。
-
即使从项目角度分析,足够的缓冲时间,有利于降低项目延期风险
工作总是被人打断怎么办?
-
比如:开会,比如插入了一个紧急工作任务,这种较长时间的打断,那就将这些被占用的时间,写进工作日志,即时向项目组反馈,要求原本的工作任务加工时或延迟开始
-
被同事问问题。几句话能说清楚的,那不妨和他直说。几句话说不清楚的,那只能等你有空的时候,再给他解答。要优先考虑完成自己的工作任务。
大方的承认自己的不足,能力多大,就做多少事,明确自己的定位
可能有的小伙伴,可能被别人激一下,被人以质疑的语句问一下,后续就被人牵着鼻子走了。有很大因素是因为不敢承认某方面的工作能力暂有欠缺。其实大方的承认即可,有问题,那就暴露问题,如果项目组其他成员会,那就让他来教你,这也属于沟通协作。如果没人会,那说明这是一个需要集思广益的公共问题。
可能有同学觉得自己就是个小码农甚至因为自己是外包,不敢发表自己的想法和见解,其实大可不必,只要你就事论事,有理有据,完全可以大方说出来,你不说出来,你永远只能从自己的角度看这个问题,你无法确认自己是对的还是错的。错了咱改,对了继续保持。既不贬低别人,也不看轻自己,以平常心讨论即可。
明确自己的定位,就是个普通码农,普通干活的,项目延期了,天塌了也是领导想办法解决。自己不会的就反馈,别人不会自己会的,那就友好分享。不会的,不要羞于请教。干不过来了,及时告知领导,让其协调解决。坦坦荡荡,不卑不亢。
前提
-
此方法是在没有技术阻碍的前提条件下预估,如果有技术障碍,请先解决技术阻碍
-
此方法需要根据个人实际情况调整
-
这里以普通的以vue,element-plus,axios为基础技术的管理系统为例
-
这些都是个人见解,欢迎在评论区提出不同观点
-
请先以一个普通的CRUD界面,测算自己的基本编码速度
自我评估时
领导给你评估时
总原则
-
不要duang的一下,对整个界面/模块进行评估,应该对行列,表单项,逻辑点,进行评估,然后将总的时间加起来,就是这个界面的预估工时
-
要至少多估20%的时间,一个是因为你很难持续性的投入(比如:有人突然问你问题,上厕所,喝水,或有事请假)
-
请将一天的工作时间最多算6.5小时(因为你可能需要开会,可能被其他事情打断,可能有时不在状态,同时也算是给自己留点思考时间)
-
尽量不要在过了一遍需求之后,立马评估工时(不要被项目经理或业务的节奏带偏),而是要自己再思考一遍需求,想想大概的实现逻辑,重难点等等,尽量不要当天给出工时评估
-
如果是给别人评估工时,那尽可能给别人多评点工时
-
工期紧的时候,加人有必要,但1个人干7天的活,7个人未必能1天干完
-
有公共组件和没有公共组件完成同样的功能,所需要的时间可能天差地别, 因此,请确保先完成公共组件的开发
-
请先将业务逻辑理顺,把工作进行拆分,直至自己能正确预估的范围内
前端有哪些地方需要耗费工时
-
思考实现方式
-
静态UI界面还原与响应式
-
业务逻辑实现
-
动态UI交互
-
后端接口mock
-
后端接口对接
-
自测
前端项目应该分成几步实现
-
整体项目搭建以及规范与约束确认
-
整体页面结构,路由结构搭建
-
统一UI风格,以及公共组件实现
-
具体的界面实现
1,2点应该由项目组长完成 3点应该由项目组长以及技术较强的组员共同完成
常见的公共组件工时
列表页拆分与编码工时预估
首先做总体拆分,分成3大部分
1、头部的搜索表单
每个表单项30分钟左右,每个功能按钮40分钟左右
因此这里是1个表单项(30分钟),2个功能按钮(80分钟),总计110分钟
2、中间的工具栏
P.S. 这里没算右侧工具条,只算了左侧功能按钮
因为是列表页,添加角色
这个按钮,只考虑是个简单按钮加个点击事件,至于点击按钮之后的角色添加界面的工时不放在列表页评估,而是在添加角色界面单独评估,因此添加角色
按钮算30分钟
批量操作按钮,应该使用公共组件的下拉按钮组件,以及与分页表格组件配合实现,因此算40-60分钟
因此这里整体应该总计在70分钟内
3、主体的分页表格
应该使用公共组件的分页表格组件实现
-
普通列(直接显示字段值的列,和简单转换的列)每列算20分钟
-
操作列按每个操作按钮另算
-
复杂转换列按40-60分钟算
-
排序列按40-60分钟算
-
分页表格组件调用30分钟
从界面看,这里有6列,checkbox列和序号列,是分页表格组件实现的,无需再算工时,除操作列和创建时间外,其他都属于普通列算20分钟每列,创建时间列算40分钟,因此总共100分钟
操作列角色成员,角色权限和修改,都需要打开一个抽屉界面(抽屉界面里的东西另算,不算在列表页中),删除需要调后端接口以及确认,因此
-
角色成员按钮
: 20分钟 -
角色权限按钮
: 20分钟 -
修改按钮
: 20分钟 -
删除按钮
: 30分钟
总计: 100 + 20*3 + 30 = 190分钟
因此整个列表页工时
列表页需要mock 1个接口,列表接口,算20分钟
110 + 70 + 190 + 20 = 390 分钟 = 6.5小时
再在390分钟的基础上再多加20% = 390*1.2 = 468 分钟 = 7.8 小时
P.S.
-
添加角色/角色成员/角色权限这是独立界面,需要单独计算时间。计算方式也与上面的类似
-
没有单独计算自测时间,个人认为理想情况应该对1个界面,加2-3小时自测时间
-
没有计算联调时间,联调时间应该另算
-
没有计算UI还原时间,对于复杂UI界面或UI还原度要求高的界面,应该单独计算UI还原时间
-
对于复杂的业务逻辑,可以将业务逻辑拆解为一条条的业务逻辑项,每个业务逻辑项以40分钟左右每条作为参考实现时间
-
没有考虑思考时间,对于复杂的业务逻辑,或者没做过的界面形态,或者复杂的界面形态等,必须将思考时间计算进来,或者说,在已经基本想明白怎么去实现的基础上,再去评估工时
被误解的敏捷开发模式
错误的敏捷开发
-
敏捷开发就是强调一个快字
-
敏捷开发就是不断的压榨工时
-
敏捷开发就是不停的加班
正确的敏捷开发
-
测试在项目之初就介入,编写完测试用例之后,共享给开发,方便开发自测
-
将一个完整的项目进行合理拆分,拆分为若干独立小迭代
-
每个小迭代完成之后,进行提测以及收集用户试用反馈,尽早反馈,以及尽早发现问题
-
在小迭代提测期间,应该让开发略作修整(改bug或修整)和总结(总结共性问题,避免下阶段,再重复出现这些共性问题),而非让开发立马进入下阶段开发,否则容易造成,开发一边赶下阶段需求,一边赶上阶段bug
-
个人认为敏捷开发,重点在于敏捷,灵巧好掉头,分阶段交付,及早发现问题,拥抱需求变化。而非简单的抽着鞭子让程序员加班赶工996或007