最后期限 软件工程
D E A D L I N E…
最后期限…
As a developer, this is one of your biggest nightmares or should I say your enemy? Name it whatever you want.
作为开发人员，这是您最大的噩梦之一，还是我应该说您的敌人？ 随便命名。
Admit it. It scares you a lot. Even now, while you are reading these sentences, it makes your hair stand on the end.
承认吧 吓死你了 即使现在，当您在阅读这些句子时，它仍然使您的头发直立。
Wondering how I know that?
想知道我怎么知道？
I know because I’ve felt the same. But now the fear is in the past. I’ve made peace with deadlines. I’ve embraced them.
我知道，因为我有同样的感觉。 但是现在恐惧已经过去了。 我已经按时完成了任务。 我已经拥抱了他们。
So I suggest you do the same thing. Embrace them, make peace with them. This is the only way that you can defeat them.
所以我建议你做同样的事情。 拥抱他们，与他们和睦。 这是打败他们的唯一方法。
Ok but, how you can do that?
好的，但是您该怎么做呢？
There are some facts that we all tend to ignore when it comes to setting a deadline. My aim here is to show them to you so you can see that it takes so little to bury the fear and start enjoying life while you are working on your project without worrying about dates.
在设定截止日期时，有些事实我们都倾向于忽略。 我在这里的目的是向您展示这些内容，这样您就可以发现，消除恐惧并开始享受生活时所花费的时间很少，而不必担心日期。
在平静的环境中工作 (Work in a calm environment)
Don’t rush. Don’t force anything.
不要着急 不要强迫任何东西。
The first thing first you should know is that you can’t find your peace by setting unrealistic dates and forcing your team to work in a rush. There are companies that throw out big words and show unrealistic things to motivate their team to move forward. But while there are some facts obvious to everyone in the team, how can you expect them to believe in what you are saying if it is far away from reality?
首先，您应该知道的第一件事是，您不能通过设定不切实际的日期并强迫团队匆忙工作来找到自己的安宁。 有些公司大声疾呼，展示不切实际的事情，以激励他们的团队前进。 但是，尽管团队中的每个人都有一些显而易见的事实，但是如果这与现实相距甚远，您如何期望他们相信您所说的话呢？
Without a fixed — and most importantly believable — deadline, you can’t work calmly. Yes, keeping the calm is the key here. When you don’t trust the date, or when someone tells you to do everything within a limited period of time, or someone adds more tasks to the project without giving you more time, you start working maniacally. This is not work anymore. This is hell.
没有固定的(最重要的是令人信服的)截止日期，您将无法冷静地工作。 是的，保持冷静是关键。 如果您不信任日期，或者有人告诉您在有限的时间内执行所有操作，或者有人在不给您更多时间的情况下向项目添加了更多任务，那么您就会开始疯狂地工作。 这不再起作用了。 这是地狱。
When you are under stress and pressure, you can’t be productive. When you are calm, you are also conscious which means that you can make better decisions.
当您承受压力和压力时，您将无能为力。 当您保持冷静时，您也会意识到，这意味着您可以做出更好的决定。
我们的估计很糟糕 (Our estimates suck)
Windows users will remember that window dialog. The estimation in the dialog is exactly like our estimations, isn’t it?
Windows用户将记住该窗口对话框。 对话框中的估算值与我们的估算值完全一样，不是吗？
Let’s admit it. Our estimates suck. We think we can guess how much time something will take. We have a tendency to believe that whatever we guess will come true.
让我们承认。 我们的估计很糟糕。 我们认为我们可以猜测某件事将花费多少时间。 我们倾向于相信，无论我们猜到什么都会成真。
However, generally, when we are guessing, we ignore some important factors that can affect our assumptions. Why? Because we are too optimistic.
但是，通常来说，在进行猜测时，我们会忽略一些可能影响我们假设的重要因素。 为什么？ 因为我们太乐观了。
To me, the first step in making peace with the deadline and getting better at setting deadlines is to admit that we are terrible estimators. When you embrace this fact, you will be conscious next time and it will prevent you from underestimating the requirements. And here is a solution for you to get better at estimating:
对我而言，与截止日期达成和平并在设定截止日期方面变得更好的第一步是承认我们是可怕的估算者。 当您接受这个事实时，下次您将有意识，这将防止您低估需求。 以下是您可以更好地估算的解决方案：
Divide the big things into smaller things. The smaller it is, the easier it is to estimate. This will increase your chances of having more accurate estimations.
将大事分成小事 。 它越小，估计就越容易 。 这将增加您获得更准确的估算值的机会。
足够好就可以了 (Good enough is fine)
“Perfect is the enemy of good.” — Voltaire
“完美是善的敌人。” —伏尔泰
People like big challenges. We are best at finding a complicated solution for a simple problem. But here is a fact:
人们喜欢挑战。 我们最擅长为一个简单的问题找到复杂的解决方案。 但这是一个事实：
Every problem has its own simple solution that you probably ignore.
每个问题都有其自己可能会忽略的简单解决方案。
Don’t chase a perfect solution. Your first version doesn’t have to be perfect. Build a half product that can work. If you wait too much, you will waste your limited resources and precious time, or you will miss the deadline and even worse do nothing at all because you are chasing perfection. The solution is:
不要追求完美的解决方案。 您的第一个版本不一定是完美的。 制作可以使用的一半产品。 如果您等待太久，则会浪费有限的资源和宝贵的时间，或者您会错过最后期限，甚至更糟的是根本不追求任何东西，因为您追求完美。 解决方案是：
Find the solution that will bring you a lot of value and requires little effort. And don’t forget, good can be turned into great later.
找到可以为您带来很多价值并且需要付出很少努力的解决方案。 别忘了，美好的事物可以在以后变成美好。
不要太乐观。 现实点。 (Don’t be too optimistic. Be realistic.)
I see managers that are too optimistic which makes them set optimistic deadlines to motivate the team. This is so wrong. I’m not telling you that you should be pessimistic about the future. On the contrary, I am telling you that you should be able to see every possibility that can create a bottleneck. Once you can see them, you can consider them and have a more accurate estimation.
我看到经理人过于乐观，这使他们设定了乐观的截止日期来激励团队。 错了 我并不是要告诉您您应该对未来感到悲观。 相反，我告诉你，您应该能够看到所有可能造成瓶颈的可能性。 一旦看到它们，便可以考虑它们并获得更准确的估计。
There are different teams in the company. Engineering, business development, marketing, etc. When the business development team forces you to give them a deadline in the very near future, you shouldn’t get affected by them. They want their job to be done as soon as possible.
公司中有不同的团队。 工程，业务开发，市场营销等。当业务开发团队强迫您在不久的将来给他们一个截止日期时，您不应受到他们的影响。 他们希望自己的工作尽快完成。
Remember that every team thinks about their own side.
请记住，每个团队都在考虑自己的一面。
区分“您必须做”，“您可以做”和“您想做” (Differentiate between “you have to do”, “you could do” and “you want to do”)
Understanding is the key here. What are the core requirements for releasing your product? Usually, the product team has a hard time differentiating them.
理解是这里的关键。 发布产品的核心要求是什么？ 通常，产品团队很难区分他们。
When you have a meeting, one of the team members will say, “we could implement it, it will bring us that much value” or another one will say “We should put this into release.” They are looking from their own perspective. Ok, we can implement this and it can bring us some value, but the important question is that “do we need it now? In the first version?”
当您开会时，其中一个团队成员会说：“我们可以实施它，它将给我们带来很多价值”，而另一位成员则说：“我们应该将其发布。” 他们从自己的角度看。 好的，我们可以实现它，并且可以为我们带来一些价值，但是重要的问题是“我们现在需要它吗？ 在第一个版本中？”
The answer is NO in most cases.
在大多数情况下，答案是否定的。
The things that you have to do are what you should focus on. Eliminate things you could do and you want to do. They are not even negotiable in most cases.
您要做的事情是您应该关注的 。 消除您可以做和想做的事情。 在大多数情况下，它们甚至都不可协商。
默认说不 (Say no by default)
There is one important fact that we usually forget when we say “Yes” to something. We are saying no to the things we already need to complete.
有一个重要的事实，当我们对某事说“是”时，我们通常会忘记。 我们对已经需要完成的事情说不。
When you say yes to something new, you’re not thinking about the impact it will have on your existing to do’s.
当您对新事物说“是”时，您并没有考虑它会对现有工作产生的影响。
“Let’s add more tasks to the project after we’ve set the deadline. (Your project should get smaller over time, not larger.)” NO.
“在设定截止日期后，让我们向项目添加更多任务。 (你的项目应该得到较小随着时间的推移，没有较大的。)” NO。
“We focused on what matters, ok. But what about the details? Let’s consider what kind of details we have that can make problems in the future.” NO. Ignore every detail for the first version. Don’t try to predict the future.
“我们专注于重要的事情，好的。 但是细节呢？ 让我们考虑一下，我们拥有什么样的细节，将来可能会造成问题。” 不行 忽略第一个版本的每个细节。 不要试图预测未来。
Finding more time for things isn’t the problem here. Too much stuff to do is the problem. Differentiate between “must-haves” and “nice-to-haves”.
在这里找到更多的时间并不是问题。 问题太多了。 “ 必须有”和“最好具备”区分。
The only way to get more done is to have less to do.
完成更多工作的唯一方法就是减少工作量。
永不更改截止日期 (Never change the deadline)
I see development teams with a bad habit that can affect their product development badly: deadline rescheduling.
我看到开发团队的坏习惯会严重影响他们的产品开发：重新安排截止日期。
When they miss the deadline, they set a new one. If they can’t meet this one, they set another one. When they do this repeatedly, it becomes a habit. Then this bad habit turns into their culture. Other teams in the company lose trust and question the developers’ work. Even worse, the developer team itself can lose trust in each other. In themselves as well.
当他们错过最后期限时，他们设定了一个新的期限。 如果他们不能满足这个要求，他们就另设一个。 当他们反复执行此操作时，它就会成为一种习惯。 然后，这个坏习惯变成了他们的文化。 公司中的其他团队失去了信任，并质疑开发人员的工作。 更糟糕的是，开发团队本身可能会彼此失去信任。 就其本身而言。
Changing the deadline is essentially an admission of failure. It is making statements like, “We failed to plan requirements, we didn’t say no enough, we didn’t focus on what matters, we pushed our teams to do unreasonable things in an unreasonable time.”
更改截止日期本质上是对失败的承认 。 它发出这样的声明：“我们未能计划需求，我们没有说不够，我们没有专注于重要的事情，我们迫使我们的团队在不合理的时间内做不合理的事情。”
请注意，总会有一些问题 (Be aware that there will be always some problems)
Being too optimistic causes you to ignore the fact that there may be some problems. Be aware. Probably something will go wrong. And this will cause you to lose some time on fixing things. So better to be prepared for bad scenarios. I am not saying that you should be pessimistic and you should try to predict the future and prepare yourself and your team for the unknown. Just find a balance between optimism and pessimism. Be realistic.
过于乐观会使您忽略以下事实：可能存在一些问题。 意识到。 可能会出问题。 这将导致您在修复问题上浪费时间。 因此最好为恶劣的情况做准备。 我并不是说您应该悲观，您应该尝试预测未来，为自己和团队做好未知的准备。 只要在乐观与悲观之间找到平衡。 现实点。
My experience showed me that, in software development, some things always go wrong. My advice to you is:
我的经验告诉我，在软件开发中，某些事情总是会出错。 我对您的建议是：
Add some time to your deadline before you set it by considering that something may go wrong.
考虑到可能会出问题，请在截止日期前增加一些时间。
不要在项目中添加更多人 (Don’t add more people to a project)
A lot of people think that they can speed up the process if they add more people to the project. However, they miss a very important point. Let’s remember Brooks’s law:
许多人认为，如果将更多人添加到项目中，他们可以加快流程。 但是，他们错过了非常重要的一点。 让我们记住布鲁克斯定律 ：
Adding human resources to a late software project makes it later. — Freed Brooks
将人力资源添加到较晚的软件项目中会使其变得更晚。 —释放的布鲁克斯
According to Brooks on Wikipedia, there is an incremental person who, when added to a project, makes it take more, not less time. So why does it work this way?
根据Wikipedia上的Brooks所说 ，有一个渐进式人员，将其添加到项目中后，会花费更多而不是更少的时间。 那么为什么它会这样工作呢？
It takes some time for the people added to a project to become productive. You will have to educate them first. You have already limited human resources and you will have to dedicate those resources to educate new member. Also since they are new, they will introduce new bugs that move the project further away from completion.
加入项目的人员要花一些时间才能变得富有成效 。 您将必须首先对其进行教育。 您已经有限的人力资源，您将必须投入这些资源来教育新成员。 另外，由于它们是新的，因此它们将引入新的错误，这些错误会使项目远离完成工作。
Communication overheads increase as the number of people increases.
通信开销随着人数的增加而增加。
- Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration. However, other tasks including many specialties in software projects are less divisible. Another great example of this by Brooks is: while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”. 将更多的人添加到一个高度可分割的任务中，例如在酒店打扫房间，将减少总体任务持续时间。 但是，其他任务(包括软件项目中的许多专业)很难被整除。 布鲁克斯的另一个很好的例子是：虽然一个女人要生一个婴儿要花9个月的时间，但“有9个女人一个月不能生孩子”。
Another bit of evidence from Richard Dalton to understand why adding more people is wrong is:
理查德·道尔顿(Richard Dalton)理解为什么增加更多人是错误的另一个证据是：
“Teams are immutable. Every time someone leaves or joins, you have a new team, not a changed team.” — Richard Dalton
团队是一成不变的。 每当有人离开或加入时，您就会拥有一个新团队，而不是一个变更后的团队。” —理查德·道尔顿
不要拖延 (Don’t procrastinate)
Let me help you to understand what I mean. Last week, we had a meeting about defining the deadline for a new feature of our product. We were talking about which tasks are our priority and how we should implement them in an effective way.
让我来帮助您了解我的意思。 上周，我们召开了一次会议，讨论确定产品新功能的截止日期。 我们正在讨论哪些任务是我们的优先任务，以及我们应该如何有效地执行它们。
There was a task on which we have heavily wasted our time. There were three ways to implement that task but somehow we were stuck. We couldn’t choose because developers were trying to predict the future. They were starting each sentence with “What if”.
有一项任务我们浪费了很多时间。 可以通过三种方式来执行该任务，但是我们却陷入了困境。 我们之所以无法选择，是因为开发人员正在尝试预测未来。 他们在每个句子的开头都加上“如果”。
You can’t predict what the future will bring you. Don’t over-prepare yourself for the unknown.
您无法预测未来会给您带来什么。 不要为未知而过度准备。
I am not talking about big technical decisions here. Of course, if you have to decide on your core technology, you should sleep on it to find the right solution. But don’t spend your time on small things. Uncertain things increase meetings and block your progress because your backend process is continuously working on them.
我这里不是在谈论重大的技术决策。 当然，如果您必须决定核心技术，则应该依靠它来寻找正确的解决方案。 但是不要把时间花在小事情上。 不确定的事情增加了会议并阻碍了您的进度，因为您的后端流程一直在处理这些会议。
Don’t procrastinate it, decide on it and move forward.
不要拖延，决定并继续前进。
Change your mentality from “Let’s think about it” to “Let’s decide now”. Decisions will speed up your progress. When something is decided, it will be clear to everyone in the team. Everyone will exactly know what to do.
将您的心态从“让我们考虑一下”更改为“让我们现在决定”。 决策将加快您的进度。 做出决定后，团队中的每个人都会很清楚。 每个人都会完全知道该怎么做。
沟通：查看瓶颈在哪里？ (Communicate: See where is the bottleneck?)
You planned everything. You defined what to focus on and what to do. You know exactly how much time it will take (probably you will be wrong). So, the deadline has been settled. Is it enough?
您已计划好一切。 您定义了要重点关注的内容和要做什么。 您确切地知道将花费多少时间(可能您错了)。 因此，截止日期已经确定。 够了吗
NO.
没有。
As I mentioned above, there is always a possibility that something can go wrong. While your team members are working on their tasks, something can block them. Something can stop them to finish their tasks on time. You have to see where is the bottleneck and what it is.
如上所述，总有可能出问题。 当您的团队成员在执行任务时，某些东西可能会阻止他们。 某些事情可以阻止他们按时完成任务。 您必须查看瓶颈在哪里以及瓶颈在哪里。
Communication is the key here. You have to keep teams synced. Sometimes team members can go into a box and it can be very hard for them to see what is happening out of it. This is where you should enter the scene. Once you have identified the bottleneck, remove it so your team members can continue from where they were stuck.
沟通是这里的关键。 您必须保持团队同步。 有时，团队成员可能会陷入困境，而他们很难看到其中发生了什么。 这是您应该进入场景的地方。 一旦确定了瓶颈，就将其删除，以便团队成员可以从卡住的位置继续进行。
I wish you good luck in meeting all your deadlines :)
祝您在所有截止日期前都好运：)
Thanks for reading.
谢谢阅读。
Originally published at https://huseyinpolatyuruk.com.
最初在https://huseyinpolatyuruk.com上发布。
最后期限 软件工程
扫一扫
627
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
