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

我为一家软件开发公司工作，该公司的开发工作已不存在。岸上团队处理支持并直接与客户交谈。我们从不直接与客户交谈，我们只是与岸上团队的人员交谈，他们直接与客户交谈。

当需求到达时，岸上团队与客户交谈并制作需求文件并通知我们。在研究了要求之后，我们制作了设计文件（我们遵循传统的瀑布模型）。

但是整个过程中存在一个问题：离岸团队或在岸团队中没有人完全了解应用程序的功能。我们只知道它是一个大型的复杂Web应用程序，可处理复杂的订单处理，目录管理，活动管理和其他活动。我们对设计文档感到困惑，因为要求不明确。然后，它会讨论在岸团队，离岸团队和客户之间的一系列问题/答案。我们经常被告知要从代码中了解功能。但这通常是不可行的，因为代码库很大，甚至了解一个简单的菜单项都需要几天甚至几周的时间。我们试图告诉客户给我们知识转移关于该应用程序，但无济于事。即使设计文件不完整或要求不明确，我们的经理也会经常告诉我们开始编码。我们将从对似乎很明确的需求部分进行编码开始，然后等待其余部分。

这通常会使部署推迟一个月。在极端情况下，我们在开发和生产中的错误率非常低，但是客户会说那不是他们要求的。那将开始一个非常规游戏和一系列变更请求，而我们最终将开发出非常不同的东西。

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

更新

开发方法并不是我真正的选择，我也不是我团队的负责人。这是它开始的方式。我试图告诉人们敏捷的优势，但无济于事。此外，我认为我的团队没有在敏捷环境中工作所需的思维定势。

简洁版本：

知道该怎么做≠认识您的客户。

想象一下：您是一家与房地产开发相关的公司。您要求您的伴侣建造一个大型综合体。合伙人说，尽管您给了他所有文件，但他还需要直接与将在此建筑群中购买公寓的人交谈。认真吗

长版：

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

有些域太复杂了。如果您只是一名开发人员，并且正在处理来自多个域的多个应用程序，那么您将永远无法理解最终用户的工作，因为这将需要您花费5年的时间学习会计学，在医学院的10年时间，在法学院等了六年

另一方面，在不了解特定领域的情况下制作的软件产品充其量是最好的，有点用处。

这就是为什么功能和非功能需求必须由完全了解该领域的人员编写的原因。通常，需求收集同时涉及：

1. 技术人员（例如，开发人员会告诉他们某个特定功能是不可能的，如果这样做的话，另一个功能可能会更好，并且如果有更便宜的替代方法，则这将花费数千美元），

2. 专门从事项目管理的人员

3. 专门从事客户领域的人员，他们对这一领域和客户的确切需求有充分的了解。当然，这可能是客户本身。

编写了一个功能性和非功能性需求，并且非常精确，作为工作人员，您无需执行其他任何操作即可将这些需求转换为代码。

对于您的具体情况，您自己描述问题的原因：

我们对设计文件感到困惑，因为要求不清楚。

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

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

• 如果您知道收集需求的团队是绝望的，并且您自己的团队拥有熟练的需求收集人员，请向您的上级解释情况，并告诉其他团队必须由胜任的人员代替，例如您的人员。

• 否则（即，如果他们不是绝望的），请尝试确定造成这些低要求的内部原因，并说服他们正确地执行工作只会降低项目的总体成本。在这里显示关于书面要求如何通过增加成本（多少？）以及项目未准备好在最后期限前冒风险的影响的统计数据是一个好主意。

需求文档可能不完整。我一直都看到这种情况：经验不足的项目经理只是相信一页纸就足够了，而且不明白为什么他们会写三到四百页而不是一页。如果您的公司就是这种情况，请表明花更多的时间在需求上会减少成本。

您正使用错误的开发方法来解决所面临的问题。

通过使用Waterfall，您将致力于：

1. 预先提出正确的要求-这显然行不通
2. 让需求远离客户编写代码-承诺致力于开发需求，您将无法与客户有效地检查问题
3. 客户第一次看到其功能的机会是在测试期间-考虑到您遇到的问题，这为时已晚

如果可能，请考虑使用其他方式来管理项目。敏捷软件开发具有旨在解决您所面临的问题的若干功能。

瀑布与敏捷的比较是前一段时间写的，让我们引用其中的几句话来突出您的问题：

缺少商标：

一旦在Waterfall方法中完成了一个阶段，就没有回头路了，因为在Waterfall方法下设计和实现的大多数软件很难根据时间和用户需求进行更改。这个问题只能通过回去设计一个全新的系统来解决，这是一种非常昂贵和低效的方法。

束缚...

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

...并且无法移动

为了概括两者之间的差异，可以说经典的瀑布方法代表可预测性，而敏捷方法则代表适应性。敏捷方法擅长减少开销，例如基本原理，理由，文档和会议，并尽可能降低开销。并且，这就是为什么敏捷方法使不断变化的需求使小型团队受益的原因，而不是使大型项目受益的原因。

你现在在哪里很糟糕；您不能满足客户的要求，并且，如果您属于软件开发的责任部分，那么生产力将无法发挥作用，不信任感将会上升，情况可能会变得更糟，而不是更好。

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

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

• 您命令一家建筑公司建造房屋，但您不知道它的外观。您只需自定义第一层，因此团队可以在第一层建造房屋。然后，您要对底层进行不同的布局。糟糕...

除非您非常确定可以（部分地）为应用程序奠定正确的基础，否则我只会告诉客户，除了明确定义的目标和功能之外，别无他法。因为如果您只是冒险尝试一下，可能会冒大量金钱和时间浪费的风险。

以下是有助于克服问题的一些方法：

1. 改善两个团队之间的沟通。请其他团队将要求压缩到3个单词，然后程序员将准确地实现这些单词。这些词只需要正确即可。没有这些话，什么都不会实现。每个单词给您2000行代码。当知道一个新词时，开始执行。
2. 如果您的程序员现在还不清楚，那么他们可以问一个问题。这个问题再次必须是正确的。它需要立即的答案-答案不能等待来自世界另一端的往返，但需要事先知道。收到答案后立即开始实施，答案将紧随其后。
3. 如果在实施过程中存在不清楚或模糊的要求，解决这些问题的方法是先查看（现有的）三个词。如果仍然不清楚，那么程序员将做出最佳猜测。绝对禁止在此过程中出现任何延迟；并且寻求其他团队的帮助不是解决问题的正确方法-他们已经有机会通过确定正确的3个单词来更改要求。
4. 如果毕竟，要求仍然不清楚或无法实现，则正确的处理方法是拒绝引起麻烦的这三个单词，然后移至下一个单词。任何被拒绝的单词将被收集并传递给另一个团队，他们将需要修改这些单词，然后才能将它们重新输入到系统中。拒绝言语总是会影响最后期限，需要重新计划实施。
5. 团队需要根据他们拥有多少被拒绝的单词进行评估。需求实施后，它将永久固定，无法再更改。任何更改已经实施的功能的尝试都将被拒绝。
6. 这个问题的实际问题是，它假设更多的信息使实现变得更加容易。这不是真的。在更自由的程序员中，更容易实施。压缩需求可以交流大量信息，而又不会过多限制程序员的工作。