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