与程序员沟通以定义项目的最佳方式？

Question

给程序员定义项目的最佳细节是什么？

简单地说，我知道我想做什么，但我对编程一无所知，那么将项目定义给程序员的最佳方式是什么，这样他/她就能给我我需要的东西。即 项目总结，设计简报，流程图？

Answer 1

避免假设。尽可能详细地说出你想要做的事情。确保每个问题都可以用“是”，“否”或X来回答，其中X是一个确定的值。不要在说明书中留下任何解释或任何遗嘱。

指定最终用户可用的每个项目，其行为和样式。在你要求某人编码之前，请确保你确切知道自己想要什么。

确保您的文档整齐有序。我相信你可以在网上找到很多关于商业要求的白皮书。

Answer 2

撰写产品需求文档。

http://en.wikipedia.org/wiki/Product_requirements_document

阅读Joel Spolsky的这个系列

http://www.joelonsoftware.com/articles/fog0000000036.html

这是一个例子

http://www.joelonsoftware.com/articles/WhatTimeIsIt.html

Answer 3

使用SCRUM方法。

根据“用户故事”描述事物（用户想做什么） 描述“用户故事”如何相互交互。

让开发人员弄清楚如何。

让他/她定期演示他们所做的事情。如果你改变主意或不按自己喜欢的方式进行，那么你可以更新开发人员他出错的地方，并且可以更新他的方向。

规格/要求和瀑布方法已经一次又一次地显示不起作用（或者我应该说提供一种精确规划项目的方法）。

Answer 4

根据我的经验，尝试定义您想要的内容，将其抛到墙上并期望程序员能够提供您想要的内容是一个坏主意。构建软件最难的是它的复杂性，如果你准确地指定了你想要的东西，你可能提供了与你自己编程时一样多的细节。

您可以做的最好的事情是尝试与程序员一起工作。找一个能够以较短的增量交付工作软件的人，每月一次或每两周一次。并提供有关您喜欢什么，不喜欢什么以及您想要什么的反馈。尝试确保程序员每次都为您提供经过测试和运行的软件，这样您就可以真正了解已完成的工作量。

这种工作方式使您能够确切地确定您认为重要的功能的优先顺序。你先实施它们。缺点是这会花费你更多的时间和精力。

Answer 5

无论你做什么，写下来，签署它。

然后交给他们，并同意遵守文件上的说明。

我们作为开发人员的最大问题是不完整或错误翻译的规范，我们真正想要的是一张非常清晰的纸张，你应该能够在项目中遇到任何问题，它应该在文件中以术语清晰的术语表述。

至少我们可以这样说“看，我们做了你问的问题，这里写的是什么，这里没有写的任何东西都不能指望我，它不会发生”。

这听起来可能听起来不错，但请相信我，你不喜欢它会让你更难以清楚地尝试。如果一个目标没有进入论文，不要尝试稍后滑动它，在需求之后重写规范只会导致你让事情过于夸张。

计划里程碑，签名，执行。有些东西被遗漏，它会延伸到后来的里程碑。你没有做到这一点，它永远不会发货。

那些贬低我的人 仅供参考，我认识的每个人都有这个问题。太糟糕了。我有一些员工，这些员工被那些透露规格的公司有效地勒死了，这些公司甚至从未讨论过。你不能指望有人做一些没有规定的事情。它甚至不可能。也许它是在幻想的土地上，或者是你一直在关注的“企业现实”，但不是在现实世界中。

在建造房屋时，人们不会“躲避它”。

一个家庭便利的人建造的房子，因为他们决定如何做到这一点需要数年才能建成。 的＆LT; /咆哮＆GT;

Answer 6

1. 您需要该应用程序执行的操作的完整摘要/概述。
2. 程序员编写应用程序所需的任何特定于业务的知识的总结（例如，如果您需要保险单费率计算器，程序员需要了解一般如何计算费率）。 / LI>
3. 将使用/要求的任何数据的描述，以及如果您拥有它们的示例（例如示例Excel电子表格，数据文件等）。
4. 如果新项目是旧应用程序的替代品，那么旧应用程序的副本（如果有的话，源代码就很好）是程序员非常宝贵的信息来源。

