seem like an obvious question. Do you think it's part of every computer professional's job, what they're paid to do, to verify that these requirements are correct? And point them out at every possible stage? Is that a role that we all have to play?
Johanna: Well, I actually think it is. I know that when I was a developer, and people said to me, "I want you to do this thing," I always said, "Give me twenty seconds on why. Tell me the problem I'm trying to solve." Because if you understand the problem you're trying to solve, it makes understanding the requirements very clear, and then how you implement the requirements is even more clear. Most of the time, sometimes we think we don't have enough time to do that. I think we don't have enough time not to. But I think everyone involved in developing software or testing software needs to understand, where did this requirement come from? And who's going to benefit from this requirement? We have lots and lots of different users of our systems. There are the people who buy the systems, and they could be very sophisticated to very unsophisticated. There are people in our own companies, who we can think of as users of the system, whose lives will change because we've produced this system. And there are people who we don't want to use the system. Right? ATMs are based on the fact that everyone has a password, and if you don't have the password to go with the card, you're not supposed to be able to get in there. So there are people that we want to prevent from using the system. There are people who we want to use the system. And there are other people who are affected by the system in multiple ways. We need to know what does this requirement mean to all of them. It doesn't mean you spend twenty years on a Master's thesis to try and figure this out. But spending a couple of minutes on every new group of features, undertaking ten or fifteen minutes, or going back to the architect and saying, "Tell me why this thing goes here. Explain this to me." A little more understanding at the beginning can lead to a much more superior product, and something that gets done faster in the end.
Carol: So if you uncover, say, that a requirement is wrong, or doesn't look right, and you're not an analyst, and you're in the test stage, I think what you're saying is that it's important for people to point that out. And I can see some people saying, "Well, that's a bit of a danger. That might be stepping outside my job description." What are your thoughts on that?
Johanna: Well, it could be stepping outside your job description. But most of the time, the people in test are supposed to verify that the implementation of the requirements was correct. If they haven't… If they're not… If someone isn't verifying the requirements themselves are correct, you're missing a piece of some testing that needs to get done on that product. If you're concerned about the reaction that people are going to have to you when you say, "Why are we doing this thing?" or "This looks funny to me," there are a couple things you can do. One is, why does it look funny to you? Try and articulate that, in terms of what would it cost the customer to do this? Or I should say the user. Because sometimes our users are different
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
