漫步欧洲

by David Yu

由于大伟

如何使您的发射过程在公园中漫步 (How to make your launch process a walk in the park)

It was 2AM. My phone was still buzzing with developer conversations about how to handle 404 pages. It was only the beginning…

是凌晨2点。 我的电话仍在与开发人员有关如何处理404页面的对话嗡嗡作响。 这仅仅是开始...

T minus three days until launch. We were running around like a chicken with its head cut off. ?

T减去发射三天。 我们像头被割断的鸡一样跑来跑去。 ？

I had to think of how we would avoid the feeling of apocalypse when we approach the official launch date.

我不得不考虑在临近正式发布日期时如何避免启示的感觉。

As Murphy’s Law states:

正如墨菲定律所述：

Anything that can go wrong will go wrong.

任何可能出错的地方都会出错。

How do we launch a product and ensure that something DOES NOT go wrong (as much as we’re able)?

我们如何推出产品并确保某些地方没有出错(尽我们所能)？

Below is the beta version of my strategy for the next launch.

以下是我下次发布策略的测试版。

第一周有内容 (Have content for the first week)

When you tell a client that the launch date is a month away, the list of data and assets required for launch are buried in their Inbox and pop out just a week before launch. ?

当您告诉客户启动日期已过一个月时，启动所需的数据和资产列表将埋入其收件箱中，并在启动前一周弹出。 ？

In the end, we’re scrambling for stuff because of the sudden changes to images and text — the “little things”.

最后，由于图像和文本的突然更改(即“小事情”)，我们争先恐后。

Oh wait, the image size ratio is not right, let’s double check with the client if there is another image…

哦，等等，图片尺寸比例不正确，让我们仔细检查客户端是否还有其他图片……

Valuable time is lost during this back and forth communication.

在这种来回通信过程中浪费了宝贵的时间。

如何敦促客户提供您所需要的信息而又不失礼貌 (How to urge the client to provide the information you need without being rude)

• Explain how the content is the soul of the product. Without it, the product is only a skeleton of fancy logic.解释内容是产品的灵魂。 没有它，产品只是幻想逻辑的骨架。
• Be more proactive in understanding what their obstacles are in acquiring those assets.更加主动地了解他们在获取这些资产方面遇到的障碍。
• Write down detailed specifications for image and copy: image size ratio, preferred file type, word length, preferred font family, etc.写下图像和复印的详细规格：图像尺寸比率，首选文件类型，字长，首选字体系列等。
• Identify the single person who is responsible for the task. Offer help and assistance. Adjustments are easier to do in the early stages.确定负责任务的单身人士。 提供帮助和协助。 在早期阶段调整比较容易。

如果客户说：“冷静...兄弟，我们在处理。” 您还没有采取明确的行动吗？ (What if the client says, “Chill…bro, we’re on it.” And there’s no clear action you see being taken?)

You could explain why you’re in a hurry, so they get the context behind what all you need to do.

您可以解释为什么要着急，所以他们可以为您提供所有需要做的事情的背景信息。

It’s like building a brick house. When we only have one or two bricks laid on the ground, we can easily say, “Meh, I don’t like brick. Let’s use bamboo.”

这就像盖砖房。 当我们只在地面上放一两个砖块时，我们可以轻松地说： “嗯，我不喜欢砖块。 让我们用竹子。”

But, it will take a miracle to swap bricks with bamboo when the brick house is near completion. We will build a flimsy house (product) at best if that’s the case, or our launch date will be delayed.

但是，当砖房即将完工时，用竹子交换砖头将是一个奇迹。 如果那样的话，我们最多只能建造一个脆弱的房屋(产品)，否则我们的发布日期将被推迟。

坚决冻结功能 (Be firm on feature freeze)

Feature freeze is a handy concept that is easier said than done.

功能冻结是一个方便的概念，说起来容易做起来难。

In software engineering, a freeze is a point in time in the development process after which the rules for making changes to the source code or related resources become more strict, or the period during which those rules are applied - Wikipedia

在软件工程中， 冻结是在开发过程中的某个时间点，在此之后，对源代码或相关资源进行更改的规则变得更加严格，或者应用这些规则的时间段-Wikipedia

In addition to setting a feature freeze a week prior to the launch date, we also need to be clear about what a feature is.

除了在发布日期的一周前冻结功能外，我们还需要清楚功能是什么。

A discrete piece of functionality desired by stakeholders - Oliver Dolan

利益相关者所需的离散功能-Oliver Dolan

If you have a website with an interactive map in it, would it be a new feature to build a “back-up” map with another map provider?

如果您的网站中包含交互式地图，与其他地图提供商一起构建“备份”地图是否是一项新功能？

Our thought process may have been that since we’re in China, there is no guarantee that our first choice of map provider wouldn’t be blocked.

我们的思维过程可能一直是，由于我们在中国，因此无法保证我们的首选地图提供商不会受到阻碍。

So we may cram it into our schedule as a feature.

