|To BEta or not to BEta - that is the question|
|Friday, 17 June 2011 08:29|
We have been discussing how to best manage new features and custom development on clients systems. Following our internal QA procedures means that any custom development, or a client system upgraded past the current production release is classed as 'in Beta'.
Now obviously this does not mean that the whole system is in Beta just the new features and arguably some areas of code that might have been affected by this development effort.
What does this mean and how can we be true to our procedures whilst being realistic to what our customers need? The last thing that our customers want to lose is this agile approach to delivery of what is important to their business.
We feel the best way to manage this process is to introduce an official Beta phase for a clients system. Most of our subscribers use the production version and are upgraded every 3 - 6 months with a new QA tested release so this only concerns those customers and prospects that are looking for something specific that we have already written and is working its way into the next release OR if they require a feature developed for them.
If a customer needs a new feature developing there are two things for us to consider, firstly adding a new feature will itself introduce a level of ambiguity which needs to go through the QA stage which is compounded because we will generally add core features to the latest development version and as a by product will mean that there are other development considerations.
Note : We are not 'doing a Google' here and adding the words Beta to every version of OpenCRM for the next 18 months - Honest!
We, like other professional software developers, run a sophisticated version control system which includes multiple versions of the application as it rolls through the Development / Alpha / QA / Beta / Production phases, along with a strict set of policies that dictate when a version is ready for public consumption.
In the past we would never release a Beta version unless it was to a client who had expressed an interest in joining our Beta program, however with the dramatic increase in new systems and the greater than normal percentage of systems requiring custom development we are looking to make some minor changes.
We have introduced a method of adding new features in a very structured way, not just as an ad-hoc amendment to the code, this new process will allow us to flag a custom developed feature or new core feature (that is being introduced early), as a Beta feature - this is clearly visible with the admin settings. This includes a process for making the client and their users aware of what to expect and a process for them to report any unexpected behaviour. Our support desk also has a process to fasttrack any comments on Beta features into the development team to minimise any frustration.
For those users that just cant wait, perhaps they are technoheads or need to be as close to the head of our feature branch as they can, then we still have the Beta program. Obviously we don't make available any new release as an Alpha before the QA stage all of this has to pass our own internal QA process before anyone gets their hands on new stuff - just in case! I remember being told many years ago when Apple was in partnership with Claris Software "we don't have bugs here we just have unpublished features" well I guess that's what we are trying to avoid.