“为什么不能赶出来？” 当项目赶不上deadline时，经理总觉得是开发组的错。但真的是开发人员行动太慢了吗？ 项目管理服务Sprintly的产品营销经理JustinJackson在博客中表示，他们使用Sprintly跟踪开发人员执行各种任务所花费的时间，并按类型和大小进行细分，得出以下结论。 有什么共同点？ 第一点，开发人员很一般。根据软件收集的数据，75%的开发周期在175小时左右。 其次，变数最大的是工单开始前，也就是厂家出规范和安排工作的时间，即从工单出现到安排工作所需要的时间。这个阶段浪费了很多时间。 第三，从“完成”到“测试并准备分配”的过渡对团队来说也是困难的。 进步的原因是什么？ 如果不是你的开发人员这么慢，为什么开发逾期了？答案可能是：您的流程有问题。 需求不明确 确定技术规格很重要。如果开发人员不了解功能的用途，他如何开发它？大多数技术规范是在没有仔细考虑的情况下制定的。通常，当我们开始设计或开发时，我们会遇到很多麻烦，因为很多规范都有漏洞。—eagerMooseonStackExchange 厂商开发的功能往往是自己没有仔细考虑过的，所以开发者必须了解用户为什么需要这个功能，这个功能是干什么的，怎么用。您可以用固定格式描述用户上下文。在使用Sprintly时，你必须按照这种格式来写：我是一个____，我想要____，所以____。（把事情做好）一定是这样。—DarrenRogan，HackandHeckle播客 这种格式设定了特定功能的方向，但也保持了小规模的上下文设置而不会过度拉伸。 不断变化的需求 开发者抱怨的第二个主要原因是项目启动后不断变化的技术规范。一位HackerNews用户说得很贴切：开发人员：“我们已经盖好屋顶和墙壁了！”供应商：“我们现在想拆除所有的墙。” 这主要是因为在安排工作之前没有正确规划功能而产生的债务。 避免在过程中更改需求的一种方法是在实际开始开发之前进行交互式模拟。我们以灵活的方式工作，这并不意味着我们可以随时更改规模。 最理想的情况是，你在这个过程中得到的所有想法都应该立即记录下来，并考虑到以后的更新。 另一种防止需求和规模变化的方法是尽可能地预测进度。Sprintly中有一个功能，就是根据进度预测完成一个功能需要多少天。 切换工作 JustinJackson提到流程中最后一个绊脚石很可能就是切换工作，而这可能有以下几种常见的形式：开发者完成了A的一半工作，此时你走到他的办公桌前，让他转做工作B。开发人员正在工作A进行到一半，你走到他的办公桌前，让他同时做工作B。 比如Sprintly的开发总监，经常需要检查代码，帮员工分组，开会，遇到紧急情况出来救火。 开发负责人经常分心，导致他比其他人花费更长的时间来完成一项工作。 当经理让开发人员中途更换新工作时，就会出现问题，如果工作时间表不断变化，团队可能会付出高昂的代价。 StackOverflowCEO，Trello联合创始人JoelSpolsky在博客中也提到了跳槽的危害：你将从这些事件中吸取教训，不要让人们同时处理两份工作，并确保他们知道工作内容。优秀的管理者会承担责任并消除障碍，让人们专注于一项工作并完成它。如果出现紧急情况，在打断全神贯注于项目的工程师之前，先看看自己是否能处理好。 承担责任 管理者的工作是提供一个开发人员可以成功完成项目的环境。在将延误归咎于开发人员之前先检查一下自己。 这里有一些简单的步骤来检查你是否拖累了团队： 1。让你的团队明白目标：和你的团队一起定义如何让用户的生活更美好，弄清楚用户想要的结果。开发者接受与否很重要。对功能的热衷程度会极大地影响开发速度。 2。用户情境的设计必须有明确的规范。每个作业都是使用相同的模板创建的，开发人员有权拒绝接受一个作业，除非它有完整的详细描述。 3。降低转换成本，不要打扰你的开发人员！在发送电子邮件或提出任何请求之前，衡量对生产力的影响。 重点是，在指责开发人员“太慢”之前请三思，很可能是您的工作流程拖慢了他们的速度。
