在软件工程中，工作量评估是一件吃力、艰难、认真做又怕浪费力气、敷衍做又不好向 leader 交代的事情。正所谓一千个人眼里有一千个哈姆雷特，同一个项目，给不同人评估，往往会得出不同的答案。
假设准备启动业务提出的一个需求项目：
- 有硬 deadline 限制（譬如响应政策、配合外部环境整改、leader 不切实际的拍板），deadline 不会变，还估啥工作量，正常干不完的该 996 得 996（多数情况下加班比项目组加人管用多了）。
- 无硬 deadline 限制（譬如为了抢占市场、优化、改善性项目），无论最后估多少，正常该干多久，就干多久。
如果把评估工作量环节去掉，项目开发流程会有啥不一样呢？
可能出现的现象
- leader 不安心。leader 总是想知道项目何时能上线，要占用多少人力成本。
项目的上线时间交给项目团队定，除非 leader 亲身参与项目细节里头，这样就可以对项目上线时间做评估。要占用的人力成本就更不用担心了，业务部门提出的需求一般都是价值优先。如果以成本优先，那就只做最低成本的需求便可，有没有市场价值就不用管了，这明显就是一种不合理的方式。用最优的力量，做最高价值的项目。IT 部门主要项目分析可行性便可，除非 IT 部门做了一个比业务更加专业的市场调查来打业务的脸。
- 员工不上心。既然一些项目上线时间可以由 IT 团队定，那就慢慢做。
这是人之常情，就像做暑假作业，有几个人不是最后几天赶出来的？不过，如果频繁地做作业检查，相信情况会好很多。那如何保证项目进度？以下借鉴几个 scrum 技巧
1. 任务公开化可视化
把项目分解成一系列小任务，排个优先级，先做啥后做啥，找个墙或者小白板，写上小纸条，贴在待办区域里。
团队成员各自领取任务（团队 leader 分派也行），贴到开发区域。
2. 每日站会
每天找个固定的时间团队一起开个小会议，时间不用长，15 分钟以内吧，记得是站着开。每个人说一下任务的新进展和遇到的问题。把完成的任务移动到完成区域，然后再领或派一个新任务。
3. 定期展示成果
口说无凭，软件说话。隔个一两周，把大家叫到会议室时运行一下各自的代码。如果两次展示之间没有进展，负责的程序丸在每日站会上又没有报问题，那就要检查一下出了什么状况，及时纠正项目进度。
去掉工作量评估这一环节，省掉了不少事务性工作时间，只要增加项目的频繁返馈，再建立尽快交付价值的团队目标。
业务只需安排好项目优先级，IT 只需努力尽快实现业务价值，做完一个项目，再挑一个优先级最高的做，保证在做的永远都是当前最有价值的事情。
最后随便扯一下，项目是并行做好，还是串行做好？
如果一个团队接到不止一个项目，先保证优先级最高的项目得到最有效的投入，保证可以尽快向业务交付价值。
譬如团队接到三个项目（不能出现项目优先级相同的不按套路出牌的情况），如果并行开发，6 个月后三个项目同时期上线了。如果串行发，2 个月后上线优先级最高的项目，4 个月后上线优先级次高的项目，6 个月后上线优先级最低的项目。
别以为一个团队并行开发项目效率总会比串行高，就像一个人左手画圆，同时右手画方，结果画出来圆不是很圆，方又不是很方。
以上观点自知肤浅，旨在探讨软件工程，抛砖引玉。