如何向非技术人员解释为什么任务将花费比他们想象的更长的时间？[关闭]

几乎每个开发人员都必须回答业务方面的问题，例如：
为什么要花两天的时间来添加此简单的联系表？

当开发人员估计此任务时，他们可以将其分为以下步骤：

• 对数据库进行一些更改
• 优化数据库更改以提高速度
• 添加前端HTML
• 编写服务器端代码
• 添加验证
• 添加客户端JavaScript
• 使用单元测试
• 确保SEO设置正常
• 实施电子邮件确认
• 重构和优化代码以提高速度
• ...

这些对于非技术人员来说可能很难解释，他们基本上将整个任务看作只是组合一些HTML并创建一个表来存储数据。对他们来说，最长可能需要2个小时。

那么，有没有更好的方法可以解释为什么对非开发人员来说估算值很高？

您刚刚在问题中做到了。

将任务分为各个步骤，并为每个步骤进行估算。这将表明您已经考虑了所有选项，并（希望）涵盖了所有可能发生的情况。

如果时间尺度太大，则可以使用具体数据讨论在这种情况下不需要哪些部分（例如，电子邮件确认），而不仅仅是尝试将夸脱装满品脱锅。

经常进行此操作，您将希望教会他们，一般而言，开发所带来的不仅仅是乍一看。

列出任务几乎是完美的，但是请记住，对于工程师来说完全有意义的任务对非技术人员来说几乎没有意义。例如，在上面的列表中，我知道“优化数据库更改以提高速度”可能是一项或多项耗时的任务，其中包括对代码进行概要分析，运行它以寻找慢点，与专家进行审查或将其扔给其他人。针对产品的一组预定义测试。然后，您可能会花费数小时甚至数天不停地在桌子上猛烈地晃动，而您试图找到一种方法来修复太慢的区域。

但是，如果没有“ optimize”一词，您可能会失去对“ DB”一词的项目管理。

我通常用BIG步骤向项目管理人员表达这些内容，并用词语描述业务方面的风险。拿您的清单，如果我正在与我的项目管理人员交谈，我会把它简化成这样：

1. 首先，这件事有两个部分-用户看到的网页和承担繁重任务的服务器。这两个部分都需要在那里才能起作用。
2. 第一部分将是制作对用户有意义的网页（添加前端HTML，添加客户端javascript）。这里的关键是网页必须看起来像是该产品的一部分，它必须在我们支持的所有浏览器中运行，并且必须光滑。用户所见即所得，因此，如果外观不好，则用户会认为我们的产品不好。开发此程序然后进行测试将需要X天。
3. 接下来，需要在网页下方进行工作。在这种情况下，这意味着在此处插入功能说明（映射至-对数据库进行一些更改，编写服务器端代码，实施电子邮件确认，添加验证，使用单元测试）。我不能只是把这些放在一起。如果开发并测试了代码，则可能会导致损坏所有用户的数据的风​​险。这意味着简单的新事物可能损害产品的整体声誉-即使对于不使用此特定功能的用户而言。我们的开发实践涵盖了这一点-我们进行了大量测试以确保不会发生-但这意味着我必须计划及时进行测试。这将使我Y天。
4. 速度在我们的产品中至关重要。如果事情发生不快，用户会认为该产品不好。因此，在我编写完所有这些内容之后，我需要仔细研究并确保其性能符合标准。这在网络上是一件大事-如果人们看到网站变慢，他们将迅速转向另一种产品来满足相同的需求，因为很难看到缓慢与崩溃之间的区别。这类工作通常需要Z天的时间（优化DB更改以提高速度，重构和优化代码以提高速度）

我会避免少于半天的任何估计。他们将不得不在某种程度上相信您知道自己在说什么。如果他们真的认为只有2个小时，请邀请他们与您一起坐2个小时，同时让他们逐步体验SW开发人员生活中2个小时的样子-然后为他们编写101类编码大约需要2个小时，以确切显示开始解决问题所需要考虑的所有内容。

最重要的是以下几件事：

