手机屏幕xy坐标软件_软件工程中的xy问题

手机屏幕xy坐标软件

XY problem is classified as a communication problem in which the person who asks the question cannot communicate the problem statement clearly. This situation arises when the questioner needs to do X and they think they can use Y to achieve X so they ask how they can perform Y. However, they should really ask how they can solve X. Without the context of X, people who want to answer can only suggest how to solve Y. Meanwhile, there may be a solution Z that can solve X in a more efficient way.

XY问题被归类为沟通问题，其中提出问题的人无法清楚地传达问题陈述。 当发问者需要执行X并且他们认为可以使用Y来实现X从而询问如何执行Y时，就会出现这种情况。但是，他们确实应该询问如何解决X。在没有X的情况下，想要要回答，只能建议如何求解Y。同时，可能存在可以更有效地求解X的解决方案Z。

There are many instances of XY problems that happen every day in companies. The effect can be from being negligible to sucking resources out of the engineering team for years. There are some case studies from real life examples that help better describe the problem at hand.

公司每天都会发生许多XY问题的案例。 其影响可能是微不足道，甚至是多年以来从工程团队中抽出资源。 现实生活中的一些案例研究有助于更好地描述当前的问题。

案例研究：MySQL搜索 (Case Study: MySQL for Search)

In early stages of a startup that has thousands of users, it makes sense to go with the easiest solution that can solve the problem at hand and just keep the business up and running. However that solution may not scale well when the business gets to millions of users.

在拥有成千上万用户的初创公司的早期阶段，选择最简单的解决方案是有意义的，该解决方案可以解决当前的问题并保持业务正常运行。 但是，当业务吸引到数百万用户时，该解决方案可能无法很好地扩展。

An example is when MySQL was being used for performing search on customers and merchants. Since all the data was already in MySQL, it was the easiest solution to run query on the tables:

一个示例是使用MySQL进行客户和商人搜索时。 由于所有数据已经​​在MySQL中，因此这是在表上运行查询的最简单解决方案：

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.address LIKE '%q%'

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.address LIKE '%q%'

With thousands of rows and even without indexing, this returns results in a reasonable amount of time that matches UX expectations.

在具有数千行的情况下，即使没有索引，此返回结果也会在合理的时间内实现与UX期望相匹配的时间。

As the company grew, the number of rows also grew and we faced a different problem: Paging! Lots of thought went into how to implement a good paging that returns the closest result to the user’s current location. This meant we had to add more criteria to the SQL to include some math for user location. Since the logic was too complicated for ORM to handle, we had to switch to native queries, eventually bypassing the ORM.

随着公司的发展，行数也增加了，我们面临一个不同的问题： 分页 ！ 如何实施良好的分页，使返回的结果与用户当前位置最接近，引起了很多思考。 这意味着我们必须向SQL添加更多条件，以包括一些用于用户位置的数学运算。 由于逻辑太复杂而无法处理ORM，因此我们不得不切换到本机查询，最终绕开了ORM。

When we added international shops to our repository, we faced a new problem. We had to also search both English and the other language name and address. Our SQL looked like this:

当我们在仓库中添加国际商店时，我们面临一个新问题。 我们还必须搜索英语以及其他语言的名称和地址。 我们SQL看起来像这样：

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.i18n_name LIKE '%q%' OR shop.address LIKE '%q%' OR shop.i18n_address LIKE '%q%' [plus paging and user location logic]

SELECT * FROM shop WHERE shop.name LIKE '%q%' OR shop.i18n_name LIKE '%q%' OR shop.address LIKE '%q%' OR shop.i18n_address LIKE '%q%' [plus paging and user location logic]

With more users and merchants added to the system, the query was not efficient anymore. MySQL service connection exhausted and many downstream failures happened. At this point we didn’t know that the increase in number of connections was because of the inefficient search so we focused on healing the database by adding replicas and increasing the instance size for higher CPU and memory.

