职业程序员：不完美世界的游击战术 - 第 5 章
将您的需求刻在石头上
 |
|
第 5 章 - 将你的需求刻在石头上
随意需求诅咒是一个经典的惊悚片，保证能吓坏所有程序员。但它有点像沉睡的巨人，因为可怕的事情并没有发生在开头。与大多数好人最终获胜、罪魁祸首是管家的大多数悬疑故事不同，在我们的这个小故事中，好人输了，而且他们一开始也负担不起管家。软件开发过程始于一个程序想法。这个想法通常和扔在洗衣机后面的袜子一样模糊。当程序员第一次得知管理层对新软件的期望时，只有两条路可走。第一条是默认方向，即程序员什么也不做，而是根据他们收到的任何模糊的需求开始设计或编码。第二条路更艰难：程序员必须为他们能获得的每一个细节而战斗、抓挠、拼命，并确保它们以清晰、毫不动摇的语言记录下来以供后世参考。换句话说，这包括获取具体细节并生成一份纸质记录，以在项目结束时或开发者需要自卫的任何其他时候使用。
如果您已经遵循了有组织的、结构化的、有效的需求收集过程，那么您就不需要游击战术了。相反，您可能应该花更多时间在程序员经常光顾的咖啡店里闲逛，您一定会受到当地英雄般的待遇。对于我们其他人来说，试图让管理层吐出细节并将其承诺以比口头承诺更实在的形式，比试图把一群油腻的猪赶进房间洗澡还要难。而且，不，我不会再进行任何类比了。我的管理层可能会读到这篇文章，而我非常喜欢按时收到的薪水。
请勿误以为：如果您在未来的某个时候给解释留下了余地，人们就会这样做。在最后一刻。此外，措辞不精确的需求是范围蔓延的公开邀请。即使您从现在开始一切顺利，这两者中的任何一个都可能在您距离截止日期还有一周时将您推入疯狂的加班。需求将突然改变，当然您的截止日期不会。您可能会想争辩说，您被雇来写软件，而不是管理公司，所以让需求变得具体不是您的工作。需求在你找上门时就应该那样，想要程序的人有责任做到这一点。就我希望生活的世界而言，您肯定不会从我这里得到任何争论。然而，这也有一份记录在案的事实，我所希望的生活世界包括更多的金钱、有真正墙壁的办公室，以及根据联邦法令完全取消中层管理，仅仅是列出可以印刷出来的部分。在我们每天进出工作的世界里，情况有所不同。因为我们处于食物链的底部，我们很少有奢侈品可以要求任何东西。而且，因为我们所写的软件的需求来自那些职位比我们高的人，所以我们通常会收到各种形式的需求，其中没有一个是组织好的，而且很少有详细的。因此，在设计之前，确保需求清晰且有据可查实际上是我们的工作。否则，这根本不会发生，而我们将是最终为此付出代价的人。您什么时候需要一个好的管家？
你不必喜欢它。它只需要清晰。
此时还应考虑另一件事，即使我们一旦开始处理我们的程序就倾向于变得有点占有欲，但在需求方面，我们是否喜欢它们并不重要。唯一重要的是它们精确且毫不动摇。无论您是雇佣兵还是全职员工，在管理层的眼中您都是被雇佣的枪手：他们雇佣您来编写他们需要或想要的软件，而您的工作仅仅因此而存在。
我曾为一家公司工作，该公司让我的团队负责编写一个数据库系统来管理客户信息。由于这是一家全国性公司，我们的部分需求是让数据在三十个城市保持最新。高层决定应该通过复制数据库来完成，每个城市都有数据的副本。当任何一个城市更新信息时，其他所有城市的数据库都应通过公司 WAN 实时更新。我们实现了这个系统，并按时、按预算交付了。大约在这个时候，互联网成为家喻户晓的词，这当然意味着它是那些时髦的东西之一，中层管理人员认为我们应该使用它。因此，在我们完成在三十个城市安装了他们所要求的系统后不久，我们就收到了消息，所有数据都应该驻留在单个位置的一台计算机上，并通过 Web 浏览器界面为这三十个城市提供访问。因此，现在已安装并服务于其目的的系统将被丢弃并从头开始完全重写，以提供完全相同的功能。我靠数豆子为生（除非你想把咖啡也算进去），所以我不知道他们在项目上浪费了多少钱。但这让我在那些飞来飞去的显示器的事情上感觉好多了。
我们应该从这个例子中注意到几个重要点。首先，显然非常浪费，实现一个系统、部署它、对其操作进行用户培训，然后立即将其废弃，仅仅是为了在不同的平台上做完全相同的事情（而且只是为了赶时髦）。但是，那不是我的问题。我被雇来写软件，而不是管理公司。此外，如果他们要付我两次钱来写同一个系统，我的银行在存款方面并没有什么区别。换句话说，因为这不是我的公司，选择实现哪个程序或它们的需求是什么，不是我说了算的。如果我对此事有强烈的看法，我需要辞职并创办自己的公司。否则，我有责任执行雇用我的人的决定。
话虽如此，这里要指出的第二件事是，该公司浪费的钱很可能足以让我一年或两年都躺在沙滩上，手里拿着一杯玛格丽特。这笔钱被白白花费的原因是需求过程中的根本错误。在项目甚至还没有一个程序员听说之前，他们就在指定如何去做，而需求阶段是关于“什么”，而不是“如何”。他们白白浪费了巨额资金，只是为了改变做事的方式，而业务需求已经得到了满足。不幸的是，当钱像这样被白白浪费的那个晚上，夜班保安和他搭档正在度假，这真是太遗憾了。这笔钱可能足够支付所有治疗费用了。
如果您想花时间编写一个能激发您个人热情的系统，您可能需要自己开业。我曾被要求写很多我并不觉得特别引人入胜的东西。我能接受。我只要求的是，如果你要让我枯燥乏味，请以一种非常精确的方式去做。如果你想让我写两次你的系统，只要第二次迭代和第一次一样精确，我都很乐意。我必须给这些人一件事以表赞扬：他们不知道自己在做什么，但他们能非常详细地向你解释。
权力在哪里？
无论实现某个软件系统有多大意义，当它交到我们手中时，问题不是“我们为什么要写它？”而是“我们到底要写什么？”如果我们能对后者得到令人满意的答案，最好是书面的，那么我们就有机会满足最终等待我们的截止日期。在确定这些需求时采取的第一步，除非您在企业美国徘徊了一段时间，否则似乎是在做一件显而易见的事情。作为程序员，我们无法声明一个软件已经完成。相反，我们食物链上面的人必须批准该系统并宣布其完成。谁拥有这个权力？是一个人，还是必须在我们可以完成代码（以及我们自己）之前得到满足的某个正式或非正式的联盟？总之，谁来做决定？
在我们确定了这个人或群体之前，我们不知道在项目结束时（当我们完成时）以及在项目开始时（当我们想将需求刻在石头上时）应该找谁。这是一个常见的错误，以为如果我们的老板来告诉我们写程序，那么他一定是决策者。我敢肯定，特别是如果他是中层管理者，那么他拥有的项目定义权和你差不多。如果你在需求阶段把自己的命运交给他，你最好储备一些浓缩咖啡。你将需要它。在任何足够大的、有中层管理人员的公司里，通常的情况是，在你老板上面的人才是真正需要对你编写的程序满意的人。你的直接主管很可能不是程序员。因此，他既没有训练也没有动力去向他的上级争取更多关于项目的细节。事实上，他很可能会避免这类事情，因为在商界引起太多噪音的人在晋升方面通常会被放在慢车道上。
如果您在大公司工作，您可能没有太多中层管理人员需要打交道。但这并不意味着，在编码完成后，只有要求你写程序的人才需要满意。其他部门的人可能也参与其中。如果您从事垂直市场，可能会有重要的客户也有发言权。基本上，任何想在其中掺和一脚并且有足够政治影响力的人都必须被考虑在内。无论您的公司结构如何，当您的团队收到要编写程序的指令时，第一步也是最关键的一步是快速准确地确定谁是拥有您系统最终决策权的人。再说一遍，您可能会想把这项职责推给您的项目经理，然后回到您的编译器。但是，您必须记住，您在一个团队中。在我们这个行业，一个人的命运是大家共有的。如果您的项目经理压力很大，住在加班城，那么您很可能也会如此。不过，团队合作的好处之一是，您有更多的人可以承担任务。这会派上用场，因为确定主要参与者可能需要一些侦探工作，而您没有多少时间来弄清楚。
要提前知道，在我们这个行业里，有时你必须在采取涉及一些政治风险的行动和忍受你不这样做肯定会降临到你项目上的后果之间做出选择。如果有一些简单明确的规则，每个公司都认同，让你能在正常的指挥链内运作并完成交付软件所需的一切，你就不会面临这种困境。这些规则不存在。如果你是个好孩子，你会相信你在食物链中的上级，然后简单地听从你的直接上级的指示。我承认，你可能不会被骂太多。然而，如果一条路提供了一点政治风险，另一条路则保证了我们在每一次发布中遭受的邪恶。我早就决定，我受够了毫无意义的混乱发布。
政治是不可避免的现实
事实上，多年前我也对政治做了一个决定。我曾经有一个很多程序员都有的哲学：我就是不参与任何政治上的胡闹。我是一名程序员，我来这里是为了编码，如果其他人想围着饮水机站着玩权力游戏，那就随他们去吧。我有重要的工作要做。我最终来到一家小型公司，负责一个只需要几个程序员的项目。我的项目经理，也就是开发主管，实际上是一位非常出色的数据库程序员。他非常出色，以至于他总是埋头于数据库，积极回避任何项目管理职责。
最初分配给这个项目的程序员是个聪明人，但他对于设定的截止日期来说，一个人太少了。经理急需充实团队，而我想要参与这个项目。我渴望玩这项技术，而且我喜欢已经在那里的那个人。然而，有一个新来的家伙，他甚至连最基本的编程语言都掌握不了，更不用说那些技术了，是可以安排的。不刻薄地说，让我们说，无论有多少经验，这个人都不可能成为一名优秀的程序员。有些人有天赋，有些人则没有。尽管如此，完全处理这个问题本身就是一种分心，使经理无法享受他的数据库编程，所以新来的家伙很快就被安排到了团队中，这样他就可以回到他的乐趣中去了。
当然，项目进展迅速恶化，因为最初的编码员不仅要做好自己的工作，还要照顾新来的家伙并为他收拾烂摊子。几周过去了，经理们急于让项目重回正轨。显然，解决方案是增加人手。这次，由于主要程序员的游说工作，我被安排了。我们决定，首先要做的事情是减掉一个人，这样我们才能完成一些工作。我是一个非常健谈的人，而主要程序员在政治上更有策略。因此，我在毫无外交辞令的情况下与经理对质，让他把那个人调到相当于刮椅子底部的口香糖的职位。事后看来，我可能发表了一些关于当初分配这个白痴是多么愚蠢的评论。我还相当强势和要求严格，因为我们已经在加班了，而这个家伙却让事情变得更糟而不是更好。如我所说，我对政治不感兴趣，我将其视为一个简单、明确的技术问题。这不是一件很聪明的事情，但我当时没有意识到。
最后，我们在无数个通宵之后，项目延迟了两周交付。这不算按时且在预算内。然而，在我们这个行业，延迟两周也比平均水平要好一点。尽管如此，当一切都完成后，我突然发现自己进了经理的办公室。当我从谈话中回到我的隔间时，我的网络登录和我的工作都消失了。给出的理由是项目延迟了，但奇怪的是，只有一个程序员被解雇了。事实要简单得多：我惹恼了错误的人，我为此付出了代价。
我感到难以置信，尤其是在我刚刚为了成为一名敬业的员工而加班付出了巨大的努力之后，我去找了一位公司老板。他是个好人，他实话实说。他同意情况很糟糕，但指出我的经理是开发主管，除非有极其令人信服的理由推翻他，否则他必须支持他。然后他告诉我一件至今让我难忘的事情。他说，我和他一样清楚，虽然技术上我受到了不公平的对待，但政治和任何其他方面一样，都是商业中真实且有效的考虑因素。他只说对了一半。关于政治的说法是真的，但当时我并不知道。我当即决定，虽然将来我可能会偶尔输掉政治斗争，但我永远、永远不会因为不参与而输。
那位比我更有常识的主要程序员，在公司里继续晋升。他至今仍是我的朋友，并且由于出色的技术能力和出色的政治技能的无敌组合，他在编程业务中持续发展。而且，虽然我肯定没有赢得我打过的每一场仗，但我再也没有忽略过政治现实。
我刚才给出的例子与定义软件项目需求无关。但是，它与如何获取它们有关。正如我们所考虑的，很可能在你可以停止编码并睡觉之前必须满足的人们比你的直接上级更高一级。这构成了一个困境。如果你越过你的经理，你就有可能惹恼那个可以消除你的收入来源的人。另一方面，如果你不这样做，你根本没有时间花钱，因为你将永远在办公室里为不断变化的需求而编码。我们稍后会讨论一些与决策者直接沟通的方法。现在，足以说明的是，我们的第一步是确定谁真正拥有软件的批准权。在你、你的同事程序员和一点点询问之后，一旦你决定去寻找，你会发现这通常并不难。
识别其他有影响力的人
在注意到权力在何处之后，接下来要写的是一个政治性较小、实际性较强的问题。任何系统都将有一些领域专家，即那些拥有与正在开发的系统相关的业务经验的人。例如，我参与的一个项目涉及空中交通管制软件。办公室里的几个人以前曾担任过管制员，他们被认为是领域专家，因为他们曾担任过这个职位，并且知道管制员需要什么软件。了解哪些领域专家将参与定义您系统的需求非常重要，因为这些人会为您的软件开发带来非常实际的视角。最终，人们将使用您的程序来完成一系列目标。您从领域专家那里获得的意见越多，您的软件就会越好。值得一提的是，这些人通常也具有一定的政治影响力，否则管理层一开始就不会让他们参与定义软件。
如果对您正在做的工作类型是可能的，那么列出一些实际用户，也就是将使用该系统的真实用户，也是一个好主意。他们通常拥有与其他人截然不同的视角，而且他们还可以帮助您澄清需求。最好现在就听到他们的声音，而不是等到软件部署后，他们不喜欢，而您却发现自己在项目的 Beta 测试阶段又得重新设计它。这种情况确实发生过。
我意识到我经常把美国企业描绘成一个常识从未被优先考虑、人们总是搞阴谋、不讲道理或根本难以相处的地方。虽然这种情况足够频繁，以至于忽视它很愚蠢，但很多程序员生活在一个更准确地说是这种胡闹与聪明、务实、敬业的团队相结合的环境中。如果我强调商业世界怪异的一面，那只是为了让您意识到每个公司都有那么一点点。实际上，有些公司里这方面的比例很高。因此，您忽视它会适得其反。
我们暂时假定，开发周期中的许多混乱不是由于人们不愿意做出必要的改变，而是由于高层管理人员根本不理解他们的做法正在导致一次又一次的灾难。这种情况非常普遍。因为商人想成功，如果我们以明智的方式行事，我们就有很大的机会。
推销过程
到目前为止，我们已经确定了决策者、领域专家和实际使用软件的人。接下来我们需要做的是在过程中插入一个暂停。通常，我们会收到非常高层级的需求，并期望开始编码。项目此时进入设计或实施工作，是由于没有人建议有更好的方法。这就是我们现在要做的事情。
开发工作规模各不相同，从一个程序员到拥有多个团队的大型团队，因此没有一个唯一的正确人向您提出这个建议。如果您是一个团队中的编码员，请争取您同事程序员和您的团队负责人的支持，然后去找项目经理。在较小的团队中，可能没有正式命名的项目经理，在这种情况下，您的团队只需与食物链的下一级交谈。无论如何，如果您能首先说服您的同事并争取他们的支持，您就会更成功。如果您中有谁能成为更好的发言人，请让他了解您想做什么，然后就务必利用他的能力来促进团队的利益。
安排与相关经理进行一些时间来谈论需求后，首先简要回顾一下您目前掌握的内容。因为如果您有详细的规格说明，您就不必费心去做这些，所以您应该很容易指出您收到的需求中的模糊之处。您可能不需要做更多的事情，只需要提及一些高层需求，然后开始“天真地”询问经理，这些具体是什么意思。很快就会发现，您缺少详细信息。此时您只是寻求他的认可。一旦经理同意，是的，事情可能应该说得更清楚一点，您就进入了。
人们总是更容易倾听一个既有问题又有解决方案的人，而不是一个只想抱怨问题的人。现在经理已经同意您的看法，认为从现有需求进行编码会很困难，您只需提到您有一个可能在这方面有所帮助的想法。如果您能与一些相关人员会面并请求一些澄清，您就可以回答您的问题并立即开始编写程序。这很可能不会显得非常不合理，您将被给予机会继续进行。
您向经理展示了多少过程将取决于您的直觉和常识，以及您获得的支援和合作程度。对于一位真正支持任何能改善软件开发程序的经理来说，我们将要进行的这个过程将显得合乎逻辑且富有成效。另一方面，如果您必须为每一步的改变而斗争，您就需要采用所谓的“渐进式销售”。在这种情况下，与其让一个不太热情的通过所有细节来描述一个体面的需求收集阶段，您不如更笼统地谈论与相关人员进行“一两次会议”以澄清问题。这比一个宏大、花哨、耗时费力的过程更容易让他们接受。这让您有机会进入，一旦您在那里，就很容易继续进行“再一次会议”，直到您获得所需的细节。有点卑鄙？也许吧。但是，嘿，他们在软件需求方面已经对我们这样做了很多年了。现在，让我们假设您至少得到了一些支持，并且可以全部摆出来。
定义问题
此时，我们将定义一组问题，我们将在以后偶尔引用它们来更详细地定义需求。这些是需求定义问题，或简称定义问题。它们是：
- 期望的行动是什么？
- 什么启动了行动？
- 它操作什么数据？
- 这些数据来自哪里？
- 对数据执行什么操作？
- 执行操作所需的补充数据是什么？
- 补充数据来自哪里？
- 视觉要求是什么？
- 音频要求是什么？
- 其他系统或子系统是否受此操作影响？
- 其他子系统对本操作有何影响？
其中大多数在意图上很明显，但有几个需要澄清。关于视觉和音频要求的问题很容易滑入用户界面设计的问题。那不是意图。我们仍然希望关注“什么”，而不是“如何”。然而，有时，需求的一部分本质上是视觉的或听觉的。例如，空中交通管制员需要知道屏幕上显示的数据是否已过期，因此无效，无论原因如何。例如，屏幕上显示的当前跑道能见度的数字可能表明一天晴朗，没有视觉障碍。但是，如果收集这些数据的设备发生故障，管制员可能不知道银行已经起雾，飞行员看不到一只吉娃娃，即使它在他面前横穿跑道。并非所有管制员都有窗户。因此，可以准确地在需求中说明，需要向管制员提供视觉警告指示，表明当前数据是错误的。可能还需要发出某种声音事件来引起他们的注意。这两者都准确地说明了软件需要做什么，而没有深入探讨如何实现。时刻牢记这一点至关重要。如有疑问，只需问自己正在讨论的主题是关于“什么”还是“如何”。这将使您保持正轨。以下是我们即将使用的流程概述。
- 确定决策者和关键参与者。
- 创建数据录入表单和数据库来收集个体需求。
- 举行一系列会议以澄清个体需求问题。
- 收集和组织个体需求，并将其正式化为一个文档。
- 由决策者签署最终需求文档。
看起来很简单，不是吗？实际上，就是这样。需求收集，剥去浮夸和仪式感的大型设计方法，无非是与相关人员开会，并精确地询问系统需求。
为有效信息收集做准备
虽然我们已经确定了关键参与者，并且我们有一套简洁的定义问题，但在准备需求会议之前，我们还需要做一些其他有用的事情。首先，设置一个数据库，至少有一个记录代表一个需求，以及用于存储从定义问题收集的数据的字段。如果有许多主要类别或子系统，那么也包含这些字段将是一个好主意。您团队中任何最熟悉数据库的人都可以轻松地进行操作，但这些都是基本要素。创建数据录入表单，方便非技术用户以纯文本和普通语言输入此信息。通过您的公司网络，让所有与会者都可以访问此数据库，或至少是数据录入机制。使用此数据录入表单作为指南，使用您公司普遍使用的任何文字处理器创建文档模板。最好有两个版本：一个用户可以直接键入，另一个设计为打印出来并手写。企业中的一个不变事实是，您让他人给您想要的东西有多容易，您成功的机会就有多大。
在您的版本控制系统中设置几个项目，用于存放两类文档。一个项目将保存描述单个需求的文档，另一个项目将作为整个过程输出的实际正式需求文档的存储库。是的，是的，我知道，每个人都直接将个体需求输入数据库会更有意义。由于各种很少有意义的原因，有些人就是做不到。同时拥有文档和打印表格为您无法或不愿意使用数据库的人提供了一个备用策略。您需要信息，而不是坚持原则如何获取。坦率地说，如果他们不使用数据库、文档模板或打印表格，但他们愿意用录音带回答定义问题，那就接受。我们需要的是结果，所以以任何可能的方式获取输入。
现在基础设施已经到位，如果您还没有一份详细说明您目前所知道的关于您需求的文档，那么现在就是收集一份的时候了。一旦您有了这个，就该安排第一次会议了。作为所有会议的一般惯例，提前一两天分发您希望与会者熟悉的文档，这不仅是出于礼貌，而且效率更高。换句话说，在会议开始前给他们足够的时间阅读和消化。很多人无论如何都不会读，但如果您能巧妙地要求他们保留文件中已经涵盖的问题，那会更容易。您会发现其他与会者会支持这一点，因为没有人喜欢参加会议，任何能加快会议速度的事情都会让您在与会者中受欢迎。
另一个富有成效的会议的一般惯例是，总要有人负责在会议期间做记录，并在之后生成一份摘要文件。指定这样一个人可以让他人更容易地专注于手头的事务，并且有助于避免对所发生事件的看法产生冲突。
至少，在这次第一次会议中，您需要决策者在场。如果可能的话，您还希望包括领域专家和任何其他在需求方面有影响力的人。如果您需要更努力地安排一个所有人都方便的时间，那么能让所有主要参与者都齐聚一堂是值得的。每个人都应该有机会阅读您目前所理解的项目的一般性需求。
定义需求
在第一次会议中，您首先要完成的是一些划分工作。对于任何非平凡的系统，您通常可以将需求划分为一些主要类别或子系统。下一步是为每个子系统建立一个焦点小组。您可能会发现有些人需要（或想要）参与多个小组。虽然让所有参与者都在所有小组中工作会削弱目的，但这有时是合理的需要，应该允许。您可能会发现可能还需要一个政治上的需要，这同样重要。为每个小组确定一个领导者，最好是根据小组共识。这个人将作为焦点小组会议的协调员，以保持它们的组织性。当然，您也需要有人为每个小组记录会议纪要。这项工作并不令人满意，所以最好能找到志愿者。
现在您想给这些焦点小组一项任务，然后让他们去做。根据他们子系统中的问题，他们需要列出两份清单：第一份是功能列表，包含所有经多数投票同意的项目，第二份清单包含那些被提及但未获得多数的项目。焦点小组应首先单独进行，列出他们的功能愿望清单。鼓励细节，但此时不要求。他们只需要能够以一种让会议中的每个人都理解的方式来识别功能。在合理的时间（通常是一两天）后，焦点小组重新开会，然后人们通过说服、贿赂和争论来淘汰愿望清单。从这些会议室中移除所有白板擦是一个好主意。
每当焦点小组完成两份清单后，他们都应该将其分发给所有完整小组成员。当所有焦点小组都完成后，就该重新召集完整小组了。此时，每个焦点小组的领导者逐一介绍清单，让小组进行全体投票。同样的规则适用：少数服从多数。但是，此时，任何决策者都可以否决小组决定，接受或拒绝某个功能。这就是为什么决策者必须参加这些会议。他们无论如何都会这样做，而您不希望在您已经编写了该死的代码之后才发生。在审查了每个焦点小组同意的功能列表后，将审查那些只获得少数票的功能列表。如果大多数整体小组成员认为它应该保留，它就进入功能列表。
如果您的项目规模很大，您可能想通过一系列会议来分阶段进行工作，每个子系统一次会议。全天会议很乏味，第二个小时就已经浪费时间了。如果您真的关心保持大家的注意力，任何会议都不应超过一小时。
这次会议或一系列会议的产出是该系统的最终功能列表，尽管定义松散。下一步是回到焦点小组层面。这些小组在各自的会议中重新召集，手头拿着他们的功能列表和定义问题。这个过程的输出是数据库中的一个记录，用于每个需求，并回答了所有定义问题。如何将其输入数据库取决于与您打交道的人最适合的方式。对于一些公司来说，在会议室里放置一台工作站，以便有人可以在回答问题时输入数据，这是可行的。在其他环境中，打印表格并手写填写可能是最有可能成功的方法。即使他们用录音带完成，然后有人将其转录到数据库中，也无关紧要。只要回答了问题。
当焦点小组完成后，数据库中的信息将被用来生成完整的需求文档草稿。根据您的公司做事的方式有多么正式，这可以是一个简单的数据库报告，也可以是繁琐的将信息录入文字处理器中的单独文档。重要的是要以包含所有细节并以决策者能够接受的格式进行。它是您最终希望他们签署的文档的草稿。如果他们是正式而严肃的人，您就必须以同样的精神创建文档，否则它就不会被认真对待。这听起来可能很愚蠢，但这是企业世界中的人性，最终，这份文档——以及您和您的想法——被认真对待是至关重要的。
在分发了需求文档草稿之后，又是另一次会议或一系列会议的时间，这同样取决于子系统的规模和数量。这次您还想让您的一些顶尖程序员参与进来。如果您能做到，让您所有的程序员都参与进来是有好处的，但至少您需要他们将在其上工作的子系统的关键参与者。如果决策者想跳过接下来的一个或两个会议，那没关系，但焦点小组成员必须留下，因为程序员会向他们提问。重复相同的程序，逐一审查每个需求。这次，除了房间里任何觉得某个需求不够清晰的人的意见外，程序员还有机会审查每个功能，并验证他们是否拥有设计和编码所需的信息。
各位，这是你们的机会，所以不要害羞。如果你现在还不清楚，当你启动编辑器时也不会清楚。这是生活中为数不多的可以把话放到别人嘴里的时刻之一。你可能会听到模糊的功能描述，你必须帮助将其转化为严格而具体的要求。我认为有用的方法是，将听到的模糊陈述用精确的术语重复给他们，并征求他们的同意，例如：“我明白了。所以你的意思是我们需要 [用精确的功能描述替换模糊的陈词滥调]。我理解正确吗？”记住，许多参与者不是技术人员，所以你可能需要提供这方面的技能。此时外交手段非常重要，因为你想建立盟友，而不是敌人。相信我，我吃过外交的苦头。
虽然程序员对哪些功能保留、哪些功能删除没有否决权，但他们确实有权将一个需求标记为不完整，这意味着它需要进一步澄清才能进入需求文档。当然，他们能具体说明需要什么额外信息，焦点小组就能更好地配合。此外，程序员可以将一个需求标记为当前状态下无法实现。例如，如果某个功能需要互联网访问，但程序将在一些缺乏连接的机器上运行，那就行不通了。这并不意味着该功能将从需求文档中删除，而是将其列入一个列表，供决策者最终审查。他们是唯一可以决定删除该功能或确保其可实现的人（例如，在我们的例子中，将互联网访问作为产品需求的一部分）。
此外，程序员还可以将一个实际上是设计问题而不是实际需求的需求标记出来。如果人们正确回答了定义问题，您应该不会看到太多这种情况。但是，如果真的发生了，就需要注意，以便程序员在设计时可以与相关人员处理。
派对结束后
当所有需求都处理完毕，不再有需要解决的问题时，草稿需求文档会再次更新并分发。最后一次会议将由决策者和全体成员召开。会议的目标是让所有相关方在概念上“签署”需求，但实际上，应该为所有决策者和每个焦点小组的领导者提供签名行。程序员的领导者也将签名。决策者的签名是强制性的，因为这是整个过程的目的——让有权势的人对一套非常具体的功能做出坚定且公开的承诺。让焦点小组签署文档只是政治上的好处，表明所有参与者都同意这些是福音般的需求。你永远不知道这种事情何时会派上用场。
将文档提交到版本控制系统，标记为最终需求文档，并将签名文档的副本分发给所有参与者。在最后一次会议上，最好让每个人签署两份或更多份副本，以防任何决策者想保留一份原件。您肯定想要一份带墨水的给自己。将其存放在安全的地方，以免被任何流浪犬的尖牙啃噬。
批准后，需求阶段正式结束。对于任何未来的功能请求，都有一个简单的回应。您可以拥有您想要的任何东西，只要它在 2.0 版本中。但是，如果决策者需要一个新功能呢？如果是这样，并且这可能会发生，那么它必须符合定义问题所概述的相同严格指南，并且必须重新审视后续的设计和估算阶段。底线是日期必须相应调整。然而，一旦您接受了将特定日期与特定可交付成果挂钩的流程，您就会发现这一点会更容易实现。
在会议进行期间，鼓励在需求团队成员之间使用电子邮件进行问答。人们的日程安排不同，电子邮件是一种最体贴的提问方式，而不会打断他们正在做的事情。当然，电子邮件也是最容易被忽略的方式。如果您发现有些人倾向于这样做，请鼓励其他人即使不得不去，也要在他们办公室门口等候。体贴是相互的。此外，请提醒团队，就官方程序而言，走廊会议不算数。如果不是书面的，它就不存在。
应对敌对环境
到目前为止，我们一直在假设您将获得决策者所需的参与和支持来遵循此过程。由于政治、变革阻力或人们在商业世界中做傻事的任何其他原因，情况可能并非如此。事实上，您可能会遇到对所有或所有这些方面的积极而极端的抵抗。在我看来，一个流程如果无法在现实世界中运行，无论它在纸面上看起来多么令人印象深刻，都是完全无用的。如果决策者（他们最终是唯一重要的人）不允许或不遵循这个过程，那么有几件事就很清楚了。首先，您处于一个相当糟糕的环境，坦率地说，您可能想掸掉您简历上的灰尘。任何抵制有助于他们按时获得所需软件并良好工作的程序的管理层，都将随时带来麻烦。第二件清楚的事情是，如果这是您的现实，那么您能得到的任何帮助都比您现在拥有的要好。所以，让我们看看一些捷径。这不会产生完美的结果，但任何程度的细节和问责制都比那些将自己定位为不可触碰的人提出的模糊功能请求要好。
无论如何，您仍然必须识别决策者。在这种特定情况下，您需要一个人，就是能够否决其他所有人的最终权威。这应该不难。他会告诉你他不会支持或允许需求会议。这个人是你最终需要说服其做出承诺的人。了解这个人是谁并核实他确实有权批准软件系统至关重要。仍然重要的是要聚集，或者至少识别，尽可能多的相关领域专家。
忘掉个体需求的正式文档模板，但保留数据库。只需意识到您必须自己完成所有数据录入工作。这很乏味，但最终是值得的。
在这个简化的过程中，您将遵循一些相同的步骤，并且仍然从您创建一份总结管理层给出需求的文档开始。您仍然需要澄清。因为决策者不想支持一个合法的过程，您需要用您的问题来针对这个人。我们现在处于敏感的政治领域，所以要非常小心。使用团队中拥有最佳人际交往能力并且不介意冲锋陷阵的人。如果您团队中没有人愿意这样做，您就完了。正常的、合乎逻辑的方法已经失败了，您现在必须决定是否值得冒一些风险来尝试改善您的生活状况。没有人能替你做这个决定。你只有两个选择：更新你的简历或者带上睡袋。
您想亲自问问题。这里的策略很棘手，但目的是让经理清楚，如果您得不到问题的答案，您就无法编写软件。如果您不能与相关方进行您需要的会议，您就无法得到问题的答案。但是，因为这是请求软件的人，他显然可以回答这些问题，因为最终他必须对系统满意。您唯一的希望是保持友好、积极、非对抗性和无可挑剔的逻辑性。如果您以一种看似天真的纯真态度来对待，就更难被抓住。哦，你需要写软件，但你就是不知道你应该写什么，所以问这些问题是自然的，对吧？
这里隐含的陈述是，如果经理想要软件但又不想让你通过常识步骤来定义它，你就会成为他挥之不去的一个麻烦，直到你得到问题的答案，或者他感到厌烦并委派此事。惹恼上级的危险显而易见，这就是为什么你希望你最不惹人厌烦的人来执行这项任务。中断已经足够令人烦恼了。您不希望您的一个家伙带着相当于紫心勋章的解雇通知回来。幸运的是，您至少能从这个人那里得到一些定义。您每次抓住他时可能不会有多少时间，所以您的疑问要排好优先级，深思熟虑，并且准备就绪。如果这就是您世界的极限，那么除了获取信息之外，您的做法也足够引人注目，他会记得他曾承诺过您所要求的细节，仅仅是因为他觉得这很烦人。
在这种情况下，使用小型袖珍磁带录音机而不是试图做笔记也会有所帮助。只要确保他清楚您有它，否则看起来您似乎在欺骗他。未经他人知情同意而录音也有法律上的含义，您就是不想那样做。您只需解释说，您感谢他们的时间不多，所以不想浪费时间做笔记，然后将其放在衬衫口袋里，这样就不会对任何人构成威胁。这会稍微不那么具有威胁性。聪明的兔子不会威胁孟加拉虎。也要准备好被告知关掉它。有些人对被录音感到不舒服，原因有很多。如果对方表达了这样的感受，请迅速而以良好的态度顺从。准备好一个小笔记本作为备份。
如果对方生气到委派，那就是一个机会。抓住它。如果他以前抵制您提出的会议，可能是因为他不想自己处理，您现在可以再次建议“一两次快速会议”与他委派给的人，这相当于同意他的看法。然而，您可能会随意建议，如果带入“另外一两个人”可能有助于加快速度，并且给被委派的人带来更少的麻烦，而这些人正是您已经识别出的领域专家。没有必要宣布有多少人或谁，除非您被追问。即使那样，也没有必要承认全部人数。提及一两个人最不可能引起阻力的人。其余的只是被邀请参加会议。请求原谅总是比请求许可容易。
准备好参加会议，但不要像往常一样提前分发文件。请记住，如果您在这里，您处于敌对状态，需要稍作不同思考。您给予的任何一点善意警告都有机会让某人为您搞砸。所以，带着您准备的高层文档副本出现在会议上，并将其分发出去。您此时做什么很大程度上取决于小组的氛围。您可能会发现，即使决策者是一个固执的令人讨厌的人，但被委托工作的人实际上是合理且支持性的。
您必须凭直觉来处理这个问题。如果您得到所有相关人员的良好态度，您可以尝试建议将其分解为子系统，让每个人收集一些信息，也许与一些用户或其他他们认为对他们的领域有帮助的人会面。此外，您提供一种将帮助他们的方法，即我们已经涵盖过的两份清单系统，并将定义问题列表悄悄地交给他们。换句话说，如果您得到一个好的团队，您就会悄悄地、不引人注目地进入该流程。不要强迫他们进行任何数据录入或其他繁琐的任务。您的主要重点是收集信息，您的次要重点是建立盟友，以便在决策者最终批准需求文档时可以依赖他们。您的团队可以处理任何繁重的工作。您只是不希望这个联盟破裂，所以尽您所能保持顺畅。
如果您参加了委派的会议，并且没有得到支持性的团队，那么您只需回到您用来与决策者打交道的策略：纯真、逻辑、魅力（如果您有的话），以及一个获取尽可能多问题的压倒性目标。在每次会议结束时，只要您能逃脱，就随意问一两个关键人物，他们是否介意本周晚些时候再与您简短地见面，以“回答一两个问题”。目标是您最需要信息的人。如果您能做到，您就可以利用这种方法一次举行一系列迷你会议，每次与几个人。同样，您可以路过一个人的办公室（在这种情况下电子邮件毫无用处），然后问他们是否能抽出几分钟时间来回答几个问题。换句话说，您的任务是收集信息，即使这意味着挨家挨户的战斗。所有这些都很麻烦，但仍然不如在只获得最模糊的需求并且知道这些需求会不断变化的情况下应对最后期限和压力那么麻烦。
如果您根本无法实际接触到决策者怎么办？这是一个艰难的局面。这时，就去找他们下面一级的官员，并运用同样的策略。底线是，如果您没有得到决策者在您的软件上做出决策的相关人员的一些合作或准入，您基本上就完了。然而，我曾在大型国际公司工作过，虽然从 CEO 那里可能会传来创建软件的总体指令，但实际上批准您的软件已完成的人通常在整体计划中离您并不太远。
同样，无论您被迫采用以上哪种策略，您的最终目标仍然是获得决策者对您详细需求的官方批准。最好是以书面形式获得。然而，如果您处于一个敌对或不支持的环境中，那是不可能发生的。在这种情况下，您就拿到最终的需求文档——在现有条件下您能做的最好的文档——并在版本控制中标记它，以防止有人以后对其进行篡改，然后将其放在网络上。然后，您发送一封电子邮件，说明该文档的存在以及如何找到它，收件人是任何在决策过程中有影响力的人，换句话说，所有被认为是决策者的人，以及所有领域专家。在您的电子邮件中，您应该有礼貌地说明，据您所知，这是您所知道的唯一需要实施于软件的东西，并且除非您另有说明，否则这就是您将要实施的一切。语言应该是非对抗性的，更像是告诉他们，您将感谢任何可能有的澄清或输入。如果您收到任何回应，请尝试通过定义问题来引导他们了解他们可能想要偷偷添加的任何功能。经过一轮这样的讨论后，更新文档并重复发送电子邮件。当您发送电子邮件并且一两天后没有收到任何回复时，那么这就是您能得到的最好的结果了。然而，当发布高峰期到来，人们开始试图添加新需求或更改现有需求时，您就有了纸质记录（将您收到的所有电子邮件回复打印出来并保存在家中）来帮助抵御最后时刻的改变。这不如决策者的签名好，但比您原本拥有的弹药要多一些。
政治从未远离
尽管我们已经涵盖了从建设性和合作性环境到敌对和不合理环境的所有方面，但一些基本概念仍然没有改变。要定义一个给定的需求，您需要问具体的问题。要将需求与日期挂钩，您需要正式化最终需求并让决策者承认它们。尽管我们在这里讨论的所有问题可能都很重要，但也许最关键的考虑是认识到，如果您在确定需求时没有得到全力支持，那么您就在处理政治问题。这是一把双刃剑。虽然政治对我们大多数人来说是不愉快的，而且如果被忽视或处理不当肯定很危险，但程序员也可以利用它们来获得他们想要的东西。这在需求收集阶段最为普遍，因为人们有自己的个人议程在争夺他们想要的东西。那就是政治，纯粹而简单。然而，您会发现，尽管我们讨论的是实用的、基本的编程问题，如精简设计方法、低级估算技术等，但政治考虑将永远不会远离。如果您靠在商业世界中谋生，这是不可避免的现实。最终，成功交付软件的程序员通常是那些拥有良好的技术技能、良好的组织技能、良好的政治技能，并且愿意在被要求时使用它们的人。