代码之家 › 专栏 › 技术社区 › jaekie

组织代码以及如何在编程最后期限内完成最后期限

project-management

-1

jaekie · 技术社区 · 15 年前

我知道这可能不完全是一个编码问题,但我觉得它仍然与编程有关,因为我确信许多开发人员以前都遇到过这个问题,并且可能对如何解决这个问题有一些见解,或者有一些建议。不过,实际上还有一个编程问题。

我作为开发人员的问题。

我在一家小公司工作,大约15人,其中5人是开发人员,包括我自己,其余的人是技术支持和管理人员。我遇到的问题是,当我们得到一份工作说明书(SOW)时,我们的客户会给我们一份他们要求的项目的大致描述,通常是1-3页的简短描述,通常包括一份Visio文档,现在作为一个编程,我负责审阅文档并转发一个时间线,说明我完成任务需要多长时间。删除项目。

不幸的是,有很多时候,不仅是我,我们低估了这个项目,因为在我们真正开发它之前,我们没有完全投入到它当中,这最终给我们自己一个耳光,因为我的老板很生气,因为他正受到客户的追捕,而客户现在因为我们错过了承诺的最后期限而很沮丧。

我的问题是,当你们需要给出更多概念的最后期限时,你们如何处理组织基本的项目描述,你们对如何组织它有什么想法吗?

我想去见我的老板,建议我们不要总是把估计的最后期限推给我们的客户,他们希望我们达到这个目标,我们应该写一份详细的文件,关于如何开发他们想要的应用程序,这可能需要更多的时间,但至少如果项目被转移到其他人那里,我们会花更多的时间。因为它是为他们设计的,当我通常4个月后回到它的时候,我不需要再刷新,我只需要按照我写的步骤就可以了。

你们觉得怎么样?思想?或者更好的处理方法?

5 回复 | 直到 6 年前

1

2

JBRWilkinson 15 年前

如果您将开发转换为使用迭代方法(敏捷、XP、Scrum等),那么客户将看到比您认为必须承诺的任何期限都要早得多的结果——通常是每1或2周。

当他们看到你开发的产品时,我可以保证他们会改变他们最初的需求,因为他们现在对产品有了一个直观的表示,这可能不是他们想的那样。他们的一些变化可能相当激进,所以最好尽早得到反馈。

在我坚持要我们这样做的所有项目中,客户都很高兴——他们很早就看到了结果,可能会影响项目的结果,而且我们达到了他们的最终期限。出乎意料的是,一整批功能都被抛在了后面——猜猜怎么着——客户一点也不介意,因为他们得到了他们想要的顶级功能,并将项目/产品直接投入生产,因为他们有很多时间来改进它以适应他们的业务,所以他们已经熟悉了。

管理、销售、创意等都需要付出大量的努力,才能让所有人都接受迭代式的风格,因此您可能需要在这段时间内实现一个混合解决方案,但根据我的经验,这是非常值得的。

如果不可能完全转向迭代,那么将您的项目划分为切实的里程碑,并交付这些里程碑。正如其他人所说,夸大你的估计。我以前的经理把我的估计翻了一番,销售团队也翻了一番。

2

Jacob Relkin 15 年前

膨胀你的项目截止日期。这是大多数程序员应该做的事情(我引用了 Freeverse ,我工作的公司):

这是一个众所周知的事实在软件行业工作的人 最后5%的发展总是最长的 .

3

1

Arnkrishn 15 年前

如果可能的话,尽量将更高级别的任务分割开来,这样你就可以更好地估计出子任务需要多少工时。

此外,在任务执行中添加隐藏缓冲区有助于覆盖一些看不见的意外事件。

干杯

4

0

µBio 15 年前

如果你和你的顾客一起做模型(balsamiq或其他什么),你会得到更多的细节。有了这些细节和一些经验,您的估计将更加准确。再加倍,加4个小时(小时、天、周、月)

5

0

Mathias 15 年前

首先,除非你系统地低估了估计,否则你的老板不应该生气。回答客户是他的工作,他应该知道,根据定义,估计不是未来。从统计上看,有时候你应该提前交货,有时候迟交货。
就我个人而言,我认为“需要多长时间”的框架并不完全是正确的讨论。软件开发是一项有风险的业务,并且变化/意外总是发生。其中一个有帮助的方法是少关注“正确”的数字,多关注波动性。看看这个项目,考虑一下你对它需要多长时间非常清楚的地方(你以前做过并且理解得很好),看看你有不确定性的地方(不清楚的需求,新技术),对于这些,考虑一下它会有多糟糕,以及为什么。这将有助于你得到一个数字,而不是界限:你认为合理的,最坏的情况,也许是最好的情况(客户永远不会看到),并将信息传达给你的老板,这样他就可以相应地管理。
此外,这将允许您识别项目的危险点,然后您可以相应地创建原型-尽早查看不确定点,以便您可以快速缩短时间线,并为您的老板和客户提供早期警告。