web项目调整项目名称_如何有效调整软件项目范围-CSDN博客

web项目调整项目名称

by Angela Zhang

通过张韶涵

如何有效调整软件项目范围 (How to effectively scope your software projects)

Since starting my career as a software engineer, I’ve learned that scoping is one of the hardest things to get right. Unfortunately, CS programs in universities don’t really teach you how to scope projects. So here’s my attempt at consolidating what I’ve learned on this topic.

自从作为软件工程师开始我的职业生涯以来，我已经了解到范围界定是最难解决的问题之一。不幸的是，大学的CS计划并没有真正教会您如何确定项目范围。因此，这是我尝试巩固我在该主题上学到的知识。

Scoping isn’t something that you can spend a day on during the project and never think about again. In fact, to scope a project accurately, you need to pay attention throughout the project during:

范围界定不是您可以在项目期间花费一天的事情，而再也无需考虑了。实际上，要准确确定项目范围，您需要在整个项目期间注意以下事项：

The planning phase: the early stages of defining the project and its goals
计划阶段：定义项目及其目标的早期阶段
The scoping phase: the time when most people think about scoping. This is where you try to list out the work that needs to be done given the project goals, and estimate how much time will be required to do them.
范围界定阶段：大多数人考虑范围界定的时间。在这里，您尝试列出给定项目目标所需完成的工作，并估算完成这些工作需要多少时间。
The execution phase: when you are actually implementing the project.
执行阶段：实际执行项目时。

规划阶段 (The planning phase)

One of the most important things to do during this time is to define very specific goals for the project. For example, instead of “improve X to be more scalable and performant,” a better and more specific goal might be to “improve X by adding unit tests, supporting 20K queries per second, and reducing capped mean of user latency to <= 200ms.”

在这段时间内要做的最重要的事情之一就是为项目定义非常具体的目标 。例如，代替“提高X的可扩展性和性能”，一个更好，更具体的目标可能是“通过添加单元测试，每秒支持20K查询并将用户等待时间的上限平均值减少到<= 200ms来提高X。。”

Having very specific goals allows you to ruthlessly cut anything that does not contribute to these goals, so that you don’t suffer from feature creep. Along these lines, you might also consider explicitly defining anti-goals, and separating must-haves and nice-to-haves.

拥有非常具体的目标可以使您无情地削减任何对这些目标没有帮助的内容，从而使您不会遭受功能蠕变的困扰。沿着这些线路，您也可以考虑明确界定防目标 ，并分离的必备和可有可无的富人 。

Minimize the batch size of the project by (1) setting up clear milestones and checkpoints for the project, and (2) making it easy to launch only part of the project. Not only does this help break down the project, but it will also allow the team to pause or cut the project early if another, higher priority task comes up.

通过(1) 为项目设置明确的里程碑和检查点，以及(2) 简化仅启动部分项目的过程，可以最小化项目的批处理大小 。这不仅有助于分解项目，还可以使团队在出现另一个更高优先级的任务时及早暂停或削减项目。

De-risk the project as soon as possible. Two common ways of de-risking a project include (1) working on the riskiest parts upfront, and (2) prototyping the riskiest parts using dummy data and/or scaffolding. Whenever a new open-source system or external service is used, that usually represents a big risk.

尽快降低项目风险 。降低项目风险的两种常见方法包括(1)在最危险的零件上进行工作，以及(2)使用虚拟数据和/或脚手架对最危险的零件进行原型设计。每当使用新的开源系统或外部服务时，通常都会带来很大的风险。

Don’t optimize for total amount of work done. Instead, optimize for total amount of impact over time. Once you’ve gotten the riskiest part out of the way, prioritize working on the part of the project that would result in the highest amount of impact immediately.

不要针对已完成的工作总量进行优化。相反，要针对一段时间内的总影响进行优化 。一旦您排除了最危险的部分，请优先处理项目部分，这将立即产生最大的影响。

