We tend to fall into the same traps over time, not matter how much we try. When I was a consultant, it was very easy to correct a client who demanded technical solutions instead of listing their business objectives. It was my job to re translate that back into "what is the real requirement here".
Now I've been working for an architect at a single company for two years, I find myself falling into the traps that I used to help others avoid. In designing a new profile service a group of three architects, plus other contributors discussed the proposed structure. We went over all the technical implications, and we felt we understood what the business need was quite well thank you, including what would need to be in an MVP, and what could be deferred to later.
Four months on and I find myself in a very enlightening meeting with key business users, who have a far better understanding of what they need than I did, despite having "done my research". I find that several of the decisions I made, while valid in their way, just didn't go far enough to addressing the business need.
It is a timely reminder that the developer (no matter how well in tune with the business he believes himself to be) is ultimately far more focused on a technical challenge and "elegant solutions" than he is with what the end consumers want.
Lesson Learned: If you think you have a solution to the business problem, ask yourself "have I sat in a room for an hour with four business user who have no interest in how it is done, but only what it lets them do?"
No comments:
Post a Comment