该研究所教授算法，数据结构，OOP。在一个好的情况下，他们可以谈论设计模式或多线程编程。但是我没有听说如何正确评估劳动力成本。

同时，每个程序员每天都需要这项技能。总会有更多的工作要做。评估有助于正确确定优先级，并完全放弃某些任务。更不用说诸如预算和计划之类的家庭问题了。相反，不正确的估计会带来很多问题：低估-冲突情况，预算处理和漏洞，夸大预算-取消项目或寻找其他执行者。

公平地讲，应当指出，低估在发展中更为普遍。怎么了有人认为程序员本质上过于乐观。我将为此添加更多的理由：成为一个好的程序员和成为一个好的评估师不是一回事。要成为一名优秀的程序员，一个愿望是不够的。需要知识和实践。为什么评估会有所不同？

在本文中，我将讨论我对任务评估的态度如何改变以及如何评估公司的项目。我将从不需要评估的方式开始。如果您已经知道“不”的方法，请直接转到文章的第二部分。

反评估模式

项目中的大多数评估都是在生命周期的开始进行的。直到我们了解估计是在确定需求之前就获得的，并且因此在研究任务本身之前就得到了，这并没有困扰我们。因此，通常不会按时进行评估。正确地将此过程称为不是评估，而是猜测或预测，因为需求中的每个位置都是猜谜游戏。这种不确定性会在多大程度上影响评估的最终结果及其质量？

琐事，但不愉快

假设您正在开发一个订单输入系统，但是尚未能够开发出输入电话号码的要求。在可能影响程序评估的不确定因素中，我们可以立即强调以下内容：

客户是否需要检查输入的电话号码的有效性？
如果客户需要电话号码验证系统，他会选择哪个版本-便宜还是昂贵？
如果您实现了便宜的电话号码查询功能，客户是否会在以后切换到昂贵的电话号码？
是否可以使用现成的系统来检查电话号码，或者由于某些设计限制，您需要自行开发？
验证系统将如何设计？
对电话号码验证系统进行编程需要多长时间？

这些只是经验丰富的项目经理的脑海中出现的几个问题...即使从这个示例中也可以看出，在识别，设计和实现相同功能方面的潜在差异可能会累积并增加数百次或更多次的实施时间。而且，如果将它们组合成一个大型项目的成千上万个功能，则在评估项目本身时会遇到极大的不确定性。

“膨胀”的另一个很好的例子似乎是基本要求，请阅读文章“ 两周如何？！ ”。

不确定度锥

软件开发以及许多其他项目由数千种解决方案组成。研究人员发现，项目估算在不确定性预测水平所固有的不同阶段。不确定性锥表明，随着项目的进行，估算变得更加准确。请注意，在初始概念阶段（经常进行估算并承担义务），错误可能是400％（百分之四百，Karl！）。最好在完成详细设计后作出承诺。

神话般的人月

仍然有高管相信，如果功能是严格固定的，则可以通过增加可以在更短的时间内完成更多工作的人员来随时减少时间。这种推理的错误在于评估和计划中使用的计量单位：工时。成本实际上是根据员工人数和所花费月份数的乘积来衡量的。但是结果没有实现。因此，使用工时作为工作量的度量单位是一种危险的误解。所有研究人员都同意，缩短名义工期会增加工作量。如果一组7人的名义期限为12个月，那么仅将人员增加到12人就不会将期限减少到7个月。

在大型团体中，协调和管理的成本增加，并且通信路径的数量增加。如果必须在任务的各个部分之间单独进行协调，则沟通成本将成倍增长，而团队的“力量”将呈线性增长。三名工人需要成对交流，是两人的三倍，四对六。

该项目小组正试图应对这些问题。// Ivan Aivazovsky，1850年

如果8个人可以在10个月内编写一个程序，那么80个人可以在一个月内编写同一个程序吗？在极端情况下，极端严格的截止日期的效率低下变得尤为明显，例如1600人需要一天编写一个程序。在Frederick Brooks的同名书中阅读有关此内容的更多信息。

评估模式

因此，有了这些问题，一切都变得清晰了。该怎么办？

分解

与其评估一个大型任务，不如将其分为许多小任务，然后对它们进行评估，并获得最终成绩作为初始成绩的总和。因此，我们立即用一块石头杀死多达四只鸟：