随着更多用户和商家添加到系统中，查询不再有效。 MySQL服务连接已耗尽，并且发生了许多下游故障。 在这一点上，我们不知道连接数量的增加是由于搜索效率低下所致，因此我们专注于通过添加副本并增加实例大小以提高CPU和内存的容量来修复数据库。

We had a group of engineers that were opinionated to using PostgreSQL instead since it has better performance. Another group debating migrating to a different cloud provider. They spent a lot of time on prototyping and coming up with a migration plan to move to another storage and use another provider.

我们有一组工程师被认为应该使用PostgreSQL，因为它具有更好的性能。 另一个小组正在辩论是否要迁移到其他云提供商。 他们花了大量时间进行原型设计，并提出了迁移计划，以迁移到另一个存储并使用另一个提供程序。

At this point let’s take a step back and analyze the situation:

在这一点上，让我们退后一步，分析一下情况：

X: “We want to give the ability to the users to perform a search on existing merchants with partial data on the name or address.”

X： “我们希望使用户能够使用名称或地址的部分数据对现有商家进行搜索。”

Y1: “How can I use SQL to search the merchant data?”Y2: “How can I improve the SQL performance to get faster/better response?”

Y1： “如何使用SQL搜索商家数据？” Y2： “如何提高SQL性能以获得更快/更好的响应？”

Z: “There are solutions like ElasticSearch that is created to solve this kind of problem”

Z： “有一些类似ElasticSearch的解决方案可以解决此类问题”

Later, we moved to ElasticSearch with couple of months of planning and migration with better and faster response. We left many months of tech debts in our code because of going to the wrong path. This caused the company many engineering hours and a waste of resources.

后来，我们通过几个月的计划和迁移迁移到ElasticSearch，并获得了更好，更快的响应。 由于走错了道路，我们在代码中留下了数月的技术债务。 这导致公司大量的工程时间和资源浪费。

案例研究：Scrum不是目标 (Case Study: Scrum is not the goal)

XY problem can happen in a process in the engineering organization. Agile methodologies have been adopted by many companies. Scrum, which is a very popular one, has been used in many startups to power agility and fast feedback loops.

XY问题可能会在工程组织的过程中发生。 敏捷方法已被许多公司采用。 Scrum是非常流行的一种，已在许多初创公司中使用，以增强敏捷性和快速反馈回路。

Earlier in my career, we used scrum pragmatically. We focused on having all ceremonies, SMART tickets, burn-down charts and etc. One part that we got obsessed about was the ticket estimation. We iterated through different methods:

在我职业生涯的早期，我们务实地使用了scrum。 我们专注于拥有所有典礼，SMART门票，燃尽图表等。我们着迷的一部分是门票估计。 我们通过不同的方法进行迭代：

• 1 story point = half a day of work, 2 story points = a day of work, …
  1个故事点=每天工作半天，2个故事点=每天工作天，…
• 1/2 story point = half a day of work, 1 story point = a day of work, …
  1/2个故事点=工作半天，一个故事点=工作一天，…
• Complexity-based Fibonacci V1 (1,2,3,5)
  基于复杂度的斐波那契V1(1,2,3,5)
• Complexity-based Fibonacci V2 (1,2,3,5,8)
  基于复杂度的斐波那契V2(1,2,3,5,8)
• Software-based online poker planning
  基于软件的在线扑克规划
• Physical cards poker planning
  实物扑克计划

The obsession was so much that it took a good chunk of the meetings to make sure that the estimation is right. Every day we had confidence vote to see how confident people are that they can finish the sprint without any leftovers. We had advanced maths to look at previous X sprints and see the average of story points and predict the future.

如此沉迷，以至于花费了大量的会议来确保估计正确。 每天我们都有信心投票，看看人们有多自信可以完成冲刺而没有剩菜。 我们拥有高级数学功能，可以查看以前的X冲刺，并查看故事点的平均值并预测未来。

Pragmatic scrum advocates called the sprint a failure even if one ticket would slip and had hours of discussion and postmortem analysis of why this has happened. The outcome of these analyses was either a new way of doing scrum or changing the math.

