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?
相关问题
- JavaScript variable scope question: to var, or not
- Scope on each last elements of a has_many relation
- Spring session scoped objects in @Scheduled
- Scope Order by Count with Conditions Rails
- variable not being changed out of then scope in fl
相关文章
- Rails scope for values only between two dates
- How to scope closure's variables in CF10?
- What is Scope Creep? [closed]
- Cannot access self:: when no class scope is active
- Function hiding and using-declaration in C++
- Is there a way to call a private Class method from
- Nodejs accessing nested variable in global scope
- JS loop variable scope
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.
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.
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?
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'.
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.
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."