我们更好地了解工作范围。要分解任务，您需要阅读要求。莫名其妙的地方将立即出现。减少了误解需求的风险。
在对需求进行更详细的分析的过程中，系统化知识的思考过程会自动开始。这样可以减少忘记工作的某些部分的风险，例如重构，测试自动化或布局和部署的额外工作
分解结果可用于项目管理，前提是两个过程都使用了一个工具（此问题将在下文中详细讨论）。
如果我们测量分解过程中获得的每个问题的估计的平均误差，然后将该误差与总估计的误差进行比较，那么总误差将小于平均误差。换句话说，这样的评估更加准确（更接近实际的人工成本）。乍一看，这种说法是违反直觉的。如果我们在评估每个分解问题时出错，最终评估将如何更加准确？考虑一个例子。为了创建新表单，您需要：a）在后端上编写代码，b）组成布局并在前端上编写代码，c）测试并布局。在5个小时评估任务A，在3个小时评估任务B和C。总成绩为11小时。实际上，后端是在2个小时内完成的，表单花了4个小时，而测试和修复错误又花了5个小时。总工作量为11个小时。理想的评级。此外，评估任务A的错误为3个小时，任务B为1个小时，C为2个小时。平均错误为3小时。事实是，低估和高估估计值的误差相互抵消。后端节省的3个小时弥补了前端和测试阶段1个小时和2个小时的延迟。实际劳动是一个随机变量，取决于许多因素。如果您生病了，那么您将很难专心，而不是三个小时，可能要花六个小时。否则将会出现一些不可预料的错误，必须整天对其进行搜索和修复。或者相反，事实证明，代替编写自己的组件，您可以使用现有的组件，等等。正偏差和负偏差将相互抵消。因此，总误差将减小。

功能和任务

分解的核心是功能。功能是交付功能的一个单位，可以独立于其他功能投入生产。有时将此级别称为“用户故事”，但是我们得出的结论是，“用户故事”并不总是非常适合设置任务，因此我们决定使用更通用的表述。

一名成员负责一项功能。有人可以帮助他进行实施，但是一个人通过了测试。该任务也已退还给他进行修订。根据团队的组织，这可以是团队负责人，也可以直接是开发人员。

不幸的是，有时会有很大的功能。在如此大的容量下，单独工作将需要很长时间。长期以来，您将必须测试并实施验收流程。然后，我们将任务类型更改为Epic。史诗只是一个非常强大的功能。除了史诗之外，我们别无其他。即史诗可以是大的，巨大的或巨大的。在任何情况下，史诗都是部分（功能）发送给接受的。

为了更准确地进行评估，功能被分解为单独的子任务（任务）。例如，功能可能是开发新的CRUD接口。任务的结构如下所示：“显示带有数据的表”，“紧固过滤和搜索”，“开发新组件”，“向数据库添加新表”。任务的结构通常对企业而言根本没有意义，但对开发人员而言则极为重要。

分组评估，扑克筹划

程序员对工作量过于乐观。根据各种消息来源，低估率通常在20％至30％之间变化。但是，分组减少了错误。这是由于从不同的角度和评估气质得到更好的分析。
随着敏捷的日益普及，最常见的实践是“ 扑克筹划 ”的实践，但是，与团队评估相关的两个问题是：

社会压力
时间成本

社会压力

在几乎所有小组中，参与者的经验和个人效能都会有所不同。如果团队拥有强大的团队/技术（首席/首席程序员），其他成员可能会感到不舒服，并故意低估了等级：“好吧，Vasya如何做到，但我会更糟吗？我也可以做到！” 原因可能有所不同：竞争似乎比实际情况要好，或者只是顺从。结果是：小组评估失去了所有优势，变得个人化。蒂姆利德（Timlid）留下痕迹，其余的都简单地同意了他。

很长时间以来，我一直在向团队施加压力，以使评分更加符合我的期望。这总是导致质量下降和术语故障。结果，我改变了态度，现在我的评分通常是最高的。在讨论过程中，我指出了潜在的问题：“在这里重构不会受到损害，在这里我们的数据库结构正在发生变化，有必要进行回归测试。”

有几个主要建议：

