rd 删除 长目录_长时间的反馈循环如何伤害您的rd

rd 删除 长目录

I’ve been a part of the medical software world for a number of years now, and let me tell you: Developing software for a medical company is difficult. You have a lot of regulations to contend with. You must satisfy numerous parties before your software will be used anywhere. This invariable truth will mean that you cannot avoid a longer feedback loop.

多年来，我一直是医疗软件领域的一员，请告诉我：为医疗公司开发软件非常困难。 您有很多法规要应对。 您必须满足许多方面的要求，然后才能在任何地方使用您的软件。 这个不变的事实将意味着您无法避免更长的反馈循环。

But I’m getting ahead of myself. First, what is a feedback loop?

但是我要超越自己。 首先，什么是反馈回路？

It is the time it takes from the moment you make “a thing” until the moment you have got any response on how well that “thing” is doing. I’m being ambiguous since this loop comes in many forms, and it is different for different stakeholders.

这是从您做出“一件事情”的那一刻到您对“某件事情”的执行状况有任何React为止的时间。 由于该循环有多种形式，我是模棱两可的，并且对于不同的利益相关者而言，它是不同的。

For an investor, it might be between making the investment, and getting a sense on how it is doing, or actually seeing revenues.

对于投资者而言，这可能是在进行投资，了解其运作方式或实际看到收入之间。

For a product owner who defines the features of a product, it will be from creating the definition of the feature to getting user feedback on whether it works and provides important functionality.

对于定义产品功能的产品所有者而言，从创建功能的定义到获得用户对其功能是否有效以及提供重要功能的反馈。

For a developer, it will usually be from writing the code to knowing whether it is working properly. But this is another subject that we’ll expand on later, since the end goal can mean various things.

对于开发人员来说，通常是从编写代码到知道代码是否正常运行。 但这是我们以后将要扩展的另一个主题，因为最终目标可能意味着各种事情。

But what is a long or short feedback loop? What length of time is considered “long”?

但是，长反馈周期还是短反馈周期是什么？ 多少时间被认为是“长时间”？

Again, this is subjective to the context of the stakeholder. We’re here to discuss the impact on R&D, so let us focus on that context for now.

同样，这取决于利益相关者的情况。 我们在这里讨论对研发的影响，所以现在让我们专注于这种情况。

了解您的代码有效 (Knowing your code works)

Say a developer writes code and runs a test that was designed to verify whether the code works in a way that matches the requirements, one could say:

假设开发人员编写了代码并运行了一个旨在验证代码是否以符合要求的方式工作的测试，则可以这样说：

If your tests pass — you know your code works.

如果您的测试通过了–您就知道您的代码有效。

Unfortunately, software is more than straightforward code. It needs to be compiled, packaged, deployed somewhere (probably a server in the client facility or maybe the cloud), installed on a client-facing device (like from the Google Play store), and run by the user.

不幸的是，软件不仅仅是简单的代码。 需要对其进行编译，打包，部署(可能是客户端设施中的服务器或可能是云)，安装在面向客户端的设备上(例如来自Google Play商店)，然后由用户运行。

All of those are technical aspects. There are also the dreaded non-technical aspects. Are the users using the software as expected? Are they installing it on devices it’s not meant for, like installing a phone app on a tablet?

所有这些都是技术方面的。 还有一些令人恐惧的非技术方面。 用户是否按预期使用软件？ 他们是否将其安装在不需要的设备上，例如在平板电脑上安装电话应用程序？

If I wrote a function and the tests to check it, then I have a very short feedback loop for that scale. Within seconds I will know if it works or not. Without tests, I would need to manually test the feature, and the said function will be a small part of it. It will take me at least minutes to an hour to check, making the feedback loop longer by a factor of 100 at the least.

如果我编写了一个函数并进行了测试以对其进行检查，那么对于该比例尺，我的反馈循环非常短。 在几秒钟内，我会知道它是否有效。 如果没有测试，我将需要手动测试该功能，而上述功能将只是其中的一小部分。 检查至少需要几分钟到一个小时，这会使反馈循环至少延长100倍。

The impact of a long feedback loop in this context is straightforward: it will take the developer longer to complete even a simple assignment. It might still be “just an hour”, but how much better would it be if it was “a couple of minutes”?

在这种情况下，漫长的反馈循环会产生直接的影响：即使是简单的任务，开发人员也会花费更长的时间才能完成。 可能仍然是“仅一个小时”，但是如果是“几分钟”会好多了？

了解系统工作原理 (Knowing your system works)

Say a developer writes the code for a feature and successfully tests it locally. Now they go on to test it in the deployed environment and find that it isn’t working. It should work because it’s not a big change. Further examination shows another developer is also using the same environment and is making changes to another part.

假设开发人员为某项功能编写了代码，并在本地成功对其进行了测试。 现在他们继续在已部署的环境中对其进行测试，并发现它不起作用。 它应该起作用，因为它没有太大的变化。 进一步检查显示，另一位开发人员也在使用相同的环境，并且正在对另一部分进行更改。

They wait a while, maybe do something else in the meantime. Finally they can try again, and it works! Great.

他们等了一会儿，也许在此期间做其他事情。 终于，他们可以再试一次，并且有效！ 大。

Job done? Not yet.

任务完成？ 还没。

