Your app will be finished on Tuesday。 — which Tuesday?!

原文链接（需要科学上网）

“Your app will be finished on Tuesday.” — which Tuesday?!

你的应用程序将在星期二完成，哪个星期二？

10 reasons why Software Development projects fail

软件开发项目失败的10个原因

If you search online for trends in software development you’ll find an endless supply of information on booming technologies and how tech is going to impact every sector by 2020. We hear about all the amazing changes new technology will have ad nauseam, but I’m here to question the latter part of the previous sentence.
如果你在网上搜索软件开发的趋势，你会发现有关蓬勃发展的技术以及技术将如何影响到2020年各个领域的无穷无尽的信息。我们听到了新技术令人作呕的所有惊人变化，但我我在这里质疑上一句的后半部分。

“By 2020”. For those of you who don’t speak “software engineer”, that means 2040.
“到2020年”。对于那些不会说“软件工程师”的人来说，这意味着2040年。

As the only guy at Crane.ai that doesn’t write code, I’ve been plagued by this problem for the longest time. Of course, non-coders are also part of the problem; this post was originally going to be about 5 reasons why software development projects fail, but in full client fashion I changed the spec halfway through the project and so it’ll now be about 10 reasons why software development projects fail.
作为Crane.ai中唯一没有编写代码的人，我最长时间一直困扰着这个问题。当然，非编码员也是问题的一部分; 这篇文章最初将是软件开发项目失败的5个原因，但在完全客户端的时候，我在项目中途改变了规范，因此现在大约有10个原因导致软件开发项目失败。

1. Poorly defined (or, god willing, undefined!) outcome

结果弱定义（或者上帝愿意，未定义！）

“Mobile app? We built a bridge, does that work?”
移动app?我们建了一座桥，这有用吗？

One of the largest problems plaguing software development projects is a poorly defined outcome. Without proper definition as to what the “end product” should be, a project is guaranteed to fail.
一个最大的困扰软件开发项目的是结果定义不明确。如果没有正确的定义“最终产品”，一个项目保证会失败。

