Sign up to save your podcasts
Or
Share MBA165: Remembering Jerry Weinberg
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
MBA165: Remembering Jerry Weinberg
Last week, the world lost a luminary. Jerry Weinberg passed away at the age of 84. Here are some of the most important lessons from Jerry in his own words.
After listening to this episode, you'll understand:
SHOW NOTES
Jerry Weinberg had a tremendous impact on our world. That includes his teaching, writing over 40 books and 400 articles, and helping to send a human into orbit around Earth.
Jerry joined us about a year ago in episode 130 where he talked about exploring requirements. Today’s episode includes some extras from our discussion and Jerry shares some of his thoughts about requirements.
The Reason for Requirements
Never forget that we use requirements to solve a problem, not to get people to write software code. The requirement is not to write a software program. The requirement is something that satisfies a person’s need.
Cautionary Tips from Jerry
We often don’t take requirements seriously until we feel the impact of a missed requirement. You must take requirements seriously or you’ll suffer the consequences.
When people say “don’t worry about that”, that’s the time to worry. Explore this further and ask why we shouldn’t worry about that. It often means that there are underlying assumptions that have not been validated.
Bringing Humanity to Requirements
Take the time to make sure you have the right people involved and you’re listening to them without bias. Learn to be a more accepting listener and learn to value the expertise of other people.
The requirements process is an iterative process. You can’t just get it right in one shot. It’s not something you do at the beginning of a project and then forget about it.
Set a reasonable goal and allow for testing and iteration. If you don’t test your requirements, there are going to be problems.
The requirements process is a first step in building a team. Let people interact in a way that leads to better team building.
Requirements for New Products
If you’re building requirements for something that’s entirely new, look for something that is like what you want but perhaps from another industry. To get it right, you’ll need to test.
Build things incrementally. You don’t need to create all your requirements up front. You do need to determine if the requirement is needed at all. Does the product satisfy a customer need?
From there, you can test using mockups or prototypes to ensure you’re on the right track. Remember that you’re building systems to satisfy people.
Start by honoring that people may not be able to tell you what they want, but they’ll know what they want (or don’t want) when they see it. You need to give them something to react to.
Watch the Detail
The top level of requirements is “what is it that the customer is really trying to do?” The problem is, we often work at the wrong level of detail.
We need to be able to speak less precisely at the beginning of the process. As we progressed through iterations, we can get more detailed as we test and learn.
When we define solutions in much detail, we take away the creativity of software engineers and those developing the solution.
Be sure to honor both sides of the equation. Customers at some level know what they want and know what they don’t want. Engineers and solution developers know how to create the solution for the customer’s problem.
Listing to this episode to get Jerry’s advice on taking requirements seriously, iterative development, when to get into detail, and treating people with humanity.
http://traffic.libsyn.com/masteringbusinessanalysis/MBA165.mp3
Links for this episode:
Jerry Weinberg
Author, Teacher, Consultant, Luminary
For more than half a century, Jerry Weinberg has worked on transforming software organizations, particularly emphasizing the interaction of technical and human issues. After spending between 1956 and 1969 as software developer, researcher, teacher, and designer of software curricula at IBM, formed the consulting firm of Weinberg & Weinberg to help software engineering organizations manage the change process in a more fully human way.
Jerry has published more than 40 books and more than 400 articles including books on quality software management, systems thinking, and requirements.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
.
The post MBA165: Remembering Jerry Weinberg appeared first on Mastering Business Analysis.
View all episodes
By Dave Saboe, CBAP, PMP, CSM | Certified Business Analysis Professional | Agile Coach
4.7
8282 ratings
Last week, the world lost a luminary. Jerry Weinberg passed away at the age of 84. Here are some of the most important lessons from Jerry in his own words.
After listening to this episode, you'll understand:
SHOW NOTES
Jerry Weinberg had a tremendous impact on our world. That includes his teaching, writing over 40 books and 400 articles, and helping to send a human into orbit around Earth.
Jerry joined us about a year ago in episode 130 where he talked about exploring requirements. Today’s episode includes some extras from our discussion and Jerry shares some of his thoughts about requirements.
The Reason for Requirements
Never forget that we use requirements to solve a problem, not to get people to write software code. The requirement is not to write a software program. The requirement is something that satisfies a person’s need.
Cautionary Tips from Jerry
We often don’t take requirements seriously until we feel the impact of a missed requirement. You must take requirements seriously or you’ll suffer the consequences.
When people say “don’t worry about that”, that’s the time to worry. Explore this further and ask why we shouldn’t worry about that. It often means that there are underlying assumptions that have not been validated.
Bringing Humanity to Requirements
Take the time to make sure you have the right people involved and you’re listening to them without bias. Learn to be a more accepting listener and learn to value the expertise of other people.
The requirements process is an iterative process. You can’t just get it right in one shot. It’s not something you do at the beginning of a project and then forget about it.
Set a reasonable goal and allow for testing and iteration. If you don’t test your requirements, there are going to be problems.
The requirements process is a first step in building a team. Let people interact in a way that leads to better team building.
Requirements for New Products
If you’re building requirements for something that’s entirely new, look for something that is like what you want but perhaps from another industry. To get it right, you’ll need to test.
Build things incrementally. You don’t need to create all your requirements up front. You do need to determine if the requirement is needed at all. Does the product satisfy a customer need?
From there, you can test using mockups or prototypes to ensure you’re on the right track. Remember that you’re building systems to satisfy people.
Start by honoring that people may not be able to tell you what they want, but they’ll know what they want (or don’t want) when they see it. You need to give them something to react to.
Watch the Detail
The top level of requirements is “what is it that the customer is really trying to do?” The problem is, we often work at the wrong level of detail.
We need to be able to speak less precisely at the beginning of the process. As we progressed through iterations, we can get more detailed as we test and learn.
When we define solutions in much detail, we take away the creativity of software engineers and those developing the solution.
Be sure to honor both sides of the equation. Customers at some level know what they want and know what they don’t want. Engineers and solution developers know how to create the solution for the customer’s problem.
Listing to this episode to get Jerry’s advice on taking requirements seriously, iterative development, when to get into detail, and treating people with humanity.
http://traffic.libsyn.com/masteringbusinessanalysis/MBA165.mp3
Links for this episode:
Jerry Weinberg
Author, Teacher, Consultant, Luminary
For more than half a century, Jerry Weinberg has worked on transforming software organizations, particularly emphasizing the interaction of technical and human issues. After spending between 1956 and 1969 as software developer, researcher, teacher, and designer of software curricula at IBM, formed the consulting firm of Weinberg & Weinberg to help software engineering organizations manage the change process in a more fully human way.
Jerry has published more than 40 books and more than 400 articles including books on quality software management, systems thinking, and requirements.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
.
The post MBA165: Remembering Jerry Weinberg appeared first on Mastering Business Analysis.
More shows like Mastering Business Analysis
View all
Freakonomics Radio
32,246 Listeners
The Ben Shapiro Show
153,989 Listeners
The Economics of Everyday Things
1,643 Listeners
Business Analysis Simplified
0 Listeners