大多数评级被低估了。无法在两个评分之间进行选择？拿一个更大的。
不确定评估-丢掉卡片“？” 或很高的评价。也许几乎永远都不会携带。
总是比较计划和事实。如果您知道自己不适合两次，请给您一个比您想像高出两倍的估计值。开始夸大了？在您的脑海中乘以一个半。经过几次迭代，您的成绩质量应该会大大提高。

时间成本

您知道“您想工作吗？”这句话。开会吧！” 不仅程序员会尝试预测未来，而不是编写代码。现在，整个团队都在做。此外，与单独制定决策相比，在团队中制定决策要花费更长的时间。因此，小组评估是一个极其昂贵的过程。值得从另一侧看这些费用。首先，在评估过程中，小组被迫讨论要求。这意味着您必须阅读它们。已经不错。其次，让我们将这些成本与由于项目被低估而产生的成本进行比较。

许多年前，即11月的一天，我将工作换成了一家大公司。我立即清楚地知道工作正在进行中。该公司的一半工作在年底之前发布了该产品。但是大约一周后，在我看来，到年底他们将没有时间。每隔一天，这家企业成功的机会就变得越来越虚幻……该项目实际上在第二年（即第二年）就已交付。我后来才了解到这一点，因为在夏季，问题开始于向员工支付工资，而我与大约一半的员工一起辞职。您可以说“当然，经理是傻瓜，您必须谨慎行事。” 他们为自己投保。六个月的工资支付没有问题。要保持半年的营运资金存量并非易事。我认为，如果评估更加准确，那么高层管理人员还会做出其他管理决策。

如果我们将评估中的投资视为通过合理的管理决策的投资，那么它们似乎不再那么昂贵。团体人数是另一回事。当然，没有必要强迫整个团队评估整个工作量。将任务划分为模块，服务，微服务并为团队提供自治权是更加合理的。在更高层次上，使用每个团队获得的估算来制定项目计划。这使我们顺利地进入下一段的主题。

依赖关系布局，甘特图

如果程序员通常进行评估，那么制定项目计划就是很多中层管理人员。记住，我写道，如果将一种工具用于分解和项目管理，则可以为这些人提供帮助。评估和日历时间不是一回事。例如，要显示一个简单的数据表，您需要：

数据库表
后端代码
前端代码

从技术角度来看，按此顺序执行任务是最容易的。但是，实际上有不同的专业领域。可能会安排前端专家免费。通过创建模拟或硬编码数据代替服务器请求，开始开发UI更为合理，而不是闲置。然后，当API准备就绪时，仅保留理论上用对真实方法的调用来替换代码。实际上，最大并行度可以通过以下方式实现：

首先，我们急忙就API规范达成共识
然后根据手边的人在背面或正面对数据进行硬编码。
同时，我们进行数据库，后端和前端。数据库和后端部分相互阻塞，但是通常这些能力是一个人结合在一起的，工作实际上是按顺序进行的：首先是数据库，然后是后端
我们收集一切并进行测试
我们修复错误并再次测试

重要的是尽快执行步骤1、4和5，以减少锁的数量。除了技术限制和对具备必要能力的专家的限制外，还有业务优先事项！这意味着三周后已安排了一个重要客户的演示，他想吐出您的项目计划的前一半。他希望看到最终结果，该结果将在两个月后发布。好了，那么您必须为此演示准备一个单独的计划。我们添加了计划，以锤炼必要的数据库数据，插入新链接以转换到UI，等等。最后还希望有必要扔掉20％的代码，而不是全部演示。

对这样的计划进行艺术性的切割并非易事。建立依赖关系大大简化了过程。在进入报告模块之前，您需要制作一个数据输入模块。这合乎逻辑吗？添加依赖项。对所有相关任务重复上述步骤。相信我，许多依赖关系会让您感到惊讶。

在使业务流程自动化的任务中，通常会通过几个大型锁定节点来获取相关任务的多个“长蛇”。通常，初始计划在资源利用方面和/或日历方面的时间过长时效果不佳。 — . , , . , «», . ( ) . « -»? , 30% . . , .

— — . / . , . . , , , .

,

. , ( ), , , , . , , , , , , . , .

, , , , . " ". , , . - . , , .

, , «» , , .

,

: , — — . . , , - .

? . , , , - , . . .

aka time tracking

- . , , . - . , . . , , . , . YouTrack . , .

结论

—
,
, , ,
— , ,

?

" " :

关于软件产品开发的评估和管理