Here’s one way to think about this: plot the impact of a project over time, where the Y axis is impact, and the X axis is time. At the start of the project, the impact is 0%, and at the end of the project, the impact is 100%. You want to maximize the area under the curve by doing high ROI tasks first.

考虑这种情况的一种方法是：绘制项目随时间的影响，其中Y轴为影响，X轴为时间。在项目开始时，影响为0％，在项目结束时，影响为100％。您想通过先执行高ROI任务来最大化曲线下的面积。

Try to avoid rewriting big systems from scratch as much as possible. When doing a rewrite, we tend to (1) underestimate how much work it would be, (2) be tempted to add new features and improvements, and (3) build an overly complicated system because we are too focused on all the shortcomings of the first system.

尽量避免从头开始重写大型系统 。进行重写时，我们倾向于(1)低估它的工作量；(2)倾向于添加新功能和改进；(3)构建一个过于复杂的系统，因为我们太关注于所有缺点第一个系统。

Instead of doing a big rewrite, consider incrementally replacing subsystems. Have good abstraction layers that support swapping out one part of the old system at a time, so you don’t need to wait for everything to be done to test the new system.

与其进行大量重写，不如考虑逐步替换子系统。具有良好的抽象层，这些层支持一次交换旧系统的一部分，因此您无需等待所有工作完成就可以测试新系统。

范围界定阶段 (The scoping phase)

Only the engineers writing the code should be the ones scoping the tasks. Not their managers, not the PM, or the key stakeholders in the company.
只有负责编写代码的工程师才能确定任务的范围 。不是他们的经理，不是项目经理，也不是公司的主要利益相关者。
Resist the temptation to under-scope. Be honest about how long tasks will take, not how long you or someone else (such as your manager or the Go To Market team) wants them to take.
抵制潜伏的诱惑 。诚实地说任务要花多长时间，而不是您或其他人(例如您的经理或“进入市场”团队)要他们花费多长时间。
Divide the project into small tasks, each taking two days or less. When you have tasks that are scoped to “roughly 1 week,” they often end up taking longer because you didn’t enumerate all the subtasks that you might need to do.
将项目划分为一些小任务，每个任务需要两天或更短的时间 。当您将任务划分为“ 大约1个星期 ”时，它们通常会花费更长的时间，因为您没有枚举可能需要执行的所有子任务。
Define measurable milestones to get to the project goal. Schedule each with a specific calendar date representing when you expect this milestone to be reached. Then, establish some sort of external accountability on these milestones by, for example, committing them to your manager and setting up milestone checkins.
定义可衡量的里程碑以达到项目目标。为每个时间表安排一个特定的日历日期，该日期代表您预计何时达到该里程碑。然后，例如通过将这些里程碑提交给您的经理并设置里程碑签入，对这些里程碑建立某种外部责任。
Think of project time estimates as probability distributions, not best-case scenarios. Instead of telling someone that a feature will be finished in 6 weeks, tell them something like “there’s a 50% likelihood of finishing the feature in 4 weeks, and a 90% chance we’d finish it in 8 weeks.” This tends to force people to be more realistic.
将项目时间估算视为概率分布 ，而不是最佳情况。与其告诉某人功能将在6周内完成，不如告诉他们“在4周内完成该功能的可能性为50％，而在8周内完成该功能的可能性为90％” 。这往往迫使人们变得更加现实。
Add buffer to account for: (1) Dev time != calendar time, due to meetings, interviews, and holidays. I usually multiply the dev time by 1.5 to get to the calendar time. (2) Unexpected project tasks time, since there are always tasks that you didn’t realize you need to do until much later, such as refactoring old code, debugging seemingly unexplainable behaviors, adding tests. The more experienced you are at scoping, the smaller this multiplier would get.
为以下原因添加 缓冲区 ：(1)开发时间！=日历时间，这是由于会议，访谈和假期引起的。我通常将开发时间乘以1.5以得出日历时间。 (2)出乎意料的项目任务时间，因为总有一些任务直到很久以后才意识到才需要做，例如重构旧代码，调试看似无法解释的行为，添加测试。您在范围界定方面越有经验，则该乘数将越小。
Use historical data. Keep track of whether you’ve tended to overscope or underscope projects in the past (most people tend to underscope). Adjust your scoping accordingly.
使用历史数据。 跟踪过去是否倾向于监督项目或对项目进行监督(大多数人倾向于监督)。相应地调整范围。
Keep in mind that 2X the number of people does not mean 1/2X the dev time, as a result of communication overheads, ramp up time, etc.
请记住，由于通讯开销，增加时间等原因， 人数的2倍并不意味着开发时间的1/2倍。
Consider timeboxing open-ended parts of the project. Instead of “find the best stream processing framework for this system,” which can take months of research and prototyping, timebox it to “find a suitable streaming processing framework in a week.” Use your judgement here to balance this against incurring long term operational overhead.
考虑对项目的不限成员名额进行时间限制 。与其“可能需要花费数月的研究和原型开发工作”，而不是“为此系统找到最佳的流处理框架”，而是要选择“在一周内找到合适的流处理框架”。在这里使用您的判断来平衡这与长期运营开销之间的关系。

