Project management 您如何处理程序员的日程安排/截止日期？

程序员喜欢设定截止日期吗？我是一名网络开发人员，在我的领域里，时间表/截止日期无处不在。但是我和一些讨厌截止日期的软件工程师/程序员一起工作过，有没有办法解决这个问题，我很高兴有一个最后期限，如果该最后期限是通过经过深思熟虑的评估过程确定的，并得到了经理和工程师的输入，对在该最后期限内交付的内容的要求是明确的。

我认为这取决于如何制定进度计划。开发人员需要在制定进度计划中扮演重要角色。否则你怎么知道它是否合理

---

如果高层管理人员简单地规定“功能X需要由Y完成”，而没有很好地了解实际需要多长时间（有些事情的实现比听起来要复杂得多），那么这是一件坏事。但是，如果他们与开发人员合作，估计实际需要的工作量，并将其与公司的其他需求相平衡，那么通常效果会很好。

传统上，您只能调整质量、功能或时间，最后一个是截止日期。你真的不想乱来的品质。因此，只要您使用的流程允许您校准功能以达到最后期限，我就可以。

首先，您需要区分最后期限和估计

• 截止日期来自外部来源，例如，“功能X需要为展会做好准备”
• 估计来自内部来源，例如，“功能X需要N周才能完成”

通常，程序员应该创建估算，而销售/营销将创建截止日期

当这两个问题都无法解决时，就会出现问题——如果最后期限比预计时间更近的话

开发人员的有用提示（潜在客户）：

• 让工作人员创建估算
• 确保评估基于微小的任务，每个任务不超过一两天
• 使用反馈循环让开发人员提高他们的评估技能
• 准确的评估技能可以让您更努力地满足截止日期的要求

对营销人员/截止日期创建者的有用提示：

• 不要用最后期限来替代估算
• 如果最后期限与估算发生冲突，唯一的实际选择是（a）开发商加班，（b）削减对最后期限的要求，或（c）错过最后期限
• 解释为什么截止日期很重要，以及功能截止日期的目的是什么（“客户X将签署一份六位数的合同”）
• 要明白，那些觉得自己无法按时完成任务的人是不会被激励的

---

定期审查至关重要：
• 列出主要里程碑和可交付成果
• 把它分成小块
• 创建一个较小的估计值集合
• 使截止日期合理
你必须有最后期限，但同样地，这些最后期限必须是现实的和可测量的。移动规范会惹恼开发人员-这可能是不可避免的，但不要害怕移动东西（在讨论之后）

---

最后期限和工作估计永远不会特别准确，但基本的项目管理技术应该意味着人们意识到错过了它们——以及它为什么会发生
程序员讨厌截止日期有很好的理由
在您完成一段代码之前，几乎不可能准确估计它的设计、编写和调试所需的时间
根据我的个人经验，我花了一个多星期的时间编写了一个“简单”的shell脚本，估计大约需要一个小时。另一方面，我花了大约一周的时间为COBOL数据定义（包括所有奇怪的COMP COMP-3 OCCURS重新定义同步和松弛字节）编写解析器，我估计这大约需要两个月的时间

---

另一个大问题是，面对紧迫的截止日期，程序员跳过最佳实践，开始黑客攻击。这样就节省了大约50%的编码时间，但增加了300%的测试和调试时间
开发人员需要参与创建截止日期。如果他们是武断的，没有开发人员的输入就创建了，那么他们有权抱怨。项目可以合法地从业务中获得时间限制，但必须调整资源和功能以进行补偿。如果没有开发人员（更不用说BAs、QA和运营人员）的投入，这些调整是无法进行的。
我遇到的唯一讨厌截止日期的软件工程师/开发人员会有这样的感觉，原因有两个：
• 他们完全没有组织， 并且知道他们不会满足 最后期限，所以我不喜欢他们 因为当他们错过最后期限的时候 这让他们看起来很糟糕
• 他们没有 对截止日期有问题，例如 只要有人能理解 所涉及的工作是设置 最后期限。最糟糕的期限是 由试图出售股票的经理制作 项目并说“3周？不 然后告诉他们 他们有3个开发团队 制作工作版本需要数周时间 并重新创建 为首席执行官的小孩上网

---

-1我们的开发人员也有责任改进我们进行评估的方式。这不是“几乎不可能”，它需要练习。由于我的经验，我能够准确地估计一些任务，因为我知道会发生什么。我不讨厌截止日期，因为它们帮助我专注于一个目标，我讨厌不现实的截止日期给我的营销人员设置：）不管是不是新手，当我寻找新的解决方案来寻找不熟悉的bug时，我的老板总是催我问截止日期。如果我太诚实的话，我会失去工作的。可以期待什么？我们是程序员，时间完全不匹配是因为一件事：过度思考。同意！你永远无法估计助教