So having been careful about requirements, prototyping iteratively, testing with real users early on and getting it out the door quickly, what now? No doubt users are calling, or emailing questions, feature suggestions, raves, rants and some, hopefully occasional, hate mail. There are some naysayers at this point hollering that it went out the door too soon. Be calm…
The reality is the all the finest and most experienced software companies ship fast, Microsoft, Apple, etc. The reason is that software rarely gets better after a certain point. Software really can only be so good by design. It only can become great software when in gets into the hands of real users trying to accomplish something they value. Period. It doesn’t matter how screwed up the software is, you’re on the right track.
So with flames all around you, it’s time to profit from shipping quick. All the information coming at you is gold. Here’s what to do with it:
- Capture
- Categorize
- Postmortem
- Kit
- Launch
Capture
Many shops have defect tracking systems. And you know, that is a good thing. However, the days and weeks after shipping new software is a little like brainstorming a new product. There is a tendency with defect tracking systems to narrow things down to the explicit cause and effect of a problem or bug. But right after a new product is shipped you’re going to receive a lot of input that doesn’t fit this mold (”I think the new interface sucks!”).
It is really important to capture everything you hear back from the field. I mean everything. So don’t just capture that someone thinks the new interface sucks. Make sure you capture exactly how many people said it, who they were, how loud they were, and the date. Not kidding!
Categorize
After trends start to develop generate some categories to sort the input into. Don’t get too anal about this. It is again like brainstorming, try to sensor things as little as possible. If you’ve got something that resists all other categories, give it its own category for a while. Do not make a category called Misc and put the oddballs there. One oddball idea ignored has been the death of many a project. Treat every insult with the utmost respect.
Postmortem
Dead is bad, right? Wrong. Dead is just the state of being over, being done. The previous cycle of software development tried to produce the most wizbang code for wowing users and making everyone in the company rich. It didn’t do that, right? What can we see in the feedback coming to us now, that is completely surprising?
What was predicted, that we didn’t act on and turned out to be true? Who predicted it? Why didn’t we listen? Was that a good choice to ignore (maybe it was)? Crawl through every angle of how these issues were regarded before ship date. The most important point is to have no judgment. There aren’t any right or wrong answers, no one has a crystal ball. The point is to try to stretch our imaginations to be more like how the outside world regards our work.
Kit
So with a basic set of categories and some time spent understanding issues, what we thought about them before, and what we think about them now, sharpen the categories into Kits. Kits are a combination of priority and do-ability. It is taking the most important things that are do-able and putting those first.
It might mean that large important issues have to get done in stages to keep people happy. Yes, this is unfortunate when it happens, but it happens. Prepare kits that address the needs of your customers in chunks that your team can deal with. Some of the early iterations might be very short to get stuff moving, and hopefully get longer as more gets sorted out.
Launch
Use all your new data and learning to watch for ways in which the old thinking, the stuff that was shown to be really wrong in the postmortem, doesn’t creep back into people’s heads. If we’ve spent months oriented toward a set of design challenges, it might take more than one day to turn the ship. Sometimes major philosophies or design decisions are not the right path. It can take lots of daily work to rebuild the ship, while turning it and keeping it from sinking. Stick with it. If it doesn’t kill you it will make you better.
Repeat…
The key in all these processes is tying the feedback from the field back into the thinking of the team. That is really the most important part of managing software. You can’t do this with systems and scheduling and priorities. It is a human task. Processes work for sustaining software, but to build new stuff, you gotta really find ways to get dirty with the problems and opinions of one’s customers.
Postmortems focus a team on thinking like its customers. And that, at the end of the day, is all that matters. To study our own work, with an objective eye, from the viewpoint of the outside world, is the key ingredient in truly great software.