产品开发中的辛勤劳动

苦差事：“苦差事是一种与运行生产服务相关的工作，这种工作往往是手工的、重复的、自动化的、战术性的，没有持久的价值，而且随着服务的增长呈线性扩展。”谷歌SRE图书。

产品开发：决定方向、确定范围、建立和推出产品的过程。以此为目的的后期软件产品。它包括技术团队成员(开发人员、现场可靠性工程师等)，以及与开发人员密切交互的产品管理、市场营销和运营部门的较少技术团队成员。

如果您没有关注站点可靠性工程的发展趋势(一点也没有，这些天要跟踪的东西太多了！)-您可以把它看作是DevOps的进一步发展，提高生产系统的自动化、可靠性和性能。SRE的目标之一是通过自动化减少劳动。如果您想深入了解这个主题，在结尾处有一些SRE链接。如果你在软件界，不知何故读到了这一页，了解一下这些心态应该会对你的职业生涯有所裨益。

有大量的“手工的、重复的、自动化的、战术性的、缺乏持久价值的、线性扩展的”类型的工作使产品开发团队陷入困境。Asana在他们的S-1文件中分享说，“今天，知识型员工60%的时间都花在与工作相关的工作上。”大多数个人贡献者在这种类型的工作中艰难地工作，认为这只是工作的必备部分。我们与产品经理交谈过，他们认为没有其他办法--“你只需要付出努力”，这是我们听过无数次的话。

领导力和管理层经常认为辛苦的工作是不可避免的--必须有人去做。有些人甚至保护自己不去碰它-也许他们以前必须这样做，现在他们有权委托这项工作。然而，归根结底，他们需要信息来做出战略决策。这个过程对组织来说弹性不强，伸缩性也不好。这是一个永无止境的循环，伴随着敏捷或频繁接触基地的快速反馈周期，以实现更长期的工作。

那么，团队具体在努力些什么呢？我们听到的主要主题是-状态更新、差距分析、一次性使用演示文稿，外加奖金想法。

表现在电子邮件、聊天信息、5分钟的会议上，实际上持续了30分钟或更长时间。将其他团队成员从任务中拉出来，以得到答案。通常对整个组织不可见，但给许多团队成员带来负担。

这里的答案周期通常是最短的，也是最让人分心的。您可能会收到客户成功或销售团队试图让客户满意的状态请求。或者数据科学团队正在寻找何时可以通过数据集成来解锁。或者，最后，一位创始人或高管试图完成一份大合同。团队成员在这里很难保持主动，而且他们经常措手不及。

UPS/FedEx样式跟踪编号和链接，可主动与利益相关者共享，可自动从代码存储库、其他工具和部署环境元数据中提取数据。

通常显示在充满项目管理工具链接、红色、黄色、绿色单元格和非结构化数据的电子表格中。

与状态更新相比，这些请求通常会提供更多的提示，但通常更加乏味、费力，而且充满了过时的信息和错误。也可以从组织的不同部分临时发生-“Web应用程序支持X吗？”

我们认为团队应该根据结构化的特性定义来标记他们的代码库。这样做将允许团队根据其投资组合中的功能进行查询。

组织用于状态更新和差距分析的数据将有助于自动生成演示文稿。

我们正在努力建设一个不单纯更新工作状态的世界。您的工作应该会为您更新状态。想一想这一点-如果您只做繁重的工作，而其他所有工作都是自动化的，情况会怎样？文档、状态更新、投资组合差距分析、组织一切。

这些手工练习的输出不可能在一段时间内相互比较或测量。

在2020年，团队不应该在快速过时或一次性的状态更新、差距分析和构建演示文稿上劳累劳累。数据应该来自现有的真实来源(代码)，这些来源可以与其他元数据合并，为组织提供常青树情报。我们可以把这个自动化。

特别是在过去的10年里，产品开发文化变得更加敏捷，在这样做的过程中，更少了有形、可量化或可衡量的东西。是的，我们可以前所未有地跟踪转换率、使用队列和统计数据，但功能是否存在没有客观的衡量标准。我们正在努力解决这个问题，这样你就可以既吃蛋糕又吃蛋糕了。我们希望您花更多的时间接触客户，深入研究真正的问题，而不是忙碌的工作。

我们正在触及我们认为可能的事情的皮毛，加入我们的冒险吧。我们很乐意听取您对此的看法，请在Twitter帖子中加入讨论