• 如果您购买最多的是关于客户认知度和产品使用情况的信息，那么您将要使用他们的语言-$$的语言-意思是，如果代码以次粗暴的方式被黑，最终您将失去业务-如果没有在此功能上，然后在随后的一些功能上，如果不良的开发实践导致无法扩展代码。
• 列出一系列事件。下一个非技术性的问题是：“如果我们有比您更多的开发人员，这会更快吗？如果是这样，如果要花40个小时才能做到这一点，今天下午有40个人可以实现吗？” 答案当然是“不！您不在头脑中吗？”。但这不是最好的。最好的是这里有一个逻辑上的步骤序列。在事物A到位之前，事物B无法完成（如果您没有编写任何代码，那么您就无法真正优化或测试它……）。不过，事情A和A'可以一起完成，因此，如果他们可以在那儿省掉那个聪明的家伙，那么您可以将时间从一周缩短到4天，而且如果他们可以保证提供出色的测试支持，那么您可能可以3天。那里'
• 专注于风险，并准备在此时告知某些风险是值得的。这就是商务人士的最高薪水-找出值得承担的风险。例如，如果由于您的公司有足够的现金在短期内暂存大量荒谬的服务器而导致上市速度过快而导致性能不佳，那么您可能会被告知在步骤4中跳过所有这些工作（代码/数据库优化） ）。这是他们的权利-解释该决定固有的风险只是您的工作。
• 但是，如果您不信任这些人，请以书面形式获得确认-不必是对抗性的，只需快速发送一封电子邮件，说“这是我认为我们在讨论的内容，这是我没有做的事情，这是风险。我现在要这样做，所以，如果您不同意，请告诉我...如果我没有收到消息，则我认为这是正确的做法。” 鉴于产品管理可以成为短期内存丢失的中心，这对每个人都非常有帮助。

俗话说：“你不能在一个五磅重的袋子里放十磅的废话。” 您的工作是证明任务是10磅，而他们要求在5磅的时间内完成。

您唯一缺少的是时间估计。对每个任务进行时间估算，并显示所有这些内容如何加在一起提供您的估算。不允许任何估计大于4小时。如果您有说“一天”或“ 10小时”的任务，则将其分解为较小的子任务。

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

现在，您已经有了一份详细的费用清单。总共要花费27个小时的时间。

现在，您可以向客户展示此内容，然后说：“这些都是必须做的事情，每件事都要花钱。” 请使用“成本”一词，因为时间就是成本，并且管理层理解成本。说明您可以在最后放弃两个优化任务，但它们会对您产生负面影响，它们仅占总估算的15％。

还要确保您切实地说明自己的小时/天。例如，如果您被要求提供技术支持，维护数据库或进行任何其他工作，请将其计入您的估算中。不要说“嗯，我每天可以做7.5个小时的良好编码”，因为您可能做不到。大概是5或6。

然后，最重要的是，跟踪您的进度。假设您每天可以进行5个小时的编码。然后，您应该能够在星期一完成前两个任务（在我的示例中），完成第三个任务，在星期二开始第四个任务，依此类推。制作一份清单以显示此内容，以便您可以在星期三显示它们时向他们显示，并说：“到周五结束时您还打算做什么？”

几年前我在OSCON上发表的“ 预防危机：有效的项目估算和跟踪”演讲，请参阅我的幻灯片。请看幻灯片21“计划周”。还有一个示例速度图表。

问他们：

你会怎么做？您将更改哪些模块？多少行代码？安全隐患是什么？对数据库架构有任何更改？如果您对数据库进行任何更改，将影响多少个文件？添加最后一个表格花了多长时间？添加表单的平均值（算术平均值）是多少？最长的是什么？我估计将比最长的时间少一分钟。如果您不知道添加最后N个表格所花费的时间，那么只能保证此估算值精确到一个数量级。

我可以告诉您向他们解释，他们的软件就像一台100吨的机器，具有10,000个不同的零件，其中许多零件以复杂的方式连接。将1英寸的零件安装到这台机器上需要一些工程，以便不会损坏机器，但是更好的答案是：

如果您拥有更好的代码体系结构，它会使这样的任务变得容易吗？答案是，大多数软件团队都不是优秀的架构师（因为他们只是没有积累大量的通用，架构模板，或者他们不是问题领域的主人就足以预见每个问题），而且他们也不总是优秀的工程师，因此他们对做出估算或做出承诺没有信心。

就像20世纪积累了好的建筑和建造大型建筑物的工程一样，用于软件工程的工具还没有成为主流。它们正在被开发：它需要一种新的思维方式。请参阅Wiki.hackerspaces.org/Hacking_with_the_Tao上的Zen Code。