因此，我们可以将其作为功能添加到我们的日程表中。

But, how do we decide if this feature is worth our time?

但是，我们如何确定此功能是否值得我们花时间？

这是您要向团队和客户询问您计划实施的每个功能的问题 (Here are the questions to ask your team and client for every feature that you plan on implementing)

1. What happens if we don’t implement this?如果我们不执行此操作会怎样？
2. What’s the priority level of this?优先级是多少？
3. Do we have the capacity to take on this work without delaying the launch date?我们是否有能力在不延迟启动日期的情况下进行这项工作？

更加自信 (Be more assertive with your opinions)

Imposter syndrome affects us at all stages of our career. When a senior developer with 20 years experience says let’s do it this way, and you’re not 100% sure about a counter argument, you whisper under your breath, “Oh… ok.”

冒名顶替综合症会影响我们职业生涯的各个阶段。 当拥有20年经验的高级开发人员说让我们这样做时，如果您不确定100％是否存在反驳，您会低声说：“哦，好吧。”

This is what I do when I can’t come up with a better solution on the spot.

当我无法当场提出更好的解决方案时，这就是我要做的。

那么，我们如何为这种情况做准备？ (So, how do we prepare for situations like this?)

• Understand exactly how we arrived at the conclusion first确切了解我们如何首先得出结论
• Phrase your solution as a question将您的解决方案作为问题
• Write down what bothers you and think of a better way to do it later写下困扰您的事情，并考虑以后做一个更好的方法

• Improve your communication skills

  提高沟通技巧

If at first, the idea is not absurd, then there is no hope for it. - Albert Einstein

如果一开始的想法不是荒谬的，那么就没有希望了。 - 艾尔伯特爱因斯坦

首先照顾DevOps (Take care of DevOps first)

We complicated our initial setup for development, staging, and production. We spent an enormous amount of time on working on a problem and coming up with a solution.

我们简化了用于开发，登台和生产的初始设置。 我们花费了大量时间来解决问题并提出解决方案。

Waiting twenty minutes to see my changes come online because of fancy code pipelines and connection issues almost made me hate coding. ?

由于花哨的代码管道和连接问题，等待二十分钟才能看到我的更改上线了，这几乎使我讨厌编码。 ？

那么，我们怎么能做得不同呢？ (So, how could we have done it differently?)

• The Dev environment should be able to change fast.

  开发环境应该能够快速更改。

• If automation is not saving time, it’s not automation.如果自动化不能节省时间，那不是自动化。
• Use a cloud provider that meets your needs使用满足您需求的云提供商
• Make sure the deployment process is smooth from week one确保部署过程从第一周开始就顺利进行

有一份检查清单 (Have a checklist for testing)

To prevent time lost while fixing the same thing, here are a few things to keep in mind when writing the list.

为避免在修复同一内容时浪费时间，在编写列表时，请注意以下几点。

And I’m not talking about writing code to test your code. How often do we fix something and something else breaks?

我不是在谈论编写代码来测试您的代码。 我们多久修理一次，其他东西坏了？

To avoid having to fix the same thing over and over again, here are a few things to keep in mind when writing the list.

为了避免一遍又一遍地修复同一件事，在编写列表时，请记住以下几点。

• Write the checklist from the user’s perspective从用户角度编写清单
• Grow the list with the feedback from each iteration通过每次迭代的反馈来增加列表
• Have a fresh set of eyes run through the list一览无余
• Help other developers on the team check the list帮助团队中的其他开发人员检查列表

练习同理心 (Practice empathy)

No matter what position you’re in. A little empathy goes a long way.

无论您身在何处，都有一点同情心。

For example: if you built an API that’s utilized by a web app and you’re about to make some data key naming changes.

例如：如果您构建了一个供Web应用程序使用的API，并且您将要对数据键命名进行一些更改。

You understand the particular data key names may have been included everywhere by another developer in a web app. Proactively notify other developers before things start to go wrong.

您了解特定的数据密钥名称可能已被Web应用程序中的其他开发人员随处包含。 在出现问题之前主动通知其他开发人员。

By notifying all teams that may be affected by a change, we can reduce the likelihood of hiccups during the live demo or even production.

通过通知可能受到变更影响的所有团队，我们可以减少在现场演示甚至制作过程中出现打h的可能性。

Every role in a team faces its own hurdles. The ability to put yourself in different shoes will change you from just a developer who writes code into a leader that dishes out high quality stable code.

团队中的每个角色都面临着自己的障碍。 使自己陷入困境的能力将使您从仅由编写代码的开发人员转变为提供高质量稳定代码的领导者。

谢谢阅读 (Thanks for reading)

If you enjoyed this piece, you can clap ? it up so more people can benefit from it.

如果您喜欢这首乐曲，可以鼓掌吗？ 它使更多的人可以从中受益。

翻译自: https://www.freecodecamp.org/news/how-to-make-your-launch-process-a-walk-in-the-park-2762841e9481/

漫步欧洲