blocks|key|389463|text|我首先要说的是，如果一个PM“偷偷地潜入范围内”，他是一个非常糟糕的项目经理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|389464|话虽如此.对项目经理说不是你的职责。这是你的工作，确保他知道和理解的成本和风险，他正在作出的改变。如果项目经理坚持改变项目的范围而不调整项目中的任何其他内容，那么就找另一份工作(因为项目和/或公司注定失败)。|389465|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Let me start by saying that if a PM is "sneaking in scope creep" he is a very bad project manager. 

Having said that...it's not your job to say no to a project manager. It's your job to ensure that he knows and understands the costs and risks of the change he is making. If the PM insists on changing the scope and adjusting nothing else in the project, get another job (because the project and/or company is doomed).

blocks|key|786707|text|一个好的经验法则是总是回答：“好吧，我们该怎么做才能在最后期限前把这个放进去？”和/或“好的，如果我们把最后期限移到X，我们可以把它加进去。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|786708|每一项更改都会影响完成时间。没有零时间任务这样的东西。强迫项目经理意识到质量、截止日期或特性列表每一次发生变化都会受到影响，这将大大有助于让他们正确地考虑范围爬行问题。|786709|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A good rule of thumb is to always answer, "Okay. What should we drop to get this in by the deadline?" and/or "Okay. If we move the deadline to X, we can add that in."

Every change affects completion time. There's no such thing as a zero-time task. Forcing a project manager to realize that quality, deadline, or feature list will suffer every time they make a change will go a long way towards getting them to think right about scope creep.

blocks|key|773943|text|通过对范围内的内容进行良好的成本计算和功能设计，将其带回给他们，并询问他们是否想将日期移出，或削减其他功能。如果是后者，哪些功能不再重要，还没有启动呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|773944|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

By having good costing and feature design for what is in scope, taking it back to them and asking if they want to move the date out, or cut other features. If the latter, what features are no longer important that haven't been started yet?

blocks|key|773982|text|最简单的方法是坚定地告诉他们，如果包含额外的特性，将影响发布日期。最终，他们的工作是按时发货，所以他们的底线是“我们能在不打破时间表的情况下适应这一点”。如果答案是否定的，那么任何值得他们薪水的项目经理都应该坚定地站在开发的一边，同意这是不可接受的范围蠕变。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|773983|entityMap^0|P|1|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

The easiest way to do it is be firm and tell them that it will affect the release date if you include the additional feature(s). Ultimately their job is to ship a product on time, so the bottom line for them is "can we fit this in without breaking the schedule". If the answer is no, then any project manager worth their salary should fall firmly on the side of development in agreeing it's unacceptable scope creep.

blocks|key|774359|text|是诚实的|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|774360|说明船舶日期、质量和特点之间存在着严格的依赖关系。告诉他们，如果他们想要满足船舶日期，质量将受到影响，如果新的功能被添加。|774361|entityMap^0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

Be honest 

Explain that there is a tight dependency between ship date, quality and features. Tell them that if they want to meet the ship date the quality will suffer if the new feature is added.

blocks|key|774309|text|可能的情况是，当你认为你的项目经理有一种“可能的时候偷偷溜进”范围爬行“的恶毒爱好”时，他的观点可能是不同的。确保你理解他的观点可能会更有成效。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|774310|当然，这是除了传达您自己的观点之外，也就是范围爬行的后果。您可能需要显式地确定开发计划中的额外工作，估计额外工作将花费多长时间，并解释这意味着延迟或放弃其他一些功能。|774311|这只有当你的估计是好的时候才有效。如果你在账簿之外做额外的工作，那么这样做是行不通的，所以额外花费的时间是不可见的。否则，您可能会因为其他原因而满足截止日期，例如更努力的工作或提高效率，并且您的项目经理只会记住范围爬行不会影响“最后一次”的交付日期。|774312|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Chances are, while you suppose that your project manager has a 'pernicious love of sneaking in "scope creep" when they can', his perspective is probably different. It is probably more productive to make sure you understand his point of view.