务实的Scrum倡导者称sprint是一次失败，即使一张罚单会滑倒，并且经过数小时的讨论和事后分析也是如此。 这些分析的结果要么是进行混乱的新方法，要么是改变数学的方法。

After a while the performance and output of the teams decreased significantly. Later we analyzed this and found out the following:

一段时间后，团队的表现和产出大幅下降。 后来，我们对此进行了分析，发现了以下内容：

• Engineers were more worried about the Scrum ceremonies than their own tasks. They didn’t want to be the reason of the failure of the sprint
  工程师比他们自己的任务更担心Scrum仪式。 他们不想成为冲刺失败的原因
• Engineers started to overestimate their tickets so they have more room for errors
  工程师开始高估票证，因此他们有更多的出错空间
• Engineers tend not to work on anything outside of their sprint like helping another team, onboarding new engineers, participating in interviews, etc.
  工程师通常不会在冲刺之外进行任何工作，例如帮助另一个团队，聘请新工程师，参加面试等。

At this point Scrum advocates were mostly satisfied since they had the perfect planning but at the cost of a lower engineering department performance and higher stress of engineers.

在这一点上，Scrum的拥护者们大多感到满意，因为他们拥有完善的计划，但付出的代价是工程部门的绩效较低，工程师的压力更大。

Let’s analyze this situation:

让我们来分析这种情况：

X: “We want to ship our products and services on time with efficient utilization of our engineering workforce.”

X： “我们希望通过有效利用我们的工程人员来按时交付我们的产品和服务。”

Y: “How can we improve the accuracy of sprint estimates?”

Y： “我们如何提高冲刺估计的准确性？”

Later the company moved toward the OKR framework and used that to measure the success of teams and individuals. The team started to adopt a standard way of doing sprints across the board with less stress on making it a perfect sprint.

后来，公司转向OKR框架，并以此来衡量团队和个人的成功。 团队开始采用一种标准的全速冲刺方式，以减轻压力，使其成为完美的冲刺。

我们怎么会遇到XY问题？ (How do we end up with XY problem?)

Mostly we end up with XY problem unconsciously and would understand it maybe years later. We have limited resources and we can’t always afford delaying a change for a comprehensive investigation. However, there are some factors that can negatively boost this trap.

大多数情况下，我们会在不知不觉中遇到XY问题，并可能在数年后才明白。 我们的资源有限，我们不能总是为进行全面的调查而延迟更改。 但是，有些因素可能会不利地增加此陷阱。

小胜文化 (Small wins culture)

If there is an outage because of thread pool exhaustion and the (short-term) fix is a single liner to increase thread pool versus the (long-term) fix for investigating of possible bad architecture that may take couple of weeks, many of engineers will go with the first one since it brings early win and they turn up as heroes.

如果由于线程池耗尽而导致停机，并且(短期)修补程序是增加线程池的单一衬套，而(长期)修补程序用于调查可能花费数周时间的可能的不良体系结构，则(许多)工程师将与第一个一起使用，因为它带来了早期的胜利，他们成为了英雄。

阿尔法怪胎统治 (Alpha geek domination)

Alpha geek is a slang term for the most tech savvy person within a group. Once identified, an alpha geek becomes the go-to for all problems, issues and advice when it comes to technology.

Alpha geek是for语，是一组中最懂技术的人的语。 一旦被确定，alpha怪胎就成为了涉及技术的所有问题，问题和建议的首选。

Each company at some level has alpha geeks who get their reputation by doing an amazing job over the years and owned a major part of critical systems at some point in their tenure. Engineers will look up to these folks to answer most of their technical questions or review their designs.

每个级别的公司都有阿尔法极客，这些年来，他们通过出色的工作而赢得声誉，并在任期内的某个时候拥有关键系统的主要部分。 工程师会请这些人回答他们的大多数技术问题或审查他们的设计。

Being an alpha geek is not bad and companies usually in early stages depend on these folks. However, as discussed earlier, the XY problem is a communication problem in which the questioner cannot communicate the actual problem. The problem with alpha geeks in this situation is that they will act the same way as other people, with the information they are provided they make the best judgment. However, it is hard for others to question their judgment since they are mostly always right. This usually keeps other engineers to step back and let the alpha geeks decide on what to do.

