进度落后不是开发者的错，工作流程可能才是凶手！
「为什么赶不出来？」
项目错过死线的时候，管理者总觉得就是开发团队的错。不过真的是开发者动作太慢吗？
项目管理服务 Sprintly 的产品行销经理， Justin Jackson 在部落格内说，他们利用 Sprintly ，追踪开发人员执行各项工作的时间，并依种类和大小细分，得到了以下结论。
有什么共通点？
第一点就是，开发人员表现非常平均。根据软件搜集的资料，75% 的开发周期都在 175 小时左右。
第二，在 ticket 开始前变数最大，这就是厂商开出规格和安排工作的时间，也就是当 ticket 从出现到安排作业所需的时间。这个阶段浪费了很多时间。
第三，从「完成」转换到「测试完并准备好分配」对团队而言也很困难。
进度落后的原因？
如果不是你的开发人员特别慢，那为什么开发会逾期？答案可能是：你的流程有问题。
需求不明
确定技术规格很重要。如果开发者不懂一项功能的目的，那他要怎么开发这功能？
绝大多数的技术规格开出来时，没经过审慎思考，通常等到我们开始设计或开发，就会碰到一堆麻烦，因为很多规格都有漏洞。
— eagerMoose on Stack Exchange
厂商太常开出自己没仔细想过的功能，所以开发者一定要去了解，为什么使用者需要这个功能、这个功能是做什么的、要怎么用。你可以用固定的格式来描述使用者情境。
使用 Sprintly 时，你得用这个格式来写：我是一个 ＿＿＿，我想要 ＿＿＿，所以 ＿＿＿。（要把事情做对）一定得这样。
— Darren Rogan， the Hack and Heckle podcast
这个形式为特定功能设定了方向，也维持小规模的情境设定，不会过度展开。
不断变更需求
开发者第二大抱怨主因就是，项目开始后，不停变动的技术规格。Hacker News 的一位使用者形容得很贴切：
开发者：「我们把屋顶和墙都装好了！」
厂商：「我们现在想要把所有的墙都移开。」
这大部分是安排工作前没有好好规划功能，所产生的债务。
避免在流程中途变更需求的方法之一，就是在真正开始开发前，先做互动模拟。我们用灵活的方式工作，不代表我们可以随时变更规模。
最理想的情形是，你在过程中得到的点子，都该立刻纪录下来，并考虑日后放进更新。
另一个防止变更需求及规模的方法就是尽可能预测进度。Sprintly 内有项功能，就是根据进度，预测完成一项功能还须多少天。
切换工作
Justin Jackson 提到，流程中最后一块绊脚石，大概就是工作的切换，而这可能有以下几种常见形式：
- 开发者已经完成 A 工作的一半，此时你走到他的办公桌旁，要求他切换到 B 工作。
- 开发者已经完成 A 工作的一半，此时你走到他的办公桌旁，要求他同时处理 B 工作。
举例来说，Sprintly 的开发主管时常需要检查代码、帮员工分组、开会、紧急状况出来救火。
开发主管不断分心做其他事，导致他完成一项工作的时间要比其他人来得长。
当管理者让开发人员中途切换到新工作，就会产生问题，而如果工作时程一直在变，将让团队付出重大代价。
Stack Overflow 的 CEO，Trello 共同创办人 Joel Spolsky ，也在部落格中提到切换工作的伤害：
从这些事件中你会学到，别让人同时处理两件工作，并确定他们清楚工作内容。
优秀的管理者会承担责任，替人移除障碍，让他们专心于一件工作并完成它。若有紧急事态，在打扰全心沉浸于项目的工程师前，先看看你能不能自己处理。
担起责任
管理者的工作就是提供一个环境，让开发者能成功完成项目。在指责开发人员，要他们为延迟行程负责前，应该先检验你自己。
这里提供一些简单的步骤，可以检查看看你有没有拖累团队：
1、让你的团队了解目标：和你的团队一起定义，如何让使用者的生活更好，搞清楚使用者需要的结果。让开发者接受与否很重要，对功能的热情程度，会大大影响开发速度。
2、设计使用者情境要有明确规范。每项工作都使用同一个模板创造，除非充分叙述工作细节，否则开发者都有不接这项工作的权利。
3、减少切换工作成本，不要打扰你的开发者！寄 email 或提出任何要求前，先衡量一下对生产力造成的影响。
重点是，怪罪开发人员「太慢」前请三思，很有可能是你的工作流程拖累了他们。