若是抛掉软件工程中的工做量评估

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

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

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

若是把评估工做量环节去掉，项目开发流程会有啥不同呢？

---

可能出现的现象

---

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

---

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

---

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

---

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

1.任务公开化可视化

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

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

2.每日站会

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

3.按期展现成果

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

---

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

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

---

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

若是一个团队接到不止一个项目，先保证优先级最高的项目获得最有效的投入，保证能够尽快向业务交付价值。

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

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

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