Day 1 — You bought your <fancy-name>.io domain name and promised yourself you would finish this product for good, this time.

第1天-您购买了<fancy-name> .io域名，并向自己保证，这次您将永远完成此产品。

Day 56— <fancy-name>.io homepage is still a 404. You refuse to talk to anyone about what went wrong.

第56天-<fancy-name> .io主页仍然是404。您拒绝与任何人谈论出了什么问题。

How often do you start a project and give up on it?

您多久启动一个项目并放弃该项目？

Justified by a lack of structure, discipline, or organization, this project that was once your best idea ever gets boring, messy, and doesn’t look as exceptional as when you had your first thought about it.

由于缺乏结构，纪律或组织能力，这个项目曾经是您最好的主意，它变得无聊，凌乱，看起来并不像您初次想到时那样出色。

In short, your project is not even exciting anymore, and you gave up.

简而言之，您的项目甚至不再令人兴奋，因此您放弃了。

Here are some tips to help you stay motivated and keep focused on what matters until you ship.

这里有一些技巧，可帮助您保持动力并在运输之前始终专注于重要事项。

问自己项目的目的 (Ask Yourself the Purpose of Your Project)

I believe you’re working on a concept for a reason. It solves a problem or can be a potential business in the future.

我相信您出于某种原因正在研究一个概念。 它可以解决问题或将来可能成为潜在业务。

• What does it solve?它能解决什么？
• Who’s the target?谁是目标？
• How is it solving the problem?如何解决问题？
• What makes you overly motivated about it?是什么让您对此过于动机？

Write down somewhere the answers to those questions. Be as detailed as possible. Keep that document close to your eyes when working on your product.

在某处写下这些问题的答案。 尽可能详细。 使用产品时，请使该文档靠近您的眼睛。

When stuck or in doubt, read the answers you wrote. They will remind you why you started to work on this product in the first place.

遇到困难或有疑问时，请阅读您写的答案。 他们会提醒您为什么首先开始使用此产品。

建立概念验证以衡量可行性并确定困难 (Build a Proof of Concept to Measure Feasibility and Identify Difficulties)

You don’t want to be working on your product and at some point be like: “Wait, how am I going to do that?”

您不想使用您的产品，并且有时会像：“等等，我该怎么做？”

That’s frustrating because you have to completely stop what you’re doing and come back to the conceptualization phase. This eats your time and motivation.

这令人沮丧，因为您必须完全停止正在做的事情，然后回到概念化阶段。 这会消耗您的时间和动力。

Of course, it always happens that you have something you didn’t think about, and this is normal. But by building a proof of concept, you make sure that your idea technically works. Also, you’ll have a good overview of the potential difficulties you have to pay attention to.

当然，总会发生您没有想到的事情，这是正常的。 但是，通过构建概念证明，您可以确保您的想法在技术上可行。 此外，您还将很好地概述必须注意的潜在困难。

选择一个堆栈并坚持下去 (Choose a Stack and Stick to It)

Coding is fun, and, curious as you are, you are always open to trying new stuff. But there is a moment to benchmark your needs and a moment to freeze your choices!

编码很有趣，而且正如您所好奇的那样，您总是乐于尝试新事物。 但是现在有一个基准测试您的需求的时刻，还有一个冻结您的选择的时刻！

简单场景 (Simple scenario)

Let’s say you’ve built a Rest API for your product. Now that you are focusing on the front-end, you discover how awesome GraphQL would be for your app and want to give it a try.

假设您已经为产品构建了Rest API。 现在您专注于前端，您将发现GraphQL对您的应用程序有多棒，并想尝试一下。

Well, it’s too late.

好，为时已晚。

Because you want to ship your product, you certainly don’t want to spend another week to refactor the API and discover that a part of your logic can’t be copy-pasted and needs to be partially rewritten, etc.

因为您要交付产品，所以您当然不希望再花费一周的时间来重构API并发现无法复制粘贴一部分逻辑，而需要部分重写等。

This is also true if you want to use a UI components library, a state management library, etc. Those things can’t be swapped by snapping your fingers.

如果您要使用UI组件库，状态管理库等，也是如此。不能通过弹指间交换这些内​​容。

您如何防止这种挫败感？ (How can you prevent this frustration?)

It’s simple. Take the necessary time, before or during the proof of concept, to define what language(s), libraries, and new amazing things you plan to use.

这很简单。 在概念验证之前或过程中花必要的时间来定义您计划使用的语言，库和新奇的东西。

This doesn’t mean your choices are frozen in marble forever, but for now, you have to focus on something more important: building your idea.

这并不意味着您的选择将永远停留在大理石上，但就目前而言，您必须专注于更重要的事情：建立自己的想法。

以小型，简单且可访问的目标为周期工作 (Work in a Cycle of Small, Simple, and Accessible Objectives)

I personally like to see quick achievements when working. I want to feel that I’m making progress. I want to be rewarded.

我个人喜欢在工作时看到快速的成就。 我想感到自己正在进步。 我想得到回报。

I mean, who loves to be working for hours and see nothing new happening?If this happens, it means the task is either too big or you got lost achieving it.

我的意思是，谁喜欢工作几个小时而又什么都没有看到，如果发生这种情况，则意味着任务要么太大，要么您就无法完成任务。

Before starting your work session, define a clear picture of what needs to be achieved.

在开始工作会议之前，请明确定义需要实现的目标。

“Oh, the style of that button is a bit broken, I should fix it quickly!”

