非技术人员如何学习为小型项目编写规范？

非技术人员如何学习编写小型项目的规范？

我的一个朋友正在尝试将统计项目的某些开发外包。

特别是，他在excel中做了很多工作，并且希望将脚本的创建工作外包出去，以手工完成现在的工作。

但是，我的朋友是非技术性的。他不擅长编写技术规范。

当他确实编写规范时，将按照您描述在excel中做某事的方式编写（转到此单元格，然后将值复制到该单元格）。它也太冗长，并且多次进行示例。我不确定他是否恰当地描述了极端情况。

他外包的第一个项目失败了。我认为他过多地描述了一些细节，但未充分说明极端情况。他和/或他雇用的编码人员没有仔细考虑并提出适当的问题。我不确定。我与他进行即时通讯，花了半个小时才找到一个描述，该描述本该花了五分钟或更短的时间来描述。最后，我为他编写了脚本，但没有检查为什么他的编码器处理失败。

他已向我寻求帮助。但是，我拒绝参与，因为按照他的规范并将其转换为明确的要求比执行明确的规范要多十倍的工作量。

他学习的正确方法是什么？他有可用的资源吗？他有什么方法可以和编码员一起从小型低压实践项目中学习？

他的大部分脚本都是面向统计和数据处理的。例如，使用此列并对其求平均值。在这种情况下删除这些行。因此，挑战与指定网络应用程序不同。

我看到了解决此问题的两种可行方法。但是，重要的是要意识到两件事。首先，需求工程是一项艰苦的工作-将一个想法转变为足以建立系统的正式规范需要大量的时间，精力和实践。其次，如果您有良好的要求（从正式规范到不太正式的用户案例和用例，可以采用任何格式），则实际构建软件（并尽早构建）将变得更加容易，便宜和快捷。

如果您的朋友将要构建许多软件工具，或者打算将它们外包出去，那么他应该至少在业务目标和运营概念级别上学习如何编写软件需求。关于软件需求工程的两本主要书籍由卡尔·威格斯（ Karl Wiegers）撰写-《软件需求》（第二版）和《关于软件需求的更多信息：棘手的问题和实践建议》。我希望他会雇用的大多数人都想要某种描述该系统的文档，至少是在业务目标或运营概念的层次上，这些书会涉及到该文档。他们还探讨了需求工程的其他方面的方式和原因，我怀疑优秀的开发人员会在项目早期进行这些工作。

第二种选择是雇用具有软件开发和需求工程（甚至可能是某种系统工程或系统架构）经验的人员来了解问题空间，并确定需要软件解决方案的地方和不需要软件解决方案的地方有益的是，编写文档，甚至可能监督或进行开发工作。但是，这可能会更昂贵，并且相当于长时间雇用一名全职软件开发人员来开发不仅需要的系统，而且还开发所需的需求和体系结构。

老实说，我认为您的朋友所经历的事情对于不了解软件开发过程的人来说并不罕见。我也不认为应该完全归咎于他。如果第一个软件项目没有很好的需求，那么外包给它的开发人员应该澄清，完善和记录需求。坦率地说，如果您不愿意花时间或不愿意与非技术用户/客户合作并制定良好的技术规范，则我不确定您是否是参与其中的合适人选是在任何工程学科中执行需求工程的任何人的关键角色。

我认为最佳解决方案实际上是我的两种选择的结合。我认为您的朋友（也许您也应该）应该了解需求工程中涉及的内容以及拥有可靠需求可以为项目带来的好处。作为软件开发人员，您还应该更加熟悉需求工程以及如何根据软件项目来引出，记录，分析和管理需求-对于在软件生命周期中任何阶段进行工作的任何人来说，这确实是一项宝贵的技能。

当我需要来自非技术客户的规范时，我通常会要求他们以通俗易懂的语言写出他们想要完成的工作。如“当我按C时，应用程序应执行A到B，但仅当D时”。“因为D表示……”的额外奖励。

实际上，“使用此列并对其进行平均”。是朝正确方向迈出的一步。更好的解释是“表包含该内容和该内容”（如果结构是预定义的）。“获得X的平均值”。基本上，在不丢失细节的情况下，尽可能采用最少的技术方法。

换句话说，描述想法，而不是实现。

然后，一个有爱心的程序员应该能够理解他所从事的工作的实际目的，并亲自选择正确的步骤，并提出一些不明显的问题。

如果没有足够的人在意并理解过程，那么该项目无论如何都会失败。

他可以尝试使用情节提要方法。

让他写下事情清单（故事应用程序将要做）列表，并在该列表中进一步阐述每个故事的功能。

他可以使用Asana之类的工具充实项目范围和功能，甚至与开发人员进行互动。

将其转换为明确的要求比执行明确的规范要多十倍的工作量。

阿们 这也解释了为什么：

他雇用的编码员没有仔细考虑并提出适当的问题。

在大多数编程项目中，了解需求是最困难（也是最昂贵）的部分。当非技术人员编写需求时，他们通常只记录他们要替换的解决方法（“打开Excel，单击单元格B3 ...”）。他们所希望的最好的办法就是完全复制他们当前的困难！

