软件管理的 《目标》是什么?996 能提高有效产出吗?

文章探讨了企业管理中的目标设定,引用以色列管理学家高德拉特的观点,提出利润、投资收益率和现金流作为关键指标。针对软件企业,提出了有效产出、存货和运营费用的新视角,并讨论了如何在软件开发中衡量这些指标。强调了产品组件的实际使用、快速迭代和降低运营成本的重要性,同时也指出避免无效的996工作制,应找出项目瓶颈以提高效率。最后,提倡目标与金钱挂钩,避免无谓的忙碌,关注真正能带来收益的活动。

在这里插入图片描述

以色列管理学家高德拉特 (Goldratt) 在他的企业管理小说《目标》以工厂管理为例提出了三个基本目标:

  • 利润
  • 投资收益率 (ROI)
  • 现金流

企业如果没有利润就意味着不赚钱,但是投资了100万才得到1万元的利润,收益率还跑不过国债,这也不能说赚钱。投资100万,利润20万但是18万是应收账款,只有2万现金,这种企业肯定不赚钱,说它濒临倒闭可能更符合实际。

这三个指标虽然很明确,但是在管理企业的过程中确很难随时随地地得到这些指标,为了更直观地体现上面的指标,书中提出了下面三个目标:

  • 有效产出 (Throughput)
  • 存货 (Inventory)
  • 运营费用 (Operating Expense)

有效产出只的是生产的产品实际上能卖出去的部分。对于工厂而言,工厂可能生产了一大堆产品但是不是所有产品都能卖出去,只有可以卖给市场的产品才是有效产出。存货是指将来才能被卖出去的产品。运营费用就是生产产品所产生的费用,比如看仓库的人的工资,研发的费用等等。

软件管理如何确定目标

书中的例子都是工厂的,那么对软件企业有没有什么启发意义呢?对于前三个指标,我认为最直接的就是现金流应收账款,很多软件企业都是按照 334 来签软件开发项目合同的。也就是首期3成,中期3成,开发完成以后再付最后的4成。这里有保证能收到的其实也就是6成开发费用,后面的4成好的话可能项目完成后一年半载才能收到,不好的话可能永远收不回来。这样企业的现金流会受到严重影响。所以在做软件项目的时候,首先要处理好应收账款问题。

更成功的软件企业应该是以产品为核心的软件企业,那么如何衡量软件企业的有效产出、存货和运营费用呢?软件都是有一个个模块或者说组件构成的,如果软件发布以后的某个组件没有人使用或者用的人很少,这个组件就不能算作有效产出。而我们写好了还没有发布的组件,都应该算作存货。所有参与软件项目开发的费用,都应该算作运营费用,这些费用包括人工,办公室租赁,服务器硬件,云服务器租赁,软件等。

那么如何提高有效产出,同时降低存货和运营费用呢?我觉得首先得让我们的软件组件是可测量的,这是基础。现代软件已经不像工业产品那样,开发完成以后在市场中出售出去就可以了。它更像一种服务,客户花钱买服务,软件企业不断改进服务,因此服务的内容也就是软件组件的使用情况才能反映客户的真实需求,才是有效产出。互联网企业需要随时监控软件组件的使用情况,增加有效产出。非互联网企业也应该了解客户的使用情况,即时评估自己的软件产品的有效产出。

软件企业的存货就是还没有发布到用户手中的产品版本,那么快速迭代降低开发周期就显得异常重要,只有这样才能降低软件产品的库存。另一方面,提高已有软件组件的利用率,也是降低库存的好方法。这需要我们提高软件产品的架构和设计能力。

现代软件开发人工是主要的费用项目。低代码软件开发是降低人工的重要途径。另一方面云服务的崛起使我们可以尽量减少硬件、软件投入,即买即用。云服务也会占用企业的现金流,因此我们应该把云服务的费用落实到每个项目组成员的头上,这样才可以尽量减少不必要的浪费。

最后说一下 996,《目标》这本书中也提到工厂为了完成逾期的订单经常赶工。可是就算是这样,订单逾期现象依然严重,直到重新衡量工厂的目标,找出瓶颈了以后才改善了逾期现象。某些软件企业天天加班,是因为项目会逾期吗?如果是这样就必须找出项目的瓶颈所在,因为依存现象和统计波动 (Statistic Fluctuation) 现象说明了那个最慢的单位决定了整个系统的输出效率。

拿书中的例子来说,机器人和人配合生产零件,机器人每小时生产25个,人平均每小时生产25个,机器人依赖于人生产的零件。要在 4 个小时内生产100个零件,能完成的概率是多少呢?答案是近乎于0,因为人的效率是波动的,只要4个小时里的前3个小时生产的零件小于75个,哪怕是最后一个小时生产30个,机器人和人的团队也不能在4个小时内完成任务。因为最后一个小时机器人的生产效率还是25个每小时。

统计波动的效果

如果因为一个工作任务进展缓慢,而让所有人都陷入无谓的等待或者996,团队的效率是提高不了的。我们需要做的是找出项目的瓶颈,解决瓶颈问题,这样才能让所有人共同快步前行。我们在工作中尝试过找到瓶颈吗?我们有寻找瓶颈的机制吗?我们奖励了帮助我们提高瓶颈生产效率的人吗?原书中的工厂即使天天加班也完成不了任务,在树立了正确的目标以后,有效产值从200万美元提升到300万美元,原因是有了正确的目标以后,管理人员才会正确地思考问题并尝试找到答案,团队重新获得了凝聚力。值得强调的是所有的目标都应该和金钱挂钩,不和金钱挂钩的目标那就是办公室政治了。

