（
c ）
自从技术行业出现以来，它一直在寻找“白鲸”-开发人员的劳动指标。 计数KPI程序员的渴望也许源于传统业务中的一句话：“如果无法衡量，就无法计划。”
在程序员尝试解决数百种不同的KPI之后，出现了许多不同的分析操作数据的方法-从跟踪显示器的方向到Scrum和看板。 在许多行业中，对劳动质量的测量效果非常好，因此将这种经验转移到软件开发中似乎是合乎逻辑的。 结果令人沮丧。
衡量和管理开发人员的生产力并没有导致单一的国际质量标准。 高科技IT公司正在制定自己的指标……其中有些几乎无法与其他活动领域中的传统KPI进行比较。
在本文中，我们将讨论当前最有趣的指标以及IT中的“指标”。
已经很难找到（至少在开放源代码中）有关使用工作小时数，源代码（SLOC）中的行数，功能点或每个开发人员创建的错误数作为度量标准的信息。
在公开讨论中，有可能达成共识，即工作更多
并不意味着工作更好，使用200行代码的解决方案比使用1000行的解决方案更快或更高效，并且1979年创建的功能点度量标准毫无希望地已过时。
但是，测量和计算一切的愿望发生了什么？ 显然，它并没有消失。
奈飞
（
c ）
Netflix致力于克服将用户与内容区分开的障碍。 每当有什么事情阻止您观看自己喜欢的电视剧的下一集时，开发人员都会解决问题并评估解决问题所花费的时间。
流媒体平台实际测试新想法，并测量用户与产品交互中的统计上显着差异。 而且，检验假设阶段的错误是可以接受的-“ Netflix唯一不可接受的真正错误是无法创新。”
Netflix的产品开发始于如下假设：
算法/功能/设计（×）增加了订户与服务的交互，并最终增加了其保留。
假设可能是增加搜索结果的相关性，为用户界面使用新设计或采用新功能-例如，向参与者展示其社交网络中的朋友正在看Netflix的内容。 直觉以及如何更好地为订户提供服务的想法成为开发方法的基础。
第二个开发步骤是编写一个测试，以测试假设的影响。 有时，这意味着您可以立即创建一个反映概念实质的原型，这将使您能够快速检验假设并努力构建更好的解决方案。
第三步是测试本身，成千上万的观众可以参加。 在给定的时间段内将原型部署给实验参与者。 他可能有两个测试队列，或20个队列，每个队列使用不同的方法或混合使用不同的新元素。 随时可以启动数十种不同的消费者测试。
甚至假设的失败也被认为是可以达到的结果。 因此，以下假设变得更好的可能性只会增加。 开发团队可以在很长一段时间内将想法应用到产品中，具有很大的自由度。
伊本
（
c ）
软件开发最古老，最“明显”的指标是计算单个开发人员或团队生产的生产线的数量，以及在其上花费的时间。 该度量标准最初是由IBM使用的。 史蒂夫·鲍尔默（Steve Ballmer）在纪录片
《凯旋的书呆子：意外帝国的崛起》中指出，在1980年代，IBM似乎已将宗教纳入该指标。
2011年，IBM
引入了一种工具，用于自动分析源代码的性能，安全性和技术复杂性。 代码评分最高的开发人员从系统中获得最高分数。 绩效低下的信号表明要注意员工培训（IBM声称最终得分不低并不作为惩罚）。
然而，后来的
出版物给人以范式转变的印象-构造假设的方法已经在开发的核心提到了。 虚拟的发展离不开时间和资源的浪费。
该指标的主要内容是客户对产品的反馈。 我们需要专注于对客户最重要的事情，放弃对用户无益甚至干扰用户的功能。 上图中描述了此策略。
空格键
（
c ）
关于SpaceX中开发人员的工作的信息很少，这与该非上市公司的项目的总体保密性有关。 但是根据
间接信息，您可以了解整个图片的大致轮廓。 这张图片说明了测试的重要性。
在火箭科学中，测试是设计的基础。 在用于火箭的编程软件中，使用
了相同的原理 。 例如，如果火箭安全着陆，则负责开发的所有团队都将完成KPI。 没有初步的测试，就不可能成功完成这样的项目。
考虑到为恶劣的太空环境准备设备的团队所面临的问题，不难理解他们负有什么责任。
SpaceX正在
尝试使不同项目之间的代码
并行化 -通过这种开发范例，一个项目（相对而言，火箭）的错误校正会自动扩展到其他项目。
该公司选择C ++作为主要的编程语言。 首先，由于该语言仍然相对流行，因此您可以雇用许多知名的开发人员。 同时，通常会选择习惯于编写代码并在内存和计算能力有限的环境中工作的游戏开发人员。
其次，它们受益于大型C ++生态系统。 当您可以使用熟悉的工具（例如gcc和gdb）时，无需创建特殊的软件。
最后，在开发过程中，非常重视测试指标。 建议开发人员和工程师检查安全性和容错能力，您可以想到的所有内容。
测试期间收集的数据与测试期间工作的源代码一起存储。 如果在火箭测试期间发生任何故障，SpaceX将能够重新创建确切的发射环境，重现问题并加以解决。
持续集成用于自动测试所有代码。 他们甚至拥有带有所有发动机组件的测试台，以完全模拟启动并检测潜在问题。
亚马孙
在与AWS开发人员工具总监进行的40分钟的采访中，亚马逊提出了最有趣的策略之一。
组建开发团队的关键思想是有丝分裂缩放。 团队分为较小的小组，充分保留了“母亲”团队的连续性和职能。
AWS开发人员工具首席执行官Jeff Bezos
认为 ，理想的团队应包括不超过两个披萨饼的人数。
在小型团队中，沟通更加有效，他们保持分散，独立，发展更快并引入创新。
亚马逊最初具有整体和软件架构（Perl / Mason / C ++）。 然后将体系结构分解为服务，将组织结构分解为披萨团队。 因此，云服务Amazon Elastic Compute Cloud（Amazon EC2）由仅由两个“比萨饼团队”组成的小组组成。
Amazon致力于完全自动化所有流程（构建，部署，提交传输等）。 在每个部署中，使用了几种不同类型的测试：集成，浏览器，Web和负载。 因此，一切都受到控制和测量。
在整个产品发布过程中都会对安全性进行监控，这就是为什么亚马逊在任何亚马逊文化中“像安全工程师一样思考”是完全正常的。 在启动新项目时，开发人员主要负责架构和威胁模型。
通过结合本地和全球信任策略，将验证内置到所有管道中。 领导者可以为其团队独立设置审核策略（例如，在部署之前，每次新提交都应由单元测试覆盖70％）。
同时，有适用于每个部署的通用亚马逊规则（例如，禁止在每个区域进行一次部署）。
负责项目架构的是团队中的开发人员，而不是架构师。 只有这样，建筑师或总工程师才会考虑它。 在安全性和测试方面情况相同：团队管理整个过程。 尽管这种方法有一个缺点，那就是需要长期的培训。
每年，团队都会在六个页面上准备一个运营计划（在亚马逊的各个级别上都会介绍这样的“业务计划”）。 该计划表明明年将使用固定资源来完成哪些工作，以及使用额外资源可以完成哪些工作。 经理从他们管理的所有团队中收集六页文档，创建自己的六页文档并将其提交给管理层-依此类推，直到Jeff Bezos。 相反，资源分配给团队。
创业公司在那里有什么
多亏
了 Stackify（用于监视和诊断Web应用程序的云平台）
进行的调查，才有可能找出一些知名的初创公司和“中间人”公司对指标的态度。
CircleCI在包括俄罗斯在内的一种流行的持续集成服务中具有针对Web和移动应用程序的灵活设置。 CircleCI的CTO Rob Zuber认为，衡量软件开发的生产率和有效性的最佳指标是代码从提交到部署过渡所花费的时间-提交到部署时间（CDT）。
衡量CDT的目标是“追踪”部署的障碍。 理想情况下，如果您使用自动化和/或高质量的测试，则可以在几分钟（甚至几秒钟）内进行微服务部署。 如果您主要使用手动质量控制过程，那么这可能意味着部署将花费更长的时间。
CircleCI的CDT分析显示了在哪里可以找到改进的机会。 改进可以是更具技术性的（例如，使测试更有效），面向过程或两者结合。 您的提交越小，它们启动的速度就越快，如果出现问题，则可以更快地解决这种情况。
Adeva是一家招聘公司，正在为初创企业组建现成的开发团队。 为了向客户提供更好的服务，她几年来一直在研究程序员的性能指标。 结论很简单：软件开发的有效性和生产率尚无正式和客观的衡量标准。
Adeva并未使用KPI，而是与开发人员组织了简短的会议，管理层在会议上认真听取了有关成就和失败的故事。 为了确定部门整体的有效性，向开发人员询问有关团队其他成员的有用性和意识的问题。 在这些会议上，每个人都可以发表可以帮助自己和其他团队成员的想法。
除了人际交流之外，Adeva还着眼于开发人员代码与代码库的集成方式，检查其性能，安全性，并确定从长远来看该代码是否具有较低的服务成本。
英国Web和移动应用程序开发商Scorchsoft估计项目的交付时间。 由于大多数Scorchsoft客户希望以固定的价格收到产品，因此公司应立即确定明确，明确的规格。 使用Toggl（时间跟踪器）和Jira工具根据开发时间来衡量性能。
如果客户满意并且团队在截止日期之前完成，则认为项目成功。
结论
有时，通过评估指标，您仍然可以得出一个共同的标准-这是对用户舒适度的关注。 与其试图直接衡量程序员的生产力，不如将重点放在衡量阻碍向客户交付价值的过程中。
当最终客户是成功的主要指标时，使用来自营销的指标会更容易：转化率，用户行为或评分评论。 在这个领域，成功很大程度上取决于管理层，这可能会做出错误的决定。 例如，与从“标准”中脱颖而出的开发人员相比，开发对客户而言不必要的功能对业务的负面影响要大得多。