Two months later, when the system is released, reports on issues start to roll in, and apparently, the feature is not working as expected. Now, the developer tries to recall what the feature was, what the implementation was, and why was it done like that. Then they must reproduce the error and figure out the root cause. Suddenly they realize that the local development environment may match the technical layout of the client environment, but the data being pushed into it is just a tiny bit different then what they were aware of.

两个月后，当系统发布时，有关问题的报告开始出现，显然，该功能无法正常工作。 现在，开发人员试图回顾该功能是什么，实现是什么以及为什么这样做。 然后，他们必须重现错误并找出根本原因。 突然，他们意识到本地开发环境可能与客户端环境的技术布局相匹配，但是被推送到其中的数据与他们所知道的只有一点点不同。

As you can see, in this case, it took an entire release cycle before the developers became aware of the difference between the client’s environment and theirs.

如您所见，在这种情况下，开发人员花了整个发布周期才意识到客户端环境与其环境之间的差异。

In this context, the long feedback loop is due to the testing system not exactly matching the client’s system. Not only was the length of the loop so long that the developer lost the context of the feature and took longer to return to it, but the client experienced a defect, which can have a negative effect on customer satisfaction and developer reputation.

在这种情况下，长反馈周期是由于测试系统与客户系统不完全匹配。 循环的时间不仅如此之长，以至于开发人员失去了该功能的上下文并花费了更长的时间来返回它，而且客户遇到了一个缺陷，这可能对客户满意度和开发人员声誉产生负面影响。

While not every software project will face the challenge of developing a system that must match the client’s environment, it is nonetheless a very real problem that must be taken into consideration.

尽管并非每个软件项目都将面临开发必须与客户环境相匹配的系统的挑战，但这仍然是一个必须考虑的非常实际的问题。

了解UX的工作原理 (Knowing your UX works)

Say you’re planning a new feature for your product. After tireless efforts, your UX designer creates a streamlined UI, filled with the latest concepts of flow, retention, and so on. You build on that and spend a month drawing requirements and implementing and testing the code for the new feature. Finally, you release the feature and it reaches the hands of the users. But nothing happens. The users are not really interacting with the new feature. Most of them find the UI confusing and just ignore it. No defects are reported and everything seems fine.

假设您正在为产品计划一项新功能。 经过不懈的努力，您的UX设计人员创建了一个简化的UI，其中填充了最新的流程，保留等概念。 您以此为基础，花了一个月的时间来绘制需求，并实施和测试新功能的代码。 最终，您释放了该功能，并将其传递给用户。 但是什么也没发生。 用户并没有真正与新功能进行交互。 他们中的大多数人都发现UI令人困惑，只是忽略它。 没有缺陷报告，一切都很好。

If the company stays passive, the feedback loop here is falsely indicating that all is fine!

如果公司保持被动状态，则此处的反馈循环会错误地表明一切正常！

Let’s roll back the clock a little and take a different approach. Say that before development, you conducted surveys and focus groups to assert that the UI design is good.

让我们稍微回滚一下时钟，然后采取另一种方法。 假设在开发之前，您进行了调查和焦点小组，以断言UI设计是好的。

This shortened your feedback loop and saved you a lot of time.

这缩短了您的反馈循环并节省了很多时间。

Now let’s fast forward. You release the version with the new feature, and after a while, you see that users are not using the new feature to completion. Your logs are showing some interaction with it but users don’t reach the end of the funnel (e.g., the cart is not reaching the checkout, the form is not being submitted, etc.).

现在让我们快进。 您发布具有新功能的版本，一段时间后，您会看到用户没有使用新功能来完成。 您的日志显示出一些交互，但是用户没有到达渠道的末端(例如，购物车未到达结帐，表单未提交等)。

Even though we had a short feedback loop in the beginning of the project, we “lost” it.

即使在项目开始时反馈周期很短，我们还是“迷失了”它。

How do we shorten this loop? Tools like Google Analytics give you real time feedback on how many people are interacting with your system. Create documentation of each session’s interactions — what the users clicked on, which pages they navigated to, and so on.

我们如何缩短这个循环？ 诸如Google Analytics(分析)之类的工具可为您提供有关与系统进行交互的人数的实时反馈。 创建有关每个会话的交互的文档-用户单击了什么，他们导航到了哪些页面，等等。

长时间的反馈循环会损害您的财务底线 (How a long feedback loops hurts your financial bottom line)

In the end, all these long feedback loops mean development takes longer to release, defects take longer to fix, system installations take longer (where applicable), less users interact with the product, and so on and on.

最后，所有这些漫长的反馈循环意味着开发需要更长的发布时间，缺陷需要更长的修复时间，系统安装需要更长的时间(如果适用)，更少的用户与产品交互等等。

You end up having development cost more, and with less users, revenue is lower than expected.

最终，开发成本会增加，而用户数减少，收入就会低于预期。

Whether you are a manager, owner, developer, UX designer, or any other position, during the entire project the thought should always be there, in the back of your mind: How will I know this works?

无论您是经理，所有者，开发人员，UX设计人员还是任何其他职位，在整个项目过程中，思想始终应存在于您的脑海中：我怎么知道这有效？

翻译自: https://medium.com/@yonatankorem/how-a-long-feedback-loop-hurts-your-r-d-b1116265ea96

rd 删除 长目录