jpa修改部分属性的方法_产品方法的可能更改，第4部分

jpa修改部分属性的方法

如果我们想提高流程效率，我们该如何组织？ 我们会通过管理人员的服务而不是控制来奖励他们， 第3部分 ，停止按职能进行组织，而转向看起来像基于产品的组织？

对于这个问题，我的转变思路是将组织视为遗留代码。 我们了解如何重构遗留代码。 这需要一段时间，然后，数周或数月后，我们的代码将变得更加健壮，并使我们能够更快地移动。

重构代码时，我们从尽可能小开始。 尽可能小/快速地改变事物。

经理和组织设计不是代码。 在我们更改所有内容之前是否可以考虑重构？

关于重构的思考

如果您曾经接管过某人的代码，那么您将花费大量时间阅读它。 （好吧，我做到了。）甚至在我了解敏捷方法之前，我花了很多时间创建单元测试和系统测试，所以我知道在固定/添加/替换代码时，我没有引入任何问题。

测试是小型的可以通过失败的实验。 在代码中，我可以看到正在运行的，经过测试的功能。 代码是确定性的。 （嗯，我的代码是。）

人们不是确定性的。 （感谢您！）人们有情感。 他们可能会以我们意想不到的方式做出React。

当我考虑重构代码时，我想到了以下技术来管理获取更干净代码的过程：

• 与其他人一起测试/解释/发现代码中的假设。 （在公共场所工作。）
• 工作小。 变化范围越小，重构就越容易。
• 在工作时，添加测试以验证我是否已经以一种有意义的方式更改了代码。 我不想恢复更改。

当我重构并添加更多代码时，我以以下方式工作以创建更简洁的代码：

• 养成使我能够编写简洁代码的习惯。
• 创建领先指标，以便我知道自己在做“正确”的事情，或者至少是我现在所知道的正确的事情。
• 编写小块，在继续进行测试，然后检入。
• 保持代码干净。

如果您想知道，这就是我写书的方式。

重构管理？

如果我们考虑“重构管理”，那么我们如何在公共场所工作，进行小的更改并验证我们是否做了合理的事情？

对我来说，这是关于创建小型，可以安全通过的实验。

我们可以并且应该预见到错误。 人不是完美的，他们不是确定性的。 如果我们可以期望并原谅错误，那么我们可以确保在公共场所工作，进行一些小更改并验证我们所做的合理工作是安全的。 这种文化可以帮助管理者学习如何为人民和产品服务。

我想知道我们要做的第一件事是否是通过运行暴露其漏洞的实验为服务的管理人员创造安全性。 对我来说，这是关于改变经理人的奖励制度，以使他们的薪水不依赖于他们以以往的方式行事 。

我们可以用正常薪水奖励经理，却没有奖金吗？ 如果我们确实必须创造奖励，那么该奖励是否可以与流程效率和协作相结合，以更快地发布产品？ （对我来说，质量是速度的内置要素。代码越清晰，执行速度就越容易。）

当高级经理争取合理的薪水时，经理和团队可以合作创建一些领先的指标或测试，以供他们每天评估：

• 减少一个人做决定的需要。 确定一个人所做的决定，无论该人是建筑师，经理还是项目组合经理。 我们如何记录一个人是否做出任何决定？ 也许要求团队和经理报告他们单独做出决定的次数。 我们要减少这个数字。
• 减少管理决策的滞后时间 。 如果做出决策的时间如此之长，管理者如何得知自己的决策是否正确？
• 可能“衡量”团队和经理的学习量。 （我尚不知道该如何衡量。这可能是我们进行了几次/配对。这可能是实践社区或午餐和学习。现在，这是一个容易上手的游戏方法。
• 可能会评估团队成员在提供/接收反馈和指导方面需要指导的次数。 敏捷/产品团队需要嵌入团队内部的领导技能，这样经理才不会陷入控制行动中。）

这是我的初稿，是我的失败测试。 还有其他措施可能会更好。

产品组织要求更改行为

我说的是改变组织的行为和文化。 这不是为期两天的课程的一部分，也不是“变革计划”的一部分。

行为上最大的变化之一是需要在组织的各个级别进行协作。 团队共同协作。 经理们为了团队的利益，经理们的决策，产品决策以及项目组合的管理而进行协作。

请注意，我并不是说要重组所有内容。 我们甚至不知道要创建的假设。 在下一篇文章中将对此进行更多介绍。

以下是本系列的帖子：

• 项目工作与产品工作 （我没有意识到我已经开始了本系列。）
• 产品定位需要技术卓越
• 设计产品方法的组织，第1部分
• 设计产品方法的组织，第2部分
• 定义产品方法的经理角色，第3部分

完成本系列后，我将使用所有链接更新其他文章。

翻译自: https://www.javacodegeeks.com/2018/10/possible-changes-product-approach-part-4.html

jpa修改部分属性的方法