DDI: How beta is a beta release?November 23rd, 2009
This week our DDI development programme has been brought to you by the letters P and M - of Project Management.
So the big drama this last week has been deadlines and prioritisation - the stuff that gives project managers job security. We really want to get the upgraded Timeframes preview out ASAP, but we've found there's more work to be done than there is time available - I'm sure we're the first people in the world to strike this problem ;-)
But is the problem that we're slow developers or that we're bad at estimating how long the work will take? From my observations, at the end of the day we're basically good old-fashioned, optimistic Kiwis. There's that software development saying of "Take your estimate [of the time it will take to do the work], then double it, then double it again, then you're starting to get close to knowing how long it will take". Well, we apply that rule, then say "nah, surely it can't take thaaaat long, it'll only be half that... she'll be right".
Mind you, estimating accurately is doubly-hard when you're working on a system that you are still learning. We've found Primo is well optimised for university and public libraries, but as a national library we have additional needs - both in the content we have and how we present it. This means we've been sidetracked into developing a number of 'workarounds', though thankfully Primo has a plugin architecture so it hasn't been too mind-stretching.
We've now got something that mostly works, but isn't quite how we'd really like it to be (or how we know it could be). We're running up against our self-imposed deadline but some of the ducks aren't in the row yet. What to do?
It's at this point that all project/product managers hit that age-old dilemma: which would users prefer - almost reasonable today or really good next week? You only get one chance at first impressions. Users usually say they'd prefer 'anything' now, but then grumble when it wasn't what they hoped. I think I'd like to phone a friend on this one.
Given it's only a beta release, how much incompleteness and confusingness in the interface will users put up with? The Google (et al) Labs and 'perpetual beta' phenomena means people are open to the idea of using a site that is a work-in-progress, but we haven't quite set up our environment that way yet so we're on the back foot. While delivering something early may reduce the development workload over the week, it increases the 'comms' workload - communicating what state it's in, known issues, tips for completing tasks, etc., and handling increased user queries (from users that didn't read all that carefully crafted comms stuff).
Not an easy decision... Mainly because there's no 'right' answer.
Separately we've been working on a service model for managing our digital services (remind me to cover that in a later post). While the customers' needs are paramount, we believe there are three perspectives to balance:
- Business needs
- Customer needs
- Technology needs
This was a good opportunity to give the model a whirl in a field-test. We brought together representatives from all three perspectives and reviewed and prioritised each of their needs. We gained a shared understanding of each other's needs and came to a mutual decision. Since this is only a preview (running in parallel with the production system) we decided really there are only two 'must-haves', and once those are ready we'll release it. We'll then move on to tidying up the remaining high priority needs before we cutover the old site - after all, the tidyup won't take long based on our estimates (!!).
Surprisingly we received no feedback (positive, neutral, or negative) for the recent cutovers, so that bodes well for this preview, right??