From: xruiks <kimobook@gmail.com>
Date: 2008/2/20
Subject: [265tom blog] Eight Tips on How to Manage Feature
CreepFeature creep, also kn...
To: kimobook@gmail.com
Eight Tips on How to Manage Feature CreepFeature creep, also known as
scope or requirement creep, refers to unforeseen requests for
additions and changes that are outside the project scope. It typically
happens due to inadequate requirements gathering, poor initial
planning, and an unclear protocol for change implementation, among
other things.
In this article, I'd like to discuss eight tips and suggestions, based
mostly on my experience, to help minimize and manage the effects of
feature creep in your own projects.
1. Accept that feature creep will happen.That's right. Here you are
thinking that this article's all about preventing feature creep. On
the contrary, I feel that it's a natural part of any project-based
work. Acknowledging this eventuality will allow you to be prepared
when it finally rears it's ugly code-retrofitting, design-wrecking
head. Anticipating unforeseen changes in your plans forces you to be
more adaptable, and promotes the development of a solution that's
flexible and malleable to your client's ever-changing needs.
2. Commit enough time to requirements-gathering.Easy enough, fairly
common sense, but we're all guilty of rushing the planning phase of
projects. Maybe it's because of time and budgetary constraints, or our
eagerness to show our clients tangible results, or the assurance we
get that the project's in the bag once we start it (and won't be given
to competition). Skimping on this step can lead to agony at the end,
and can take the form of unanticipated feature requirements because of
our failure to establish the client's actual needs. Take time to
survey the people involved, observe and shadow employees to see how
they might use the system you're developing, and get an accurate
estimation of the technical expertise the organization has. An ounce
of prevention is worth a few thousand lines of code revision.
3. Giving a hand might cost you your arm.If you constantly give in to
changes, you might be get more of them in the future. Try to set
boundaries of what is and isn't appropriate to revise, this not only
prevents unneeded requests for changes, but gives the project strict
quality-control guidelines. When you do decide to comply to un-scoped
demands, make sure that you indicate that you're doing something
out-of-scope, and that this can cause delays and additional financial
requirements. This may make them re-consider the value of the feature
requested, or at least give you an extension in time and budget.
4. Be the devil's advocate when changes are requested.You were hired
and assigned to the project because of your knowledge and expertise in
the solution required. If a client asks for a Flash-based navigation
menu, it is your expert obligation to convince them that the CSS-based
menu you developed is a much better solution. Don't be afraid to
contradict unwise feature requests; providing well-formed reasons will
assure them that you know your "shizznit", and they may actually allow
you to proceed as originally planned.
5. Be task-oriented, not vision-oriented.Be clear on what it is,
exactly, you're developing for them. Don't promise a grand, exciting,
but ambiguous/ambitious end result. Instead of giving broad
generalizations such as "I'll be developing a search engine optimized
website", try to outline the deliverables that you will provide, such
as: "I'll be using image replacement techniques for sub-headings,
creating and implementing a Sitemap.xml, submitting the site to major
search engines, and optimizing page titles with relevant keywords".
This makes the project less ambiguous and prevents additional tasks,
such as developing a link-exchange program to increase page rank
results, which is clearly not part of your duties.
6. Shed the "Customer is Always Right" mentality.You, more often than
not, are a more qualified judge of how things should be developed.
You're not working to get a big tip at the end. You're working (most
probably) on a flat rate fee or an agreed-upon compensation. All you
have to worry about is your reputation and producing an excellent
solution. The employer can hate everything about you, but if you've
provided an amazing profit-generating product, you'll get hired back
to do more. In the end, it's more about profits and deliverables and
less about how your employer loves your "reasonable personality"
(because they love nothing more than making a bundle of cash or
reducing their overhead due to the solution you developed). So don't
give in to unwarranted requests and unreasonable timelines simply
because you want to be on your employer's good side. Don't feel
pressured to do something that isn't in the job description or
something you feel will lead to a less desirable end product.
7. Research before committing.Assuage the temptation to immediately
accommodate a change in project scope, no matter how seemingly simple.
If you think the budget and timeline can handle a modification in
plans, research thoroughly on what the change actually entails before
committing. For example, in a CMS development project I was involved
in, I was asked if it was possible to migrate the system from our
servers, to the client's. This wasn't part of the project scope, as
the original plan was to also provide hosting for the system. I agreed
to it thinking that a database export/import and file migration would
take an hour's work at most. I failed to account for the fact that our
server set-up (being IIS 6.0/Windows and the client's being
Apache/Linux) and server settings were different. Suffice it to say
that it took longer than anticipated and the task is still unfinished.
8. Realize that feature creep is a two-way street.Clients and
employers aren't (purely) evil. They don't intend to make our jobs
more difficult. Oftentimes it's our desire to please, to prove our
worth, and our perfectionist mentality that can be, in part if not
equally, to blame. If feature creep happens, it's only because we
allow it to.
I hope this article was able to impart some tips on how to manage
feature creep. The suggestions here are based on my own mistakes with
regards to allowing scope creep to affect my projects. I hope that by
reading this, you have better luck in alleviating the impact that
features out-of-scope can have on your timelines and budgets.
I'd like to ask: should feature creep be accepted as part of any
project, or should it be prevented flat out? Are these tips ideal but
unrealistic, and in what sense? Share your thoughts!
--
由 xruiks 于 2/20/2008 03:58:00 上午 在 265tom blog 上发表