有些人可能不同意，但我通常发现流程图通常不是很有价值。

Answer 7

最好的办法是找一个有能力开发非技术客户规范的程序员。其他客户的口碑推荐可能是找到能够做到这一点的程序员最可靠的方式。

说真的，这实际上是所有开发人员的典型场景。客户通常没有技术背景，也没有深入研究编程问题的愿望。他们通常甚至不知道自己想要什么，更不用说可能的了。因此，开发人员不得不缩小差距，与客户建立联系并将客户的想法转化为技术考虑因素。

为了使事情保持正轨，我建议以迭代方式在T＆amp; M基础上进行工作。在系统开发过程中经常对系统进行评估和演示，对您所看到的内容进行反馈，并重新评估系统的价值以及您所看到的开发质量。如果它感觉像是梨形，请拔下插头。

我一直对大多数非技术人员在交付之前设想软件解决方案有多糟糕感到惊讶。我参加了无数早期的项目会议，在那里我可以保证会议室里的每个程序员都在构建相同的图片 - 包括设想某些功能需要子程序调用 - 但同一会议中的客户都不是' t在同一页面上。很多时候，直到客户真正看到产品才知道这个鸿沟，这正是程序员在发布会上所描述的，并且他们指出了一些显而易见的（对他们而言）缺陷。

如果客户在开发结束前没有看到产品，那只会受到伤害。所以请尽早查看，经常查看并提供反馈。

Answer 8

您需要找到一位有非技术人员编写自定义应用程序经验的程序员。此人还应具备技术项目管理经验。他（或她）应该在您的帮助下创建一份需求文档和一个功能规范，您将在实际开发之前签署该协议。一个真正擅长这一点的人有很多经验并且不便宜，但与许多开发人员打交道非技术客户就像与开发商打交道一样困难。

即使你签了它，也不意味着以后不能改变。如果您想要更改，您将更新您的文档，开发人员将为您提供新的成本和时间估算。

现在出现鸡蛋问题。如果你不是技术人员，你如何找到一个优秀的软件开发人员？向你认识的人寻求建议。如果您需要采访某人，请他们提供样本要求文档和功能规范。访问他们开发的网站。可以肯定的是，这将消除许多完全合格的程序员，因为许多人由于机密性问题无法共享这类东西。但是，您需要了解他们可以了解您的业务需求并创建产品来解决这些需求。

如果您对需求文档和功能规范不满意，请不要继续使用该人员。事情必然会变得更糟，而不是更好。你最终会在糟糕的情况下抛出好钱。

与很多开发人员沟通真的很难。就像找医生一样，找一个你很满意的人，听你和你的顾虑，并用他自己的话来重复这些担忧。

祝你好运！

Answer 9

只是为了补充其他人在这里所说的话，如果这是一个外包项目而不是内部项目，那么你必须更加具体。而且我不在乎你是否外包给印度，中国或街头的人 - 如果你不具体，你可能会得到的东西能够满足你在纸上的最低限度，但不是你想要什么。内部程序员更有可能要求澄清并按你的意思行事，而不仅仅是你要求的内容。

Answer 10

  

与程序员沟通以定义项目的最佳方式？

好问题。几个解决方案。

• 简单的项目概述/设计简介 - （免费工具www.createbrief.com）
• 创建项目范围（我使用Evernote）
• 在Github Scrum Boards中打开问题（通过Zenhub）

该简介旨在帮助开发人员获得大笔画概述，同时项目范围将更加详细。在项目范围中，我通常会概述视图并相互处理。在创建了这两个文档之后，我在Github中使用Zenhub Scrum Boards打开问题来管理每个任务和优先级。这也可以帮助您为多个程序员分配多个问题。

祝你好运！

Answer 11

其他海报上面的一些好建议。

