今日推荐英文原文：《Why Solving the Wrong Problem Is Guaranteed to Ruin Your Software Project》
推荐理由：这个项目是一个教你如何保护 Linux 服务器的指南。当然了，在使用之前最好先拥有一台 Linux 服务器，它一不教你用 Linux 二不教你关于安全性的方方面面（比如物理方面的）。它能做的就是从访问服务器的方面去强化安全性，兴许有的时候你正需要加强这一点。
今日推荐英文原文：《Why Solving the Wrong Problem Is Guaranteed to Ruin Your Software Project》作者：Tomer Dicturel
Why Solving the Wrong Problem Is Guaranteed to Ruin Your Software ProjectIf a poorly defined outcome is the №1 reason why software development projects fail, then a close №2 is solving the wrong problem. This is a particularly insidious problem because you might have just spent a few weeks working on little to no sleep and consuming dangerous amounts of caffeine, only to realize that your project has dangerously gone off the rails. You thought you were supposed to solve Problem X, but you were really supposed to solve Problem Y.
So why does this happen far too frequently in the software development industry? It’s too easy to chalk it up to sheer incompetence (although, admittedly, that does play a role in some cases). No, a better answer might be a lack of proper communication between the different stakeholders in the project.
In the best of all possible worlds, of course, there would be complete buy-in on the problem being solved by the software project at every level of an organization, and across all different functional units. In other words, the way the CEO views the project is the same way the VP of Marketing sees the project, which is the same way the VP of Operations views the project, and so on, down the line.
But how often is that the case? The head of marketing may want a product that looks great when photographed for Instagram (but is way less concerned with overall functionality), the CEO may wish to a product that is going to become the new “killer app” of the industry, and the end user — the person who is actually going to be using this product — just wants a new tool to help them do their job better on a daily basis.
One way to ensure that all team members are on the same page is via a process of incremental ideation. As part of this process, you first identify the core problem, then outline what steps you can take to solve it, and then commit to regular communication with all team members, in order to make sure that you are still addressing the right problem. By regularly interacting with all parties involved via a continuous review process, you can ensure that the project is appropriately adhering to the needs of the end user.
But here’s the thing — somebody needs to “own” the project. In the agile software world, for example, that’s the “product owner.” It’s the responsibility of that person to ensure that everyone is using the same language to describe what’s needed, and that team members are always asking questions and communicating with each other to ensure that they are really building what they set out to build. Communication needs to be fluid and happen when the need arises, rather than being scheduled in advance.
In fact, the role of communication and continuous feedback is so important that it is enshrined as the most critical foundational value of the Agile Software Manifesto: “Individuals and Interactions Over Processes and Tools.” If you are valuing individuals and interactions, then you are more likely to meet customer needs. At the very least, you won’t have to face the awkward situation when a client interrupts you at a meeting and says, “But I thought you were going to…”
Hey! I’m Tomer, an entrepreneur, and a maker. You might know me from Mevee, Crane and Shots, among other products I’ve launched! This article is a part of a more extensive series I’m writing mostly based on my experiences and is mainly made of my and my team’s opinions.
I hope this helps you to avoid making the same mistakes I did, and remember to keep shipping!