“哦，该按钮的样式有点破损，我应该尽快修复它！”

No! Don’t get distracted, that’s not in the plan you initially defined.Add this to your “to-do later” list.

没有！ 不要分心，这不在您最初定义的计划中。请将其添加到“以后要做”列表中。

Even if the fix looks easy, consider that it’s not. Maybe it will break something else, and you end up in a hell-loop of tasks that were not planned.

即使此修复程序看起来很简单，也要考虑并非如此。 也许它将破坏其他东西，并且您最终陷入未计划的任务的地狱循环。

Once you’ve accomplished your objective, enjoy a well-deserved break, and get back on the next task (which can be to fix that button).

完成目标之后，享受一个应有的休息，然后返回下一个任务(可以修复该按钮)。

专注于MVP并降低代码质量标准 (Focus on an MVP and Lower Your Code Quality Standards)

… at least for the first iteration.

…至少在第一次迭代中。

Depending on how complex your product is, there can be tons of different scenarios to implement.

根据您产品的复杂程度，可以实现大量不同的方案。

Have all of these scenarios written on your specifications document but focus on the main ones, the ones that make your product usable. If you complete one of these paths, it means your product can then be used.

将所有这些情况写在规格文档中，但重点放在使您的产品可用的主要情况上。 如果您完成这些路径之一，则意味着可以使用您的产品。

Also, even if it can be frustrating, accept that your codebase can’t be as clean as you wish it to be.

同样，即使它可能令人沮丧，也要接受您的代码库不能像您希望的那样干净。

I try to have the architecture of my codebase as robust as possible, but also, if I know some features of my app will evolve a lot in the future, I won’t bother spending too much time and energy on making them perfect.

我尝试使代码库的体系结构尽可能健壮，但是，如果我知道我的应用程序的某些功能将来会发展很多，那么我就不会花太多时间和精力来使它们变得完美。

The product is not even born yet, so take it easy. The goal is to deliver. Users will judge your product and not your code.

该产品尚未诞生，因此请放轻松。 目标是交付。 用户将判断您的产品，而不是您的代码。

Delivering is better than focusing on getting everything perfect.

交付要比专注于使一切都完美更好。

专注于为您的产品带来价值的产品 (Focus on What Produces Value to Your Product)

Don’t spend three days doing that neat animation on the login page.

不要花三天的时间在登录页面上制作整洁的动画。

Users are going to spend only a few seconds there and then forget about it. Worse, it can give a negative feeling if, in the rest of the app, where it matters, users don’t find the same attention to detail.

用户将只花几秒钟的时间，然后忘记它。 更糟糕的是，如果在应用程序的其余部分中重要的是用户没有对细节有同样的关注，它将给人带来负面的感觉。

Invest time on what is crucial for your product, which means: Invest time on the problem it solves. That’s why users will want to use your app.

花时间在对产品至关重要的方面，这意味着：花时间在解决的问题上。 这就是用户想要使用您的应用程序的原因。

准备好参加马拉松比赛，而不是100m比赛 (Be Ready for a Marathon, Not a 100m Race)

As it is always super exciting to work a new idea, it’s often easy to spend a lot of time on it at the beginning. Because of too much motivation, we want to go fast and ship ASAP.

工作一个新的想法总是非常令人兴奋，因此一开始花费很多时间通常很容易。 由于动力太大，我们希望尽快发货。

The problem is that, even if your concept seems simple to build, it’s probably going to require more energy than what you originally planned.

问题是，即使您的概念看起来很容易构建，也可能比原先计划需要更多的精力。

Energy and excitement management is important, especially at the beginning. Going too fast might leave or hide unsolved questions and code structure problems in the long run.

能量和兴奋度管理很重要，尤其是在开始时。 从长远来看，太快可能会留下或隐藏未解决的问题和代码结构问题。

Discipline yourself to work at your cruising speed, from the beginning.

从一开始就管教自己以巡航的速度工作。

感到无聊或沮丧时要定期休息 (Take Regular Breaks When Feeling Bored or Frustrated)

Frustration reduces the quality of what you produce.

挫败感会降低您所生产产品的质量。

If you feel like you went too deep into a problem, got stuck on something, or are not making quick progress, take a break.

如果您觉得自己陷入问题太深，陷入困境或没有快速进步，请休息一下。

Breaks reset your thoughts, allowing you to take a step back, redefine your focus, and approach the initial problem differently.

休息会重新设置您的想法，让您退后一步，重新定义重点，并以不同的方式处理最初的问题。

Later, when you come back to that task, an easy solution might come to your mind. At worst, you will notice the task is too complex and needs to be split down.

稍后，当您回到该任务时，可能会想到一个简单的解决方案。 最糟糕的是，您会注意到任务太复杂了，需要分解。

Switching to another easy task can also help you reduce the frustration and manage to get rewarded anyway for all the hard work accomplished that day.

切换到另一项简单的任务还可以帮助您减少挫败感，并设法获得当天完成的所有辛勤工作的回报。

最后的想法 (Final Thoughts)

The takeaway of this article is that you have to manage your energy, time, and excitement.

本文的重点是您必须管理自己的精力，时间和兴奋。

Bad discipline results in bad decisions, in you forgetting about the big picture or skipping essential steps that will lead your product to a successful release.

错误的纪律会导致错误的决策，使您忘记全局，或者跳过将使您的产品成功发布的基本步骤。

Thanks for reading!

谢谢阅读！