This is of course in addition to communicating your own point of view, namely the consequences of the scope creep. You probably need to explicitly identify the additional work in your development plan, estimate how long the additional work will take, and explain that this means a delay or dropping some other feature.

This only works if your estimates are any good. This does not work if you do the additional work off the books, so that the additional time spent is not visible. Otherwise, you might meet the deadline for other reasons, such as harder work or efficiency gains, and your project manager will just remember that scope creep did not affect the delivery date 'last time'.

blocks|key|786659|text|让他明白你是如何帮助他保住工作的(也就是说，你是在告诉他真相)。我想他比你更危险。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|786660|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

By pursuading him to understand how you are trying to help him save his job (i.e. you are telling him the truth.) He's got more at stake than you, I imagine.

blocks|key|774424|text|如果你想在你的组织中取得成功，你将希望成为一个团队成员，并且应该努力展示你的承诺。有时，这意味着投入一些额外的时间，以获得一个伟大的新建议的产品。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|774425|然而，你更有可能通过对你合理期望的东西施加严格的限制来赢得尊重。要做到这一点，一种方法是帮助经理们认识到，他们不会通过从事范围爬行来改善产品，但从长远来看，他们更有可能伤害产品。|774426|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you want to succeed in your organization, you will want to be a team player and should strive to demonstrate your commitment. Sometimes, this means putting in some extra time to get a great new suggestion into the product. 

However, you are more likely to command respect by placing firm limits on what can reasonably be expected of you. One way to do this is by helping managers to understand that they are not going to improve a product by engaging in scope-creep but that they are more likely to hurt the product in the long run.

blocks|key|774535|text|客户端是否会要求进入项目的部分？他们有贵重物品要送货吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|774536|如果他们把东西偷偷溜进范围而不让他们看到的话，那么PM肯定会有问题。这是一个严重的问题，我会直接和公开地向他们提出。|774537|然而，范围爬行(在我的书中)是完全可以接受的，如果它继续满足业务的要求。当然，你有最后期限，但是灵活对待你在最后期限上交付的内容又有什么不好呢？这是能见度的关键所在。|774538|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Are the bits that get crept into the project being asked for by the client? Are they valuable items to deliver?

There is certainly an issue with the PM if they are sneaking things into the scope and not making them visible. This is a serious concern and something I would raise with them directly and openly.

However, scope creep (in my book) is perfectly acceptable if it continues to meet the requirements of the business. Sure, you have deadlines, but what's wrong with being flexible on what you deliver on that deadline? This is where visibility is critical.

blocks|key|786756|text|过去对我很有帮助的事情：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|786757|我认为，如果您的项目经理想要潜入功能，他们没有一个准确的项目计划。保留你自己的任务列表，估计每项任务将花费多长时间，按优先级排序-它不需要只是一个详细的文本文档或电子表格。如果项目经理希望您添加新功能，请发送列表副本，并询问应按优先级顺序将其插入何处。|786758|如果项目经理试图降低你的时间估计，那就说“我会尽我最大的努力，但我不能保证任何事情。”|786759|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Something that has worked well for me in the past:

I am taking it that if your project manager wants to sneak in features they do not have an accurate project plan. Keep your own task list with an estimate of how long each task will take, ordered by priority - it doesn't need to be elaborate just a text document or spreadsheet. If your project manager wants you to add a new feature, send a copy of your list and ask where you should insert it in the priority order.

If the project manager tries to negotiate down your time estimates then just say "I will do my best, but I can't guarantee anything."

While project managers may each have their own personality and management style, it seems that many of them have a pernicious love of sneaking in "scope creep" when they can (whether anyone is watching or not). While they usually mean well (bless their hearts), what's the best way that you've found to say "NO" to project managers?

How to tell a project manager "NO" to scope creep

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

虽然项目经理可能每个人都有自己的个性和管理风格，但他们中的许多人似乎对在可能时偷偷溜进“范围蠕变”(不管是否有人在观看)有一种恶毒的爱好。虽然他们通常是善意的(祝福他们的心)，你发现对项目经理说“不”的最好方式是什么？

问如何告诉项目经理“不”范围爬行
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何告诉项目经理“不”范围爬行EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何告诉项目经理“不”范围爬行
EN