wxya（个人网站）🗒️工作量评估
type
status
slug
date
summary
tags
category
password
icon
如果时间紧急，领导要求紧急，提前沟通好；
能否根据价值安排优先级，先舍弃一部分，做好敏捷开发
能否为自己争取到一些福利待遇（没有加班费，年终奖不多发，自己还学不到东西，还要自己加班做，那就真的太牛马了）
做好沟通，最差劲别人起码也知道了，这工作量有风险，有预期管理。
我曾遇到过刚接手就问工作量（上面领导给我挡下来了，说先做一个技术组件有问题，先做一个切换；后来不断的修其他问题，做之前遗留需求几乎一个月过去了，没有人再提过这个事情）
还是要讲究实际科学，也许过几天大家就能理解难处了
科学的需求管理
- 需求完整度，是否成熟，可变更频率
- 提前过一遍，自己看好，该考虑细节不要忽略
- 细心细心再细心，扣需求完整读下来，多读几遍
- 是否经常变更？需要动态配置么？可扩展设计？
- 有没有组件化、通用化的需求？比如收口，其他功能也要做
- 是否需要埋点（商业化软件肯定需要的，不然运营、数分、增长、产运怎么做事情？好好考虑一下；作为开发者，也要去关注一下这些数据）
- 权限考虑，安全性（比如ipd的数据权限，prompt的维护权限，需要提前沟通好）
- 复杂程度（状态 和 需要处理的地方，复杂程度是倍数）
- 涉及项目数量（需要联合调试，提前订好规则，沟通好，这个很费时间）
- 项目熟悉程度（大概结构、做什么知不知道，遇到问题有没有对接人，对方是否好沟通）
- 技术栈熟悉程度（后端思维和前端有区别，如果是全栈直接放弃这条考虑）
- 性能考虑（比如主图生成视频，最后性能真拉跨，没有经验确实很难解决这个问题，前期也没有特别多的时间做mac和x86的测试，只能依靠历史经验了）比如涉及VCPU、KVM、contain、硬件解码
- 如果已经进入开发，且直接踩坑导致时间不足，重新评估一下（曾经有人说下午搞定，明天搞定，放了好几天的🐏sheep）并向相关人员解释（一定要做好沟通）
- 做一些功能设计，拆分实现步骤（胜兵先胜而后求战 败兵先战而后求胜）
- 部署方式（是否需要更改部署方式？简单部署还是有明显顺序？部署要谨慎谨慎再谨慎，饭碗没了就不好玩了，有备份总是没错的；王某曾经因多花0.1元没做备份，吓得一身冷汗）
上一篇
软件行业经验
下一篇
CR代码
Loading...