另外一个值得思考的问题是,让所有人忙起来这个系统的赚钱的效率就会提高吗?答案是否定的,因为当所有人都忙起来了以后,系统中的瓶颈还会是瓶颈,堆积在瓶颈面前的库存会增加,即使没有了瓶颈,市场能消化多出来的产能吗?所以我们的目标不是让,所有都特别忙,而是赚钱!

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
【直流微电网】径向直流微电网的状态空间建模与线性化:一种耦合DC-DC变换器状态空间平均模型的方法 (Matlab代码实现)内容概要:本文介绍了径向直流微电网的状态空间建模与线性化方法,重点提出了一种基于耦合DC-DC变换器的状态空间平均模型的建模策略。该方法通过数学建模手段对直流微电网系统进行精确的状态空间描述,并对其进行线性化处理,以便于系统稳定性分析与控制器设计。文中结合Matlab代码实现,展示了建模与仿真过程,有助于研究人员理解和复现相关技术,推动直流微电网系统的动态性能研究与工程应用。; 适合人群:具备电力电子、电力系统或自动化等相关背景,熟悉Matlab/Simulink仿真工具,从事新能源、微电网或智能电网研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握直流微电网的动态建模方法;②学习DC-DC变换器在耦合条件下的状态空间平均建模技巧;③实现系统的线性化分析并支持后续控制器设计(如电压稳定控制、功率分配等);④为科研论文撰写、项目仿真验证提供技术支持与代码参考。; 阅读建议:建议读者结合Matlab代码逐步实践建模流程,重点关注状态变量选取、平均化处理和线性化推导过程,同时可扩展应用于更复杂的直流微电网拓扑结构中,提升系统分析与设计能力。
内容概要:本文介绍了基于物PINN驱动的三维声波波动方程求解(Matlab代码实现)理信息神经网络(PINN)求解三维声波波动方程的Matlab代码实现方法,展示了如何利用PINN技术在无需大量标注数据的情况下,结合物理定律约束进行偏微分方程的数值求解。该方法将神经网络与物理方程深度融合,适用于复杂波动问题的建模与仿真,并提供了完整的Matlab实现方案,便于科研人员理解和复现。此外,文档还列举了多个相关科研方向和技术服务内容,涵盖智能优化算法、机器学习、信号处理、电力系统等多个领域,突出其在科研仿真中的广泛应用价值。; 适合人群:具备一定数学建模基础和Matlab编程能力的研究生、科研人员及工程技术人员,尤其适合从事计算物理、声学仿真、偏微分方程数值解等相关领域的研究人员; 使用场景及目标:①学习并掌握PINN在求解三维声波波动方程中的应用原理与实现方式;②拓展至其他物理系统的建模与仿真,如电磁场、热传导、流体力学等问题;③为科研项目提供可复用的代码框架和技术支持参考; 阅读建议:建议读者结合文中提供的网盘资源下载完整代码,按照目录顺序逐步学习,重点关注PINN网络结构设计、损失函数构建及物理边界条件的嵌入方法,同时可借鉴其他案例提升综合仿真能力。
### 3.2 软件测试过程中的常见产出软件测试过程中会产生多种文档和成果,这些产出物不仅用于指导测试活动,还用于记录测试过程、分析缺陷、评估质量以及总结经验。以下是软件测试过程中常见的产出物: #### 测试方案 测试方案是测试工作的总体设计文档,涵盖测试目标、测试范围、测试策略、测试环境、测试工具、测试人员分工等内容。它为整个测试过程提供明确的指导和依据[^5]。 #### 测试用例 测试用例是测试执行的基础,用于描述测试输入、执行步骤和预期结果。测试用例的设计应覆盖功能需求、边界条件和异常情况,确保测试的全面性和有效性。 #### 自动化测试脚本 在自动化测试中,测试脚本是执行测试用例的具体实现。它通常基于测试框架(如`pytest`)编写,可以提高测试效率和覆盖率。例如: ```python import requests def test_get_request(): response = requests.get('https://api.example.com/data') assert response.status_code == 200 assert response.json()['key'] == 'value' ``` #### Bug测试记录 Bug测试记录是指在测试过程中发现的缺陷的详细描述,包括缺陷的标题、重现步骤、预期结果、实际结果、严重程度和修复状态等信息。这些记录有助于开发团队定位问题并进行修复[^5]。 #### 测试报告 测试报告是对测试执行情况的总结和分析,包括测试用例的执行情况、缺陷统计、测试覆盖率和软件质量评估等内容。测试报告通常用于向项目团队和管理层汇报测试工作的进展和结果[^3]。 #### 测试总结报告 测试总结报告是在测试项目结束后,对整个测试过程和结果进行总结和评估的文档。它包括测试项目概述、测试执行情况、缺陷统计与分析、软件质量评估以及测试工作评价与建议等部分。例如,测试总结报告可以说明“共发现500个缺陷,其中严重缺陷100个,主要集中在用户认证和数据存储模块”[^3]。 #### 测试环境与测试数据构造工具 测试环境和测试数据构造工具用于搭建测试环境和准备测试数据,确保测试的可重复性和准确性。这些工具可以是通用工具,也可以是针对特定项目的定制工具。 #### 流程规范与模板 测试流程规范和模板包括测试流程设计规范、测试用例设计规范、测试脚本设计规范等。这些规范和模板为测试活动提供标准化的指导,提高测试工作的效率和一致性。 #### 知识库与经验总结 知识库包括测试经验总结、业务培训PPT、技术交流总结等内容。这些知识资产有助于团队成员的学习和成长,同时为后续项目提供参考和借鉴[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

surfirst

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值