成为Alpha怪胎并不坏，而且通常在早期阶段，公司都依赖于这些人。 但是，如前所述，XY问题是发问者无法传达实际问题的沟通问题。 在这种情况下，alpha怪胎的问题在于，它们会以与其他人相同的方式进行操作，并根据他们提供的信息做出最佳判断。 但是，其他人很难质疑他们的判断，因为他们大多数时候都是对的。 这通常会使其他工程师退后一步，让Alpha极客决定做什么。

资源稀缺 (Resource scarcity)

At early stages of a startup, the goal is survival and iterate over features quickly to gather more revenue. In these situations, more senior engineers are equipped with mission critical projects and there are not enough engineers with adequate knowledge to dig into finding the real problem. In these cases, the easiest solution is the one that gets picked.

在启动初期，目标是生存并快速迭代功能以收集更多收入。 在这种情况下，更多的高级工程师配备了关键任务项目，并且没有足够的具有足够知识的工程师来寻找真正的问题。 在这些情况下，最简单的解决方案就是选择一种解决方案。

复杂 (Complexity)

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. — John Gall

总是可以找到一个有效的复杂系统，它是从一个有效的简单系统演变而来的。 从头开始设计的复杂系统永远无法工作，也无法进行修补以使其正常工作。 您必须重新开始，首先要使用一个简单的系统。 —约翰·加尔

All systems eventually will turn into a complex system and depending on the engineering team, it will be broken into one or multiple simple systems again. As the company grows and technical debts are not being paid in time, the system gets harder to simplify. The tendency in this case is to keep the system working until the right moment comes for refactoring and paying debts.

所有系统最终都将变成一个复杂的系统，并且取决于工程团队，它将再次被分解为一个或多个简单系统。 随着公司的发展和技术债务的及时偿还，该系统变得更加难以简化。 在这种情况下，趋势是保持系统正常运行，直到正确的时机进行重构和偿还债务。

It is hard to analyze the system when it is complex. The time for an engineer to dive deep to find the real issue can be spent somewhere else to provide a user facing feature. From the engineer perspective, it is not rewarding to dive into a complex legacy system so the choice here is to address a simpler version of the problem at hand.

复杂的系统很难分析。 工程师可以花大量时间来寻找真正的问题，可以将其花费在其他地方以提供面向用户的功能。 从工程师的角度来看，深入到一个复杂的旧系统中并不值得，因此这里的选择是解决当前问题的一个简单版本。

缺乏多样性 (Lack of diversity)

If members of a team lack diversity, they tend to think the same way about the problem and would eventually agree on a common solution. On the other hand, diversity helps bring different points of views to the problems. Looking at the bigger picture or looking at the problem from a different angle may surface a simpler solution.

如果团队成员缺乏多样性，他们倾向于以相同的方式思考问题，并且最终会就共同的解决方案达成共识。 另一方面，多样性有助于为问题带来不同的观点。 从更大的角度看待问题或从另一个角度看问题可能会浮现出更简单的解决方案。

我们如何防止掉入陷阱？ (How can we prevent falling into the trap?)

We can’t eliminate this completely. It is part of the risk in our day to day decision making. However, we can help the organization to be more aware and take other possibilities for a problem into account. This shouldn’t be a burden for individuals but a culture that needs development. Every individual in an organization can make a difference.

我们不能完全消除这一点。 这是我们日常决策中风险的一部分。 但是，我们可以帮助组织提高认识，并考虑其他可能出现问题的可能性。 这不应该成为个人的负担，而是需要发展的文化。 组织中的每个人都可以有所作为。

作为个人贡献者 (As an individual contributor)

1. Go deeper into the problems and think outside of the box. The problem that is given to you to solve is not necessarily the root problem. Don’t shy away from asking your teammates, your manager and other people in the organization about the root problem.
   更深入地研究问题并跳出框框思考。 给您解决的问题不一定是根本问题。 不要回避向您的队友，经理和组织中的其他人询问根本问题。

