3 ms·
Yes and it can go especially poorly when you have a "problem oriented" person on the team: 1. Manager proposes low quality requirements 2. Problem oriented te
by skohan 6y ago
Yes and it can go especially poorly when you have a "problem oriented" person on the team:
1. Manager proposes low quality requirements
2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization
3. Endless discussion around this one detail
4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal
OR
4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline
- tomlagier 6y agoOof. The number of 4b's I've had to deal with in my career... What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.
- skohan 6y agoA couple approaches I have seen which can be effective are: - Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B" - Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C." With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.
- slt2021 6y agolittle bit of caution on "Yes we can do A, but that means we won't have the time/resources to do B" - this, along with Agile method of squeezing work every two weeks will lead to simply mediocre quality hacked together deliverables and accumulation of technical debt. Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable
- datavirtue 6y agoSounds like the text book description of how to start wrecking a software project.
- nullsense 6y ago4b... Sums up the last 12 months of what should have been a 3 month project.