定义你想要的基础是一个明显的开始。但根据我的经验，如果不考虑例外，那么下游流程也会受到影响。在软件开发或测试后期之前，这些几乎总是被遗忘。因此，在事情不顺利时，要考虑一下您希望软件或流程如何工作。例子：

• 哪些基础数据来自哪里？当数据不在预期的位置时，您想做什么？
• 您希望软件在验证方面做多少？如果用户输入了错误数据，您是否有手动过程让他们通过，或者您是否希望软件足够智能以便于纠正？您希望软件在处理异常时具有的智能水平可以显着改变复杂性。
• 您需要多少数据透明度？您可能只需要一些元素，但是如果有例外，提供额外的数据可能意味着用户能够自助解决问题，而不是必须联系帮助台，其他用户和程序员，这是相当昂贵的。

程序员喜欢帮助，但不是那么多......他们更倾向于使用下一个功能而不是生产支持。但是，如果异常处理规范很差，那么项目中的每个人都会最终做到这一点。

通过迭代开发，它肯定有助于在开发周期中传播您的需求流程。您并不总是知道需要处理哪些类型的异常。有些不是由业务驱动，而是由技术问题驱动，例如用户界面行为，与其他系统的集成等。尽管如此，更快的质量要求越快，整个过程就越好。

Answer 12

很难得到一个复杂的想法，比如一个完整的软件工作，这就是需求文档的用途。在其他帖子中已经说过;你需要准确地指出你想做什么，绝对不做任何假设。两个人可以用不同的方式设想某些东西与同一个解释，这就是为什么指定你想要做什么非常重要的原因。

也是先决条件。确保你告诉程序员它应该在什么环境下运行，是桌面还是服务器以及ram和操作系统的数量？

您不必指定它是如何工作的，这确实是程序员要弄清楚的。如果你有一些想法，你可以引导他，但程序员应该有足够的经验或训练来设计内部。

真的是关于外部，你需要非常清楚所需的输入和所需的输出，无论是图形用户界面还是程序界面。在他知道你想要什么之前，你需要知道自己想要什么！

Answer 13

您可以使用用户故事（在SCRUM方法上使用）来表达用户的需求。它们从用户的角度描述应用程序的功能或应用程序的一部分。程序员的责任不是将这些用户故事翻译成代码。

查看Advantages of the “As a user, I want” user story template。

希望它有所帮助， 布鲁诺菲格雷多 http://www.brunofigueiredo.com

Answer 14

这确实是一个需求规范和管理问题。无论你有什么，我都会给他们。尝试用简单的英语（或任何适当的语言）清楚地描述它。如果你可以使用流程图，也可以这样做。

你应该期望程序员可能会问几个问题然后开始思考，但你还希望他们回来给你提出更多问题，以澄清要求。如果他们在一周左右的时间内不这样做，你应该与他们核实，让他们有机会提问。

如果项目适合它，你可能会设置看早期的工作原型。

Answer 15

USB 2.0（或旧版的RS232）。

Answer 16

给程序员定义项目的最佳细节集是什么？

这取决于项目，您对所需内容的理解以及程序员对业务领域的理解。用户故事，用例和单元测试描述很棒，但程序员对业务领域的理解是所有这些的重要基础。

简单地说，我知道我想要做什么，但我对编程

一无所知

非常好，第一步是承认你需要帮助; - ）

所以将项目定义给程序员的最佳方法是什么，这样他/她就能给我我需要的东西。即项目摘要，设计简报，流程图？

以上都不是 - 因为您不是程序员，所以您将无法准确地编写这些技术描述。你也不应该！

正如其他人所说，你应该告诉程序员你，用户想要做什么。不如何这样做，但软件将使您能够做什么。 “什么”是要求，“如何”是设计。

但首先，程序员必须了解作为要求背后的业务领域。如果没有这种基础，他/她就会在概念真空中运作。

一旦程序员对您的业务有了线索，那么请谈谈您需要的应​​用程序。