2. When framing a problem, provide as much context as possible. Exercise Five Whys when analyzing a problem to get closer to the root of the problem and solve it efficiently.

   框架问题时，请提供尽可能多的上下文。 练习五个为什么分析问题时更接近问题的根源并有效解决问题。

3. Don’t get discouraged if you can’t convince your team to follow the actual problem. Your team may have time constraints and they want to have an easy patch for today’s problem. Create a ticket to follow up later but let the team know this needs to be solved.
   如果您不能说服团队关注实际问题，请不要灰心。 您的团队可能有时间限制，他们想为今天的问题提供一个简单的解决方案。 创建故障单以备后继，但要让团队知道需要解决的问题。
4. Work on your presentation skills and how you frame the problem. You can change the way people think about the problem by providing convincing facts. Always back your facts with verifiable data.
   研究演讲技巧以及如何解决问题。 您可以通过提供令人信服的事实来改变人们对问题的思考方式。 始终使用可验证的数据来支持您的事实。

作为经理 (As a manager)

1. Look for creating diversity in the team. People with different mindset can provide unique values and can help the team improve.
   寻找在团队中创造多样性。 具有不同心态的人可以提供独特的价值观，并可以帮助团队发展。

2. Avoid Common Information Effect. Look for unique information within your team. If people agree on a solution it doesn’t mean this is a right path.

   避免共同信息效应 。 在团队中寻找独特的信息。 如果人们同意解决方案，那并不意味着这是一条正确的道路。

3. Encourage your team member to go beyond the current problem and focus on the root cause.
   鼓励您的团队成员超越当前的问题，并专注于根本原因。
4. Prevent discussion domination by alpha geeks. In team discussion encourage all members to chime in and provide their inputs.
   防止讨论由Alpha极客主导。 在小组讨论中，鼓励所有成员加入并提供意见。
5. Encourage simplicity in the team designs. When a system is simple, finding issues in it is easier and individuals can find root causes for problems easier.
   鼓励团队设计简单。 当系统简单时，在其中查找问题就容易了，并且个人可以更容易地找到问题的根本原因。
6. If for a resource constraint reason you want to go with a different solution, communicate it with the team clearly. Let the team know that you acknowledge their effort to find the actual solution but because of the current constraints you have decided to focus on Y instead of X.
   如果出于资源限制的原因要使用其他解决方案，请与团队明确沟通。 让团队知道您承认他们寻找实际解决方案的努力，但是由于当前的限制，您决定专注于Y而不是X。

作为高级领导团队成员 (As a senior leadership team member)

1. Encourage postmortem culture in your organization. When an incident happens, have individuals dig deep in the root cause analysis to find the actual problem to solve.
   鼓励组织中的事后文化。 发生事件时，请个人深入分析根本原因以找到实际要解决的问题。
2. Reward innovations and thinking outside of the box. People in the organization would likely invest more time digging in the problem if they know it is the company’s culture.
   奖励创新和创新思维。 如果组织中的人知道这是公司的文化，他们可能会花更多的时间来研究问题。
3. Set the goals in a way with the teams that it shows the ideal state and not pushing any specific solution. For example instead of “Increase user engagement by replacing our current email campaign tool from X to Y”, you can set “Increase user engagement by 20%” and let the team define the way they want to get there.
   与团队一起设定目标，使其表现出理想状态，而不推动任何特定解决方案。 例如，您可以设置“将用户参与度增加20％”，而不是“通过将当前的电子邮件活动工具从X替换为Y来增加用户参与度”，然后让团队定义他们到达那里的方式。

4. Embrace OKR. If implemented correctly, each contribution of the individuals can be clearly seen as a contribution to the overall company’s objectives.

   拥抱OKR 。 如果实施得当，个人的每个贡献都可以清楚地视为对整个公司目标的贡献。

翻译自: https://medium.com/@psaeedi/xy-problem-in-software-engineering-350510db267f

手机屏幕xy坐标软件