执行阶段 (The execution phase)

Re-scope regularly during the project execution. For each task, track how much time you estimated the task would take, then how long it actually took you to complete it. Do this for every measurable milestone. If your scoping is off by 50% for the first parts of the project, odds are your scoping will also be off by 50% for the rest of the project.

在项目执行期间定期重新检查范围 。对于每个任务，请跟踪您估计该任务将花费多少时间，然后实际完成您需要花费多长时间。为每个可衡量的里程碑执行此操作。如果您在项目的第一部分将范围缩小了50％，那么您在其余项目中的范围也将缩小50％。

Use milestones to answer “how’s the project going?” As engineers, it’s tempting to answer “it’ll be done by next week” or “until end of this month.” But these types of vague answers tend to create projects that are always 2 weeks away from being finished. Instead, use the (re-scoped) milestones to give a concrete answer based on how much work is left.

使用里程碑回答“项目进展如何？” 作为工程师，人们很想回答“下周完成”或“直到本月底完成”。但是，这些类型的含糊的答案往往会导致创建项目的过程通常距离完成工作还差两个星期。取而代之的是，使用(重新界定范围的)里程碑根据剩余的工作量给出具体的答案。

If the project slips, make sure everyone understands why the project has slipped. Then, develop a realistic and revised version of the project plan. Dropping the project or cutting it short is a potential option that should be considered. Read more about The Sunk Cost Fallacy if you are curious why people tend to bias against cutting a project half way.

如果项目滑倒，请确保每个人都理解该项目滑倒的原因。然后， 制定切实可行的修订版项目计划 。放弃项目或缩短项目时间是应考虑的潜在选择。如果您想知道为什么人们倾向于偏向削减项目一半，请阅读有关沉没成本谬论的更多信息。

Giving credit where credit is due, a lot of information here comes from talking to engineers and managers like Spencer Chan and Nikhil Garg, reading books like The Effective Engineer by Edmond Lau, and personally scoping lots of projects with varying degrees of accuracy.

给予应得的信誉，这里的很多信息来自与工程师和经理(如Spencer Chan和Nikhil Garg)交谈，阅读诸如Edmond Lau的 The Effective Engineer之类的书，以及亲自对许多项目进行不同程度的准确性评估。

Lastly, if I’m being honest, I am by no means an expert on scoping and I still regularly make mistakes like not following some of the best practices above. I just figured I would document my learnings so far so I can refer back to this in the future.

最后，如果我说实话，我绝不是范围界定方面的专家，而且我仍然经常犯错误，例如不遵循上述某些最佳做法。我只是认为我会记录到目前为止的学习，以便将来可以参考。

If you like this post, follow me on Twitter for more content on engineering, processes, and backend systems.

如果您喜欢这篇文章，请在Twitter上关注我，以获取有关工程，流程和后端系统的更多内容。