This is so vital that it could quite possibly change the direction of the project itself (which is why it’s #1 on my list!). I highly recommend building a specification sheet to better identify what the product will look like, what it will do, and how it will do it. More on this under communication and expectations!
这非常重要，它很可能会改变项目本身的方向（这就是为什么它在我的列表中排名第一！）。我强烈建议您制作一份规格表，以便更好地确定产品的外观，内容以及实现方式。更多关于这一点的沟通和期望！

2. Solving the wrong problem.

解决了错误的问题

“We built a new wooden bridge that looks way prettier than the old one. Cars? Oh, no, it can’t support cars. Pretty much anything heavier than a bird will break it.”
我们建造了一座看起来比旧桥更漂亮的新木桥。汽车？哦，不，它不能支持汽车。几乎任何比鸟都重的东西都会破坏它。“

Another common issue is solving the wrong problem. This lies along the same lines as a poorly defined outcome, yet is much broader in scope. Although you can properly identify your end product and solve the other issues discussed here, if your solution does not properly address the problem then you’ve gotten nowhere with the project.
另一个常见的问题是解决错误的问题。这与定义不明确的结果大致相同，但范围更加广泛。虽然你可以正确识别你最终的产品并解决此处讨论的问题吗，但如果您的解决方案无法正确解决问题，那么您就无法使用该项目了。

One way to solve this is to incrementally ideate. Identify your core problem, what steps could be taken to solve it, and a possible solution. Next, constantly iterate the product through with your end user — maintain a constant review process to ensure the project is properly addressing the needs of your user, and remains a solution to your core problem.
解决这个问题的一种方法是逐步进行思考。确定您的核心问题，可以采取哪些步骤来解决它，以及可能的解决方案。接下来，不断地与最终用户一起迭代产品 - 维持一个持续的审核流程，以确保项目正确满足用户的需求，并且仍然是您的核心问题的解决方案。

3. Not enough communication.

沟通不够。

“We built half a bridge, they built half a tunnel.”
“我们建造了半座桥，建造了半个隧道。”

Coming in at #3 is the core problem plaguing virtually every project, industry, and business — communication. Communication is vital at every level of a software development project.
进入＃3是几乎困扰每个项目，行业和商业沟通的核心问题  。沟通在软件开发项目的每个层面都至关重要。

At an internal level, your developers need to communicate effectively to ensure they build tools and pipelines that in coordination and are properly compatible. A common solution here is to draft specifications beforehand for design, APIs, and any other engineering required in your project. This is vital to saving hundreds of hours of time that could otherwise be wasted in refactoring and restructuring.
在内部层面，您的开发人员需要进行有效沟通，以确保他们构建协调且兼容的工具和管道。这里的一个常见解决方案是预先设计规范，API以及项目中所需的任何其他工程。这对于节省数百小时的时间至关重要，否则这些时间可能会在重构和重组中浪费掉。

At a higher level, it’s also important to properly communicate with other teams. The marketing team, for example, needs to know what is technologically feasible before selling the concept.
在更高的层次上，与其他团队进行适当的沟通也很重要。例如，营销团队在销售概念之前需要知道什么是技术上可行的。

Failure to communicate at this level can cause project-shattering issues; the product could end up being severely detached from what was sold, promised, built and needed.
未能在此级别进行沟通可能会导致项目破碎问题; 该产品最终可能与销售，承诺，建造和需要的产品严重分离。

4. No plan or timeline.

没有计划或时间表

“Yeah… it’ll get done around like… maybe a couple weeks? Not sure what we’re gonna do after that…”
“是的…它会在…周围完成…也许几周？不知道我们之后要做什么…“

Regardless of whether timelines and plans are adhered to, it’s important to have one. It provides your project with a sense of structure and gives you an estimate as to when and how tasks will be completed.
无论时间表和计划是否得到遵守，重要的是拥有一个。它为您的项目提供结构感，并为您提供关于何时以及如何完成任务的估计。

Of course, a good plan reaches much further. A good plan or timeline can also serve as a common border for large teams, allowing them to operate quickly and efficiently in sprints. If a feature falls through or needs more time, then the plan/timeline can be adjusted quickly, and the budget adjusted accordingly.
当然，一个好的计划可以进一步发展。良好的计划或时间表也可以作为大型团队的共同边界，使他们能够在短跑中快速有效地运作。如果某项功能失效或需要更多时间，则可以快速调整计划/时间表，并相应调整预算。

5. Lack of accountability.

缺乏问责制

“The buck stops… over there, bye!” — Harry Truman, probably
“降压停在…那边，再见！” - 哈里杜鲁门，可能

When shit hits the fan, someone has to be ready with a mop. If a feature falls through, it should be clear who is accountable and what steps should be taken to prevent this in the future.
当狗屎撞到风扇时，有人必须准备好拖把。如果一个功能失效，应该清楚谁应该负责，以及应该采取哪些措施来防止将来发生这种情况。

It sounds childish but a common occurrence in the software development industry is “pointing fingers.” The backend engineers will blame the frontend engineers will blame the sales team will blame the marketing team will blame the legal office will blame the management will blame… This process is not only time consuming and disastrous for morale, but it leaves the core question — “what went wrong?” — open and unanswered.

6. Moving the goalposts too often.

过于频繁地移动球门柱

“Ok, but now the bridge needs to also act as a runway, have 10 more lanes, and how about a park in the middle of it?”
“好的，但是现在桥梁还需要作为一条跑道，还有10条车道，还有一个位于中间的公园怎么样？”

It’s important to keep track of a project’s goals and make sure they are met in a timely fashion. While it is possible that a project needs to be expanded or the requirements have changed, making frequent modifications to the “end goal” can not only devastate morale, but make a project outright impossible. Often times, changes are unplanned and require extensive refactoring; over time, this leads to a large amount of wasted time, and eventually a failed project.
跟踪项目的目标并确保及时得到满足是非常重要的。虽然项目可能需要扩展或需求发生变化，但频繁修改“最终目标”不仅会破坏士气，还会使项目彻底变得不可能。通常情况下，变更是无计划的，需要进行大量的重构; 随着时间的推移，这会导致大量的浪费时间，最终导致项目失败。

What may seem like a small change at first could end up becoming a long-term development project.
最初看似微不足道的变化可能最终成为一个长期的发展项目。

7. Inadequate documentation and tracking.

文件和跟踪不充分

“The instructions to defuse this bomb say to pull the red wire once the power cuts off, but all of the wires are red and the power was supposed to be cut 10 minutes ago!” — James Bond, at what will be the end of his career
“拆除这个炸弹的指示说，一旦断电，就拉出红线，但是所有的电线都是红色的，电源应该在10分钟前切断！” - 詹姆斯邦德，将会是什么结束他的事业

It’s great to follow an agile methodology and move fast, but documentation is always important. Undocumented code can lead to years of technical debt and can cause tremendous issues down the road — “what does this function do?”
遵循敏捷方法并快速行动非常棒，但文档始终很重要。未记载的代码可能导致多年的技术债务，并可能导致巨大的问题 - “这个功能有什么作用？”

It’s equally important to document the product. Every step of the process from ideation to design to execution should be well-documented to ensure that the project is easily navigable for others and stays on track. Good documentation can allow for easier project tracking — in an agile system, try a kanban board or similar to keep track of tasks!
记录产品同样重要。从构思到设计再到执行的过程的每一步都应该有详细记录，以确保项目可以轻松导航到其他人并保持正常。良好的文档可以实现更轻松的项目跟踪 - 在敏捷系统中，尝试看板或类似工具来跟踪任务！

8. Badly defined system requirements.

定义不明确的系统要求

“WTF do you mean there’s only 5 loaves and 2 fish for all 5000 of us?!”
“WTF你的意思是我们所有5000人中只有5个面包和2条鱼？！”

The technical requirements of a project can be hard to gauge, but it is extremely vital that you do so. What may seem like a small extra addition may turn into a turducken of an issue, involving allocating additional infrastructure and redefining the entire system to introduce support.
项目的技术要求很难衡量，但这样做非常重要。似乎是一个额外的小额外添加可能会变成一个问题，包括分配额外的基础设施和重新定义整个系统以引入支持。

9. Poor preparation.

准备不足

“We’re still flying half a ship.”
我们还在飞半船

Often times a project is exciting and easy to jump into; however, it is vital to its success for the proper preparation to take place. Specifications need to be created, designs must be drafted, a timeline should be agreed on, and resources should be allocated.
通常情况下，项目是令人兴奋的，很容易进入; 然而，正确的准备工作取得成功至关重要。需要创建规范，必须起草设计，商定时间表，并分配资源。

A popular method of managing this at a technical level is Test Driven Development. Before writing a single line of code towards a project, plan out the architecture and what each piece needs to accomplish. Next, write tests to assert that each piece actually does what was intended. In this manner, you have a framework ready with set goals and can quantify progress on the development of your product.
测试驱动开发是一种在技术层面上管理这种方法的常用方法。在为项目编写单行代码之前，请规划架构以及每个部分需要完成的工作。接下来，编写测试来断言每件作品实际上都是按照预期进行的。通过这种方式，您可以准备好具有设定目标的框架，并可以量化产品开发的进度。

10. Unrealistic expectations.

不切实际的期望

“Ok, the app looks good — but why doesn’t the color scheme automatically change to match the user’s phone case?”
好吧，该应用程序看起来不错 - 但为什么配色方案不会自动更改以匹配用户的手机外壳？”

It’s important to manage expectations. Often times, the client asks for a feature that is unreasonable, impractical, or flat-out impossible. A common practice is to limit the number of changes that can be made to a spec and to have an engineer present during discussions to determine if the proposed feature is technologically feasible.
管理期望很重要。通常情况下，客户要求提供不合理，不切实际或不可能的功能。通常的做法是限制可以对规范进行的更改次数，并在讨论期间让工程师在场，以确定所提议的功能是否在技术上可行。

Hopefully, by avoiding these 10 pitfalls, your next software development project will be an astounding success! What issues have you run into in your software projects?
希望通过避免这10个陷阱，您的下一个软件开发项目将取得惊人的成功！您在软件项目中遇到了哪些问题？

总结：我目前所在的公司就有如上大量的弊端。
我记得我在我们公司的第一个项目。
需求不明确，其中一个页面我可能改了近10版。产品经理不断的加入新的需求。
文档不规范，沟通不流畅，总在无止境的等后端。后来我自己把后端接过来写了。
过来三个月，接手一个旧的项目，第一次拿到几乎等于0文档。所有东西都是我从各个可能经手过该项目的人的手上一点点抠出来的。后来自己补充了大量的文档，转给下一个人了。
最近一个新项目，总感觉无法拒绝甲方似的，让甲方无止境的提需求，唯一好的一点甲方的新的需求的时效性没那么高了。因为项目经理不懂技术，自己算你这个新项目的半个扛把子，也算学习了很多