LinkedIn | FaceBook | Twitter
Back when I worked in the User Education group as a content developer, I wrote an entry in this blog that described how we put documentation and other information together for SQL Server. I thought I would follow that up now that I’m in a new group and explain where the basic thoughts come from for the design of SQL Server features. I’ll describe how we actually put it together in a future entry.
So how do we come up with the features and designs we put into SQL Server? Microsoft has often been accused (unjustly, I think) of not listening to its customers, and dictating to others what we think they should do. In the SQL Server organization, I haven’t found this to be true.
We’re in the final stages of adding all of the feature sets, and since I’ve just joined the group, I won’t have a lot of say in this release. But as I’m learning, the process starts with user requests.
Basically we cull information from a lot of sources – the SQL Server “Connect” site, user surveys, user studies, and direct feedback. We even troll newsgroups and blogs to see what you’re saying. There are literally dozens of formal and informal methods we use to find out what you’re thinking.
We also get information from the “field” – those Microsoft employees who do consulting, troubleshooting, and the folks on the customer support front lines. I just attended a mandatory meeting the other day where the support folks grilled us for a few hours on the issues they see you deal with daily.
Then there are the internal sources. This includes marketing, management, and of course our own teams. We have an impressive set of experience in our Program Managers (that’s the position I hold) as well as our developers and testers. Most of us have experience in large and small companies, and most everyone is a database professional in other products as well.
All this information gets put into two camps: Issues and New Features.
Issues are things like bugs or other unexpected behavior. These are sorted into a Severity (How many people or situations this affects) and Priority (How much it affects them). Bugs that are ranked high on this list are dealt with first as resources permit. Along the way we can have an issue that has a big impact on a lot of situations. We have to stop everything to work on those first, no matter what. So some issues are dealt with in the released version of the product, others that aren’t deemed as critical are fixed in the next release. This is pretty common in most software development shops.
The New Features bucket is where the fun really starts. We take all the feedback, with the customer’s input at the top of the list. We group the things that have been asked for the most, and voted as important by the users the most. We then fold in what the marketing people tell us they need, toss in our own ideas, and then everyone argues for what we think the best solution is for the customer.
Of course every decision has consequences. Deciding to do one thing takes time and resources away from another. So while an idea might have merit – might be the best thing ever from a certain perspective – choosing to fix an issue might take the developer and testing, documentation and all of the other resources away from that cool new thing. And believe me, it hurts no one more than the Program Manager when his or her feature is cut. Every one of us thinks we know what would make your day better (hey, I was a DBA for decades) but time and resources dictate what we do, and when we do it. This is also a common dilemma to most software development shops. But I will say this: I’ve worked in a lot of software development shops, and this one takes customers seriously. We start and end with you.
Are we perfect? Do we always make the right decisions? Of course not. And one size does not fit all. In fact, when we add features, we make things more complicated. But if we make it simpler, it isn’t as powerful. There’s always the dance of getting it right.
So if you’ve suggested something to the team and it doesn’t make it into the next release, don’t lose heart. We really are listening!
Carpe Datum : How do we create software at Microsoft?
E' una lettura di un paio di minuti ma che fa capire che, tutto sommato, i feedback dei clienti vengono