🗒️工作量评估

type
status
slug
date
tags
summary
category
password
icon
如果时间紧急,领导要求紧急,提前沟通好;
能否根据价值安排优先级,先舍弃一部分,做好敏捷开发
能否为自己争取到一些福利待遇(没有加班费,年终奖不多发,自己还学不到东西,还要自己加班做,那就真的太牛马了)
做好沟通,最差劲别人起码也知道了,这工作量有风险,有预期管理。
我曾遇到过刚接手就问工作量(上面领导给我挡下来了,说先做一个技术组件有问题,先做一个切换;后来不断的修其他问题,做之前遗留需求几乎一个月过去了,没有人再提过这个事情)
还是要讲究实际科学,也许过几天大家就能理解难处了
科学的需求管理

 
  1. 需求完整度,是否成熟,可变更频率
  1. 提前过一遍,自己看好,该考虑细节不要忽略
  1. 细心细心再细心,扣需求完整读下来,多读几遍
  1. 是否经常变更?需要动态配置么?可扩展设计?
  1. 有没有组件化、通用化的需求?比如收口,其他功能也要做
  1. 是否需要埋点(商业化软件肯定需要的,不然运营、数分、增长、产运怎么做事情?好好考虑一下;作为开发者,也要去关注一下这些数据)
  1. 权限考虑,安全性(比如ipd的数据权限,prompt的维护权限,需要提前沟通好)
  1. 复杂程度(状态 和 需要处理的地方,复杂程度是倍数)
  1. 涉及项目数量(需要联合调试,提前订好规则,沟通好,这个很费时间)
  1. 项目熟悉程度(大概结构、做什么知不知道,遇到问题有没有对接人,对方是否好沟通)
  1. 技术栈熟悉程度(后端思维和前端有区别,如果是全栈直接放弃这条考虑)
  1. 性能考虑(比如主图生成视频,最后性能真拉跨,没有经验确实很难解决这个问题,前期也没有特别多的时间做mac和x86的测试,只能依靠历史经验了)比如涉及VCPU、KVM、contain、硬件解码
  1. 如果已经进入开发,且直接踩坑导致时间不足,重新评估一下(曾经有人说下午搞定,明天搞定,放了好几天的🐏sheep)并向相关人员解释(一定要做好沟通)
  1. 做一些功能设计,拆分实现步骤(胜兵先胜而后求战 败兵先战而后求胜)
  1. 部署方式(是否需要更改部署方式?简单部署还是有明显顺序?部署要谨慎谨慎再谨慎,饭碗没了就不好玩了,有备份总是没错的;王某曾经因多花0.1元没做备份,吓得一身冷汗)
上一篇
CR代码
下一篇
MFA 2MFA TOTP
Loading...
目录
文章列表
王小扬博客
Git
AI
产品
film
AI Code
Java
其他
计算机网络
DB
云原生
Node
Docker
操作系统
Elasticsearch
Apollo
Nestjs
Think
大前端
PHP
软件开发
设计
生活技巧
CI
缓存