如果抛掉软件工程中的工作量评估

在软件工程中，工作量评估是一件吃力、艰难、认真做又怕浪费力气、敷衍做又不好向leader交代的事情。正所谓一千个人眼里有一千个哈姆雷特，同一个项目，给不同人评估，往往会得出不同的答案。

假设准备启动业务提出的一个需求项目：

• 有硬deadline限制（譬如响应政策、配合外部环境整改、leader不切实际的拍板），deadline不会变，还估啥工作量，正常干不完的该996得996（多数情况下加班比项目组加人管用多了）。
• 无硬deadline限制（譬如为了抢占市场、优化、改善性项目），无论最后估多少，正常该干多久，就干多久。

如果把评估工作量环节去掉，项目开发流程会有啥不一样呢？

---

可能出现的现象

---

• leader不安心。leader总是想知道项目何时能上线，要占用多少人力成本。

---

项目的上线时间交给项目团队定，除非leader亲身参与项目细节里头，这样就可以对项目上线时间做评估。要占用的人力成本就更不用担心了，业务部门提出的需求一般都是价值优先。如果以成本优先，那就只做最低成本的需求便可，有没有市场价值就不用管了，这明显就是一种不合理的方式。用最优的力量，做最高价值的项目。IT部门主要项目分析可行性便可，除非IT部门做了一个比业务更加专业的市场调查来打业务的脸。

---

• 员工不上心。既然一些项目上线时间可以由IT团队定，那就慢慢做。

---

这是人之常情，就像做暑假作业，有几个人不是最后几天赶出来的？不过，如果频繁地做作业检查，相信情况会好很多。那如何保证项目进度？以下借鉴几个scrum技巧

1.任务公开化可视化

把项目分解成一系列小任务，排个优先级，先做啥后做啥，找个墙或者小白板，写上小纸条，贴在待办区域里。

团队成员各自领取任务（团队leader分派也行），贴到开发区域。

2.每日站会

每天找个固定的时间团队一起开个小会议，时间不用长，15分钟以内吧，记得是站着开。每个人说一下任务的新进展和遇到的问题。把完成的任务移动到完成区域，然后再领或派一个新任务。

3.定期展示成果

口说无凭，软件说话。隔个一两周，把大家叫到会议室时运行一下各自的代码。如果两次展示之间没有进展，负责的程序丸在每日站会上又没有报问题，那就要检查一下出了什么状况，及时纠正项目进度。

---

去掉工作量评估这一环节，省掉了不少事务性工作时间，只要增加项目的频繁返馈，再建立尽快交付价值的团队目标。

业务只需安排好项目优先级，IT只需努力尽快实现业务价值，做完一个项目，再挑一个优先级最高的做，保证在做的永远都是当前最有价值的事情。

---

最后随便扯一下，项目是并行做好，还是串行做好？

如果一个团队接到不止一个项目，先保证优先级最高的项目得到最有效的投入，保证可以尽快向业务交付价值。

譬如团队接到三个项目（不能出现项目优先级相同的不按套路出牌的情况），如果并行开发，6个月后三个项目同时期上线了。如果串行发，2个月后上线优先级最高的项目，4个月后上线优先级次高的项目，6个月后上线优先级最低的项目。

别以为一个团队并行开发项目效率总会比串行高，就像一个人左手画圆，同时右手画方，结果画出来圆不是很圆，方又不是很方。

以上观点自知肤浅，旨在探讨软件工程，抛砖引玉。