在编写代码之前了解功能有多重要？

Question

我在一家软件开发公司工作，那里的开发工作已经交给我们了。在岸团队处理支持，并直接与客户交谈。我们从不直接与客户交谈--我们只是与岸上团队的人交谈，他们直接与客户交谈。

当需求到来时，岸上团队会与客户进行沟通，并制作需求文档并通知我们。在研究了需求之后，我们制作了设计文档(我们遵循传统的瀑布模型)。

但是在整个过程中有一个问题:无论是离岸团队还是岸上团队，都没有人完全理解应用程序的功能。我们只知道它是一个大型复杂的web应用程序，处理复杂的订单处理、目录管理、活动管理和其他活动。我们与设计文档斗争，因为需求是不明确的。然后，在岸上团队、离岸团队和客户之间来回回答一系列问题/答案。我们经常被告知要从代码中理解功能。但这通常是不可行的，因为代码库庞大，甚至理解一个简单的菜单项也需要数天甚至几周时间。我们试着告诉客户给我们有关应用的知识转移，但没有结果。我们的经理经常告诉我们，即使设计文档不完整，或者需求不明确，也要开始编码。我们将从编码需求中看似清晰的部分开始，然后等待其余的部分。

这通常会将部署工作推迟一个月。在极端情况下，我们在开发和生产中会有非常低的错误，但是客户会说这不是他们所要求的。这将启动一个指责游戏和一系列的更改请求，我们最终会开发一些非常不同的东西。

我的问题是，如果您不完全了解应用程序的功能，您将如何进行开发工作？

更新

开发方法，这不是我的选择，我也不是我的团队的领导者。这是它开始的方式。我试着告诉人们敏捷的优点，但没有结果。此外，我不认为我的团队有在敏捷环境中工作的必要心态。

Answer 1

简写版：

知道该做什么，≠了解你的客户。

想象一下:你是一家与房地产开发有关的公司。你让你的搭档建造一个大的建筑群。这位合伙人说，尽管你给了他所有的文件，但他也需要直接与在这个建筑群里购买公寓的人交谈。我是认真的?

长版本：

知道如何使用特定的应用程序总是很好的，因为学习东西很有趣，但在大型项目中并不总是可能的。

有些域太复杂了。如果你只是一名开发人员，而且你正在开发多个领域的应用程序，你就不能总是了解最终用户在做什么，因为这需要你花5年时间学习会计，10年在医学院学习，6年在法学院学习，等等。

另一方面，不了解特定领域的软件产品充其量也是无法使用的。

这就是为什么功能性和非功能性需求必须由完全了解域的人编写的原因。一般而言，需求收集同时包括：

1. 技术人员(例如，开发人员会告诉特定的特性是不可能的，如果这样做，另一个功能会更好，而这个功能将花费数千美元，而另一项功能的选择要便宜得多)，
2. 专门从事项目管理的人，
3. 专门从事客户领域的人，他们对这一领域有充分的了解，并准确地了解客户的需求。当然，这可能是客户本身。

一个功能性和非功能性需求是被编写的，并且足够精确，作为一个将这些需求转化为代码的人，您不需要任何其他的东西。

至于你的具体情况，你自己描述了问题的原因：

我们与设计文档斗争，因为需求是不明确的。

造成所有麻烦的并不是缺乏对客户的了解，而是需求的低质量。在正确管理的项目中，功能性和非功能性需求必须非常清楚和明确。如果需求文档不清楚，或者它告诉您“产品的视觉设计必须有吸引力”或其他类似的愚蠢之处，那是因为它是由不知道如何编写它的人编写的。

知道了这一点，你必须采取不同的行动：

• 如果你知道收集需求的团队是绝望的，而你自己的团队有熟练的人员来收集需求，那么向你的上级解释一下情况，并告诉你其他团队必须被有能力的人所取代，比如你的人。
• 否则(也就是说，如果他们不是绝望的话)，试着确定他们那些低要求的内在原因，并说服他们正确地做好他们的工作只会降低项目的整体成本。通过增加成本(多少？)显示书面需求对项目影响有多严重的统计数据。在这里，没有为最后期限做好准备的风险是个好主意。

可能需求文档是不完整的。我一直看到这一点:缺乏经验的项目经理只是确信一页文档就足够了，并且不明白为什么他们会写三四百页而不是一页。如果在你的公司里是这样的话，说明花更多的时间在需求上会降低成本。

Answer 2

对于您所面临的问题，您使用了完全错误的开发方法。

通过使用瀑布，您将承诺：

1. 把正确的需求摆在前面--这显然是行不通的
2. 将需求与客户分开编码--如果您致力于开发需求，则无法有效地与客户检查问题。
3. 客户第一次看到其功能的机会是在测试期间--考虑到您遇到的问题，这已经太晚了。

如果可能的话，考虑使用另一种管理项目的方法。敏捷软件开发有几个特性被设计用来解决您所面临的问题。

一段时间前，我们对瀑布对敏捷做了一个不错的比较，让我们从其中引用几句话，突出说明您的问题：

错过了标记：

瀑布法一旦完成了一个阶段，就不会倒退，因为在瀑布法下设计和实现的大多数软件都很难根据时间和用户的需要进行修改。这个问题只能通过回去设计一个全新的系统来解决，这是一种非常昂贵和低效的方法。

绑起来..。

敏捷方法允许根据最终用户的需求进行规范更改，从而使客户满意。如前所述，当采用瀑布法时，这是不可能的，因为所要做的任何改变都意味着项目必须重新开始。

...and无法移动

要总结两者之间的差异，可以说经典的瀑布方法代表可预测性，而敏捷方法则意味着适应性。敏捷方法擅长于减少管理费用，例如，基本原理、理由、文档和会议，尽可能地保持它们的低水平。这就是为什么敏捷方法使需求不断变化的小型团队受益，而不是更大的项目。

你现在所处的位置是不好的；你没有满足客户的需求，如果你是软件开发的罪魁祸首，生产力就会消失，不信任会上升，事情可能会变得更糟，而不是更好。

与客户的关系至关重要；在这里，您似乎无法以当前的工作方式有效地收集他们的问题，并适应他们不断变化的需求；因此，您需要研究改变这种问题的方法。

Answer 3

这不是它的工作方式。我当前教育的主题之一是分析，以及与客户的关系。重点也一直放在明确界定项目上。想象一下：

• 你命令一家建筑公司建造一座房子，但你不知道你想让它看起来怎样。你只需定制一楼，所以团队在一楼前建一栋房子。然后你想要一楼被不同的布局。哦..。

除非您非常确信您能够(部分)为应用程序奠定正确的基础，否则我只想告诉客户端，没有其他方法可以完成，只有明确定义的目标和功能。因为如果你只是尝试一下它可能是什么，你就会冒着浪费大量金钱和时间的风险。