程序员喜欢创建最后期限吗？我是一名网络开发人员，在我的领域里到处都是时间表/截止日期。但是我曾与一些讨厌截止日期的软件工程师/程序员一起工作，有没有办法解决这个问题？
jrutter
问问题
4649 次
8 回答
32
首先，您需要区分最后期限和估计。
- 截止日期来自外部来源，例如，“功能 X 需要为贸易展做好准备”。
- 估计来自内部来源，例如，“功能 X 将需要 N 周才能完成”。
通常，程序员应该创建估算，而销售/营销将创建最后期限。
当这两个问题无法解决时就会出现问题——如果最后期限比估计的更近。
对开发人员（潜在客户）的有用提示：
- 让做这项工作的人创建估算。
- 确保估算基于微小的任务，每个任务不超过一两天。
- 使用反馈循环让开发人员提高他们的估计技能。
- 准确的估算技能可以让您更加努力地应对最后期限的要求。
对营销人员/截止日期创建者的有用提示：
- 不要用截止日期覆盖估算值。
- 如果最后期限与估计值冲突，唯一的实际选择是 (a) 开发人员加班，(b) 对最后期限的要求被削减，或者 (c) 错过最后期限。
- 解释为什么截止日期很重要，以及功能截止日期的目的是什么（“客户 X 将签署六位数的合同”）。
- 要明白，那些觉得自己无法按时完成任务的人不会有动力。
于 2008-12-19T14:36:22.720 回答
10
程序员讨厌最后期限是有充分理由的！
在您完成之前，几乎不可能准确估计一段代码需要多长时间来设计、编写和调试。
根据我的个人经验，我花了一个多星期的时间来编写一个“简单”的 shell 脚本，我估计大约需要一个小时。另一方面，我花了大约一周的时间为 COBOL 数据定义（包括所有奇怪的 COMP COMP-3 OCCURS 重新定义 SYNC 和 slack 字节的东西）编写解析器，我估计大约需要两个月。
另一个大问题是，面对紧迫的最后期限，程序员会跳过最佳实践并开始进行黑客攻击。从而节省了大约 50% 的编码时间，但增加了 300% 的测试和调试时间。
于 2008-12-19T14:37:25.277 回答
5
传统上，您只能调整质量、功能或时间，最后一个是截止日期。你真的不想乱来的质量。因此，只要您使用的流程允许您校准功能以达到最后期限，我就可以了。
于 2008-12-19T14:35:39.633 回答
5
开发人员需要参与创建最后期限。如果它们是任意的并且在没有开发人员输入的情况下创建，那么他们有权投诉。项目合法地从业务中获得时间限制，但必须调整资源和功能以进行补偿。如果没有开发人员（更不用说 BA、QA 和运营人员）的投入，这些调整就无法进行。
于 2008-12-19T14:38:01.093 回答
4
我遇到的唯一讨厌截止日期的软件工程师/开发人员有这样的感觉，原因有两个：
- 他们完全杂乱无章，并且知道他们不会赶上最后期限，因此不喜欢他们，因为当他们错过最后期限时，这会让他们看起来很糟糕。
- 他们对截止日期没有问题，只要了解所涉及工作的人设定截止日期即可。最糟糕的最后期限是经理们试图推销一个项目并说“3周？没问题！” 然后告诉他们的开发团队，他们有 3 周的时间来制作 MS Office 的工作版本，并为 CEO 的小孩重新创建互联网。
于 2008-12-19T14:38:18.833 回答
2
我认为这取决于如何创建时间表。开发人员需要在制定时间表方面发挥重要作用。否则你怎么知道它是否合理？
如果高层管理人员只是简单地规定“功能 X 需要由 Y 完成”，而没有很好地了解它可能需要多长时间（有些事情的实施比听起来要复杂得多），那就不好了事物。但是，如果他们与开发人员一起估计实际需要的工作量并将其与公司的其他需求相平衡，那么它通常会很好地工作。
于 2008-12-19T14:34:37.793 回答
1
好吧，如果截止日期是通过深思熟虑的估算过程确定的，并且经理和工程师都提供了意见，并且对在截止日期前应交付的内容的要求得到了明确的定义，那么我对截止日期感到非常满意。
于 2008-12-19T14:33:02.633 回答
1
定期审查至关重要：
- 列出主要里程碑和可交付成果
- 把它分成更小的块
- 创建较小估计值的集合
- 使最后期限合理
你必须有最后期限，但同样，这些最后期限必须是现实的和可衡量的。移动规范会惹恼开发人员——这可能是不可避免的，但不要害怕移动（经过讨论）。
截止日期和工作估算永远不会特别准确，但是基本的项目管理技术应该意味着人们意识到错过了它们 - 以及它发生的原因。
于 2008-12-19T14:37:02.360 回答