慢慢进行，一起编写用户故事，绘制屏幕并将纸模型组合在一起，同意应该如何工作的细节（关于用户） ）在一起。向程序员解释，因为这是你的第一个项目，你真的想参与启动过程的每一步，但是一旦你理解并同意应用程序的完成方式 - 包括必须按顺序通过哪些测试被接受 - 然后你会留下他/她单独编码，同时仍然可以提问。

不要将缺乏经验的开发人员用于第一个项目，因为您将依靠他/她来教授您良好的实践。

编辑：如果您有多个应用程序需要构建，请选择您喜欢的开发人员，并认为您可以长期使用。在相互信任和尊重的基础上与他/她建立关系。有很多非常优秀的程序员没有人员技能;避免它们，因为从长远来看它们会让你疯狂。

Answer 17

指定您的要求的最佳方式是从用户的角度出发。如果您向程序员描述具体的use cases，那么它会更加清晰。了解用户使用我们的软件尝试完成的内容对我们很有帮助，因此我们不会构建任何自己的假设。

Answer 18

为他们提供必要的步骤，以便您从页面中获得所需的结果。如果您看到任何其他页面看起来与您想要的类似，那么请将它们作为示例提供给他们。但最重要的是要具体说明你想要的东西！如果你不知道自己想要什么，就不能指望它们。

Answer 19

没有一种特殊的方式可以用来与程序员进行通信。这是一个非常通用的问题，您需要添加更多关于您想要的内容，您正在寻找什么样的应用程序等等。

我个人在网站的UI级别上工作很多，并且更喜欢我们获得的每个请求的屏幕截图。在我的案例中，一张图片胜过千言万语。编写搜索引擎或抓取工具的人根本不需要截屏。我也更喜欢精心编写的技术规范，你想要什么，你什么时候想要它和一些例子。

另外，请务必查看您指定的内容。有时，您的需求可能与初始描述不同。

Answer 20

• 举个详细的例子。程序员 称他们为用例或用户故事。
• 明确说明您的要求。一世 需要获得员工姓名，地址， 和数据库中的电话号码 比我需要的要好得多 有关员工的信息。
• 包括您想要的所有内容 现在，你认为你可能会 希望将来。
• 的优先级。让我们知道是什么 要求，你想要什么，和 什么是不重要的。

Answer 21

<sarcasm>提供具体信息和详细信息，您将得到您所要求的内容，而不是您想要的内容.</sarcasm>

说真的，细节很好。

不要认为开发人员了解您的交易，甚至不想学习它。我发现很多很多开发人员并不真正想要了解会计或放射科学或者你所参与的任何其他交易。如果他们确实需要花时间学习，那只是在最粗略的层面。

对您的交易或工作流程至关重要的Mundane详细信息或决策对开发人员来说并不明显。像页面上的字段或Tab键顺序那样简单的东西可能会丢失在开发人员身上，因为他们从未输入过您的数据。或者两个数据相关的事实对您来说可能是显而易见的，但它们似乎与开发人员完全脱节。也许工作流程适合某种模式，除非发生特定事件或情况......

准备好教他们你的交易（即使他们不想），并确保他们明白你真正做的是什么。这是我对开发人员最有抵触的领域 - 他们倾向于认为他们理解他们实际上并非如此。这不是通过他们的任何恶意，只是简单的现实，许多工作很容易学习，但很难掌握。

Answer 22

从我的技术角度来看：

最明显的是，不要假设X必须如何设计/实现。

但更重要的是，根据我最近的经验，会发生的事情是产品所有者/客户有一些习惯或使用某些工具来完成某些任务。然后，他没有解释他的实践经验，而是抽象出他认为是一般概念的东西，这导致沟通失败，双方（产品所有者和技术人员）彼此视为无能的笨蛋。在你们都有一个共同的词汇之前，你们无法一起完成任何事情。一旦看起来不清楚就停止对话并尝试定义每个单词。

一些例子：

