Berkun reading group discussion
MakingThingsHappen
>
Chapter 3: Discussion and Questions
date
newest »
newest »
message 1:
by
Scott
(new)
Mar 14, 2015 04:19PM
Mod
reply
|
flag
I agree with the Fred Brooks quote "...The most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements"The most dysfunctional item that I've found in the planning process is the inability for teams to write good enough requirements. Unfortunately, usability engineers, product engineers, and BA's tend to be missing from my projects.
About 10 years ago, I worked on the most fulfilling project in my career. We built a trading application from the ground up and worked with a quality group of BA's, usability engineers, and a terrific project manager. They were able to ensure that the three perspectives were taken into account when writing requirements. I was most impressed with the usability engineer. She would produce wireframes of the requirements/features discussed in our meetings and even helped with some of our engineering mock-ups. Throughout the project, she must have drawn hundreds of pictures on napkins, white boards, notebooks, and even one on my hand ( at a bar drinking a beer with no paper).
The project manager ensured that everyone's voice was heard and that all meetings had a measure of success with actionable items. He did hundreds of "little things" that lead us to project success. I was impressed with his ability to delegate authority to BA's, Engineering Staff, and the business. The project manager was granted budget and requirements authority which is something that I've never seen again. Most of the patterns Scott described for requirements gathering was done on that project.
I agree with Scott's premise that balancing of the three perspectives is critical in a project. I tend to favor the engineering perspective and it's a flaw that I'm aware of. My key takeaway from this chapter is 1:1:1 (engineering to business to customer ). This will serve as a constant reminder to not let my bias and ego get in the way when producing product requirements.
My only criticism for this chapter is that I wished Scott spent more time on the value that a usability engineer can provide during the requirements and specification stage in a project. Most organizations don't understand the value of a usability engineer until they see one in action.
One of the great articles that I've read in recent years was released by Gartner - Pace Layer Model - http://www.financialexecutives.org/Ke... The mistake that most teams make is to use a one size fits all methodology for projects. The Gartner article provides another concrete example of how to approach this problem.
Excerpt from article - I was able to remember this article after Scott provided the project examples (solo-superman, small contract team, and big staff team)
The notion of pace layers comes from the realm of buildings and architecture. The idea was to design buildings that would adapt and be useful for different purposes over a long span of time (hundreds of years) without major disruption. For business applications, pace laying means creating an application strategy that can adapt and be useful for changing business needs over time.
Mod
I'll check out that article.
The quote in this chapter from Abraham Lincoln warms my PM heart: “If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,” which implies that smart preparation minimizes work. I agree that PMs are the intersection of business, tech, and user needs - in fact, that’s what I like about the role so much, and always keep in mind as the unique value a PM can provide. I am looking forward to using some of the planning questions in this chapter, the examples are super helpful.
As far as the planning meetings, has anyone found effective ways to collaborate in planning meetings online? Either to include remote team members, for introverted team members who can tend to be quiet, or just simply to reduce the amount of time spent in meetings.
I’m sure we’ve all seen the growing discipline of UX, which I believe will continue to become more integral and defined, and I think this chapter could be updated to include some of the new roles and tools that teams have to identify user needs and problems. I don't think it qualifies as a trendy fad, since it really is a focus on solving user problems and providing something they will value.
Many of the projects I’ve worked on lately have tried to incorporate some agile principles into waterfall processes, so much so that I tend to get a bit fuzzy on the terminology. I was going to ask about the problem statements and use cases, and how those relate to user stories and scenarios, but I found a handy blog post from Alistair Cockburn, who is referenced in this chapter http://alistair.cockburn.us/Stop+conf.... If there are updates to this book, it may be helpful to include some clarification around the different terms, as agile becomes more popular.
Mod
The terminology in this chapter could use updates, but I don't think it's hard to translate (of course I'm biased :)
I love that chap 3 revolves around, and continues to come back to, the customer perspective. The "magical interdisciplinary view" (p. 54) is really great as a framework/mindset for keeping the customer perspective from being the weakest. Does anyone have a good method for quickly and visually identifying how the three perspectives overlap in a specific project? In other words, given all the answers from the questions on the three perspectives, where are the high-value intersections?
Perhaps my favorite ah-ha in this chapter (p. 59): "Technological progress is overestimated in the short term, underestimated in the long term."
P.S. Sorry if the page #s don't apply to the ebook or previous eds.
Just finished Chapter 3. I love the planning process but this gave me a few things to think about in my next big project. I've noticed I tend to the engineering and customs design perspective. And there have been times when I've said "that's stupid don't use this product for that" rather than delving into the WHY of why the customer was using it that way. Clearly I need to gather more customer feedback earlier in the process.Some of the specific examples "RSS 4.0" haven't aged well, but that's really to be expected when technology is specifically mentioned.
I had conflicting thoughts about this chapter. The interdisciplinary view is something that I agree with fully but I've found that going too heavy on planning deliverables and documents can actually get in the way of keeping that view. It's a lot harder for the team to discuss and debate things that are already locked down into a paper document so I try to keep the discussion alive and on whiteboards as long as possible. At some point you do need to document things but I've often found that keeping it more to the vision level gives all around better engagement and results.
The balance of power ratio is a nice method of seeing the natural tendencies of a team and prepare for the biases that might come from that.
Mod
The balance of power in most organizations is heavily shifted one way or another and the people with the most power are the least likely to notice.
Mod
Scott wrote: "Kevin: I've seen teams use Google Docs and Wiki's for similar reasons, in that if everyone can edit it it's still alive in a way a "document" is not."Great suggestion Scott! The comments feature in Google Docs is particularly powerful and allows a lot of discussion to happen so that a doc feel more alive.
Ravi wrote: "Throughout the project, she must have drawn hundreds of pictures on napkins, white boards, notebooks, and even one on my hand ( at a bar drinking a beer with no paper)"This was beautiful and I have just shared it with my favourite UX colleague.
Mod
Eleonora and Scott:I've gone back to sketching by hand and scanning the results back to our project knowledge base. I've noticed that I can enter a "state of flow" easier by hand drawing then using some tool like PowerPoint or Visio.
