A
typical project at Acuit
First meeting
When clients call us to discuss the possibility doing a
project for them we usually meet to discuss the basic scope of the
project. During such meetings we talk about the end product,
the value to users, the market, and sales methods and
volume. That gives us a good vision of how the product will
be used. We don't feel as though we can effectively develop
products without knowing these kinds of details. Have this
foundation, we then seek to understand what our role as developers
and project managers is. Sometimes we discuss costs and our
development processes which include our unique web based method of
project management.
Leading up to the project
There are often many discussions of availability, product
features, cost and delivery during the time leading up to our
actual involvement. We make ourselves available at no cost
for such meetings. We also communicate using email and
telephone. We sincerely want what is best for our clients
even if doesn't include our involvement on certain projects.
Our philosophy is that if the client really needs us, we'll be
there to help. We won't push ourselves into projects the
client can do themselves or other are better skilled for.
Why do that? It only makes people mistrust you. It's
not a good thing to do.
During our discussion of money we take the position that
relationships are always more important than money. We will
almost always choose the former over the later. If a client
feels they are being cheated by our fee structure, them maybe they
are right! It's a delicate issue that requires us to be
sensitive to.
Developing a Specification
This is a really hard thing for a lot of people. People are
just not accustomed to spending the time to write a detailed description
of what they intend to build. The problem stems from the
belief that they can "see" it all in their minds-eye,
and that since they can "see" it all, there is no reason
to expend the extra energy to write it down. After all,
that's a waste of time, and time is money, and nobody has a lot of
that to burn. People want to jump right in and start the
implementation at once. Some people need to see progress
immediately or they begin to feel as though the developers are
incapable of delivering the final product. They also assume
that if a long period time elapses right up front then the product
will be late. But are those things really true? We
don't believe so. Therefore we always write a
specification document before writing any code.
When we write a spec it is really just a matter of identifying all
the unknowns, and documenting the entire product, even if the
product is simple in nature and features. Our clients are
almost always amazed at how many things they didn't
"see". The act of documenting your ideas always
uncovers issues and things you didn't originally think of.
The very act of writing something down uses entirely different
mental capacities of those used in conceiving of an idea.
Sometimes we separate the process of writing a specification into
a separate project. We will sometimes bill the client for
this work alone. This helps them separate the two processes
and see the value of the written document. This is also the
time for brainstorming ideas and concepts, then solidifying them
into a workable product. The last thing you want to do is brainstorm
and idea, go off and implement it, then realize it wasn't the best
idea after all. Then you are back brainstorming again.
A very inefficient process!
One of the many valuable byproducts of a finalized written
specification is that you can create a project schedule directly
from it. That leads you directly into the
implementation. Everything just flows from that.
Project commences!
Well off we go - with spec in-hand! Often times Acuit
developers are chosen as project managers or lead
developers. The particular skills we poses often suggest or
dictate that role within a project. We will often spend a
bit of time looking down to the end of the project and forecasting
and communicating events to come. What kind of events
naturally take place in these kinds of projects?
Infrastructure setup
Every software product needs a predictable and repeatable build
environment to be really successful. We set up such
environments right at the beginning. This includes a build
lab, web projects, source control, developer projects, and a
delivery plan. All of this infrastructure gets put into
place right away, and we use it to develop the product. This
makes betas, milestones and the final deliver a snap!
Milestones and checkpoints
Everyone knows that software products go though various stages of
Beta before release, but what do those milestones mean? And
why do we have them? Primarily the purpose is to "test
release" a product. We'll talk about that a little
later. At Acuit, we generally have a "First
Look", Beta 1 and 2 before ship. These milestones
have different significance.
"First Look"
A First Look is a way for the developers to show the product to
users and management for the first time. It is a point in
time where the product "lifts off" for its first
flight! Everybody gets to have a look-see, and everybody
gets to make their comments on features and usability. This fledgling
often gets a lot of abuse! Suddenly everyone has an opinion
about how it ought to work. That's good. This changes
are incorporated in to the next phase of development.
Beta 1
The first beta is a natural stopping point for quality
assurance. The product is usually at a very stable point and
is usable by a wide variety of users. All the features
suggested from the "First Look" are either incorporated,
set aside for future releases, or canned. The user interface
components are all in place and generally usable. There is
often a strong push on the part of developers just before a
Beta to ensure that the product meets these general goals.
The product is now ready for field usage.
Beta 2
This product is nearly a shipping product. There are no new
features to be added or considered. The product has reached
a strong quality position and almost shippable. The program
will be considered a candidate for release soon.
Localization and "Simship"
Before releasing a product there is often a phase where the
development team needs to consider how the product will be
translated for use in global markets. Sometimes companies
ship a product to U.S. markets simultaneously with other global
markets. This is called "Simship" or simultaneous
ship. It requires that the product be translated into
various languages before the U.S. version even ships. There
are variety of challenges connected with this that beyond the
scope of this discussion. At Acuit, we work closely with a localization
company to develop localized versions of our software.
Release Candidate and Gold
As the product reaches the point where it meets quality
expectations it becomes a candidate for release. We all
sort-of stand back and say; this product is ready for
release. It has become a Release Candidate or RC1. But
is it really, really ready for release? Sometimes not.
Sometimes jsut after you declare it done, you discover one or two
issues you feel you need to resolve before releasing the product
to manufacturing. If you find such and issue in RC1, you
naturally advance to RC2. This process allows you to step
back and breath before releasing the product. This act of
stepping back puts you into a new mode of objectively viewing the
product as the user sees it. If you release before this
little phase then you are bound to make a mistake or two.
And the end user ends up suffering.
Acuit is very serious about quality and users simply will
not stand for buggy software. These are some of the
processes that are necessary to ensure quality. You've
simply got to bake the product fully, with no shortcuts, or you
will reap the consequences.
It's funny how some developers view bugs. If your software
sometimes fails to work or crashes you put up with it, and reboot,
but if your radio doesn't work right you take it back to the
store. Users are beginning to adopt that philosophy with
software!
Service, Support and Warrantee
Acuit developers stand behind the code they write. We offer
support to our clients that ensures that they are never left
without a fix for their customer. Oftentimes we negotiate
for a warrantee period where Acuit will fix any bug discovered
within a certain time period.
Good vibes and future work
We certainly hope that our attention to detail and insistence
upon delivering quality make our customers happy. In fact we
know it does. That is why they keep coming back!
Also see: About, Projects
on the web |