• 客户希望应用程序“就像MS Word”，当他需要的只是一些格式化他的文本的快捷方式。然后技术人员应将客​​户端放在MS Word文档前面，让他准确显示他需要的功能。
• 我个人最近的经历：客户一直在问“你使用什么CMS？” - 虽然真的没有开箱即用的所谓的CMS可以满足其需求，加上，或者A）他只是像鹦鹉一样重复“CMS”，因为他被告知如此B）他已经使用或听说过，一些称自己为“CMS”的软件。真的，技术人员不应该试图通过说谎来避免这种误解（这是最简单的方法，但适得其反会使事情变得更糟）。再一次，实际演示客户端头脑中的一些现有特征，而不能在其上面添加文字，这应该会导致一个解决方案，并且再次提供一个共同的词汇。

最后，不要试图预先考虑所有事情，这是太多的假设。迭代地工作。软件是“软”的，这意味着它可以改变。最好是在一段时间内做出微小的改变，而不是对早期的假设进行顽固。

至于项目管理，最近SCRUM方法帮助我解决了所有类型的通信故障。至少，由于其透明性，这种方法可以在浪费太多时间或金钱之前看到可能导致失败的原因。

Answer 23

通过他们的耳机。 ：）

Answer 24

步骤1.用简单的英语句子描述你的问题。它不必详细，但它应涵盖您问题的所有方面。

步骤2.提取上述问题陈述中的所有名词，并提供术语的精确定义。这个术语越简单，它所需的定义就越精确，因为人们的意思不同。

步骤3.在一张大纸上画出每个术语的盒子，并用相关的线条或箭头连接盒子。忽略（0 .. *）的事情，但图表应如下所示。请记住，如果没有明确的术语定义，图表并不重要。

步骤4.接下来，提出最终用户可以带到程序的预期输出的简单方案。例如：

1. 用户按下1按钮。
2. 系统应显示“1”。 （没有引号，但包括句号）。
3. 用户按下+按钮。
4. 用户按下2按钮。
5. 系统应显示“2.” （没有引号，但包括句号）。
6. 用户按=按钮。
7. 系统应显示1和2之和的周期，即“3”。

任务可以引用其他任务，并且应该指定系统根据用户的无效输入执行操作（例如向管理员发送电子邮件）。我们的想法是提出一个可测试的场景，您和程序员可以使用它来验证程序。这些迷你场景称为用例。

步骤5.定期与程序员会面（例如每两周一次），并指定必须处理哪个任务以及不应该处理哪个任务。指定不要做的事情很重要，因为如果没有这样的指示，程序员往往会做他们认为正确的事情，这就是所谓的牛仔编码。如果需要，请更新术语，图表或用例。

步骤6.当您与程序员见面时，要求您想要查看程序本身并使用它。检查程序是否符合您的约定。告诉他们你喜欢什么，不喜欢什么。

Answer 25

我认识的许多程序员都是非常快速的学习者，并且具有发现不一致，替代和简化的天生诀窍。

你可能最好教他关于你的域名：如果你自己对需要构建的内容有一个很好的直觉，他会找出相同的东西，然后你可以讨论细节

很可能，在了解您的域名时，他会建议更高级别的更简单或完全不同的解决方案，使您的第一个问题消失，或者您可以轻松使用的现有工具。

如果您正在尝试定义一个用于制作加热车把的项目，那么与优秀程序员交谈一小时将会让他建议手套。

我遇到过这种情况：客户愿意付我建立一些东西，经过20分钟的聊天后，我向他们指出了一个现有的开源工具，它解决了一般情况下的问题。他们只是没有足够的知识或心态来分析他们的问题。

所有这一切中最重要的一点是，这是一个对话框：您需要与开发人员分享您的知识，并共同努力寻求解决方案。在墙上投掷设计简介和规格是不够的，因为你没有利用他们的能力来解决问题。

Answer 26

列出您的要求。你需要做什么。不要只是告诉他你想要什么作为最终产品，而是给他一份短期和长期目标清单。

就像我说的...... 要求， 要求， 要求。