我知道解决此问题的最有效的方法是鼓励此人编写用例（“用”加上“松”）。而不是编写要求，而是描述系统的使用方式。这给开发人员留出了一些余地，可以提出比用户现在更好的解决方案。

听起来您的朋友的书面交流技巧不好，使这个问题更加严重。他/她要么必须投入工作以有效地交流他们的想法，要么要付钱给程序员以从他们那里获取信息。这两种方法都很痛苦且很耗时，但是自己动手要比付钱与您一起做要便宜。

无论如何，这是一个常见且令人沮丧的困难，因为富有创造力的人要么想法不完整，要么无法用不到一百万个单词来描述它。这个人应该尝试找到一个非常有耐心和有见识的程序员，他们愿意深入他们真正尝试做的事情并实现它。

他雇用的编码员没有...问适当的问题

那是灾难的秘诀。那，以及程序员会问的期望。编码人员喜欢编码而不是进行交流，期望他们在没有动机的情况下改变习惯，这是不现实的。

如果您的朋友想完成工作，那么他们最好建立一个与编码员进行持续沟通的过程-而不是编码员，应该由您的朋友来扮演积极的角色。“向我展示每个星期一的工作，并在每个星期二安排两个小时讨论此事”。

• 作为介绍，请向他们提供一些轻量级的迭代和敏捷开发方法的概述（Wikipedia文章将做），以便他们对它的外观有一个了解。
   
• 为了帮助他们理解过去的失败，请向他们提供有关Waterfall / Big Design Upfront的轻量级概述（其中包括批评-维基百科的文章也会这样做）-这些通常可以很好地解释通常很难正确指定事物的原因在前面。

以我的经验，与非技术客户一起获得所需软件功能的最可靠方法是永久地交流和迭代功能描述，而不是一口气指定它。

他的大部分脚本都是面向统计和数据处理的。例如，使用此列并对其求平均值。在这种情况下删除这些行。因此，挑战与指定网络应用程序不同。

有所不同-似乎比指定网络应用程序要简单得多。这是一个逻辑过程。这是简单的东西。

您的朋友只需要写下他执行此过程时要执行的步骤。他可以随心所欲地做到这一点，但要重点关注的关键是准确性，简洁性和清晰度。没有理由不能仅仅像稿件一样在文本中完成它。它将从组件或任务的逻辑划分中受益，并且可能作为流程图或图表很好地工作。

现在，您的朋友应该找到一位称职的分析师/开发人员，并逐步参与他们的服务。他需要提出自己的期望-每天或至少每周多次，您的朋友应该与开发人员会面，并亲身看一下进度演示。在这些演示过程中，您的朋友将向开发者支付他的时间，但是确保项目按规范运行是值得的。规格的任何更改（即您的朋友遗漏的内容）都需要协商，并且可能会加到报价中。

请注意，我说的是“有能力的”-这与“平均”的能力不同，因为有很多“一般”的开发人员没有能力。如果您的朋友刚刚找到最便宜的编码器，或者只是在网上找到某人，那么他应该会遇到问题。并不建议在网上找到工作的人不好，但是如果没有推荐，您就不会雇用某人。

您的朋友必须找到合适的人。在任何软件项目中，都需要分析师，程序员，系统管理员，测试人员和项目经理。您的朋友想要“外包”这些角色的次数越多，提供者的技能就越熟练，您的朋友应该支付的费用也就越多。

很抱歉成为打破这一点的人，但是学习如何编写正式规范不是非技术人员的工作。采访非技术人员是开发人员的工作，试图倾听该人员对您说的关于他们所追求的东西，确定客户真正想要的是什么（而不是他们认为他们想要的是什么，并非总是一回事），建立一个相对非正式的需求文档（结构合理但试图避免客户不理解的行话的文档）并与客户一起查看该文档。

一旦客户对非正式需求文档感到满意，您就可以将其用作起草更正式的需求规范的基础，该规范开始涉及所需的更多技术细节。

这整个过程称为“需求捕获”，它构成了软件工程过程的第一步。实际上编写软件只是软件工程中的一小部分，可悲的是许多软件开发人员都忘记了这一事实。他们似乎忘记的另一件事是，非常需要与客户进行沟通，并在整个过程中与他们保持对话，以确保事情步入正轨。

对于与非技术人员的交流，至关重要的是，在与计算机和软件开发人员交谈时，尽量避免使用术语。如果他们在自己的领域中使用行话，那么理解这些术语的含义就很重要，因此您可能需要草拟项目词汇表以获得这些术语的正式定义。毕竟，您是在为他们工作，因此了解他们的来源很重要。

您应该尝试使用非恐吓性的方式来与客户交流，而不要用行话来表达，用普通英语编写的文档是有帮助的，但是软件行业的很多人习惯于为计算机而不是人类编写代码，因此可能会发现这一点难。此外，无论他们的语言多么简单，客户都不喜欢阅读大量的论文，因此您可能希望使用视觉辅助工具。图表，线框和情节提要在这里是有用的工具。

简而言之，核心是学习您的语言不是您的客户的工作，而是学习他们的语言是您的工作。