I have been fighting with a technical situation at one of my clients for the last couple of months. Because of decisions made, well before my time, about the architecture of the application I'm working on, we have no ability to provide full transactional protection to the data that we're saving to the database. After numerous meetings with architects from different areas of the company, I've been told that this is the way it is and there is no remedy in sight.
I was called a meeting again this past week to discuss issues around one set of specific transactions where we were seeing orphaned data being created in our testing environments. After looking through the business transactions and their fractional technical transactions, one of the solutions that was presented to me was that we should split the screens in the application so that they match the individual transactions instead of rolling all that functionality together into one screen.
I'm certainly not a professional Business Analyst, but I can't see how we, as technical people, can have the gall to dictate the screen flow and functionality to the end user. We are, after all, building this application for them. Even worse, how can we tell the users that their we can't accommodate their business needs when they see the same types of functionality in other applications? Not to stereotype the people that made these comments to me, but they were old school main frame folks and all admit readily that they don't have the first bit of knowledge about "...that new fangled Windows .NET development..." Again, running the risk of stereotyping, I think that dictating to the users is an approach that was used in the past. I also think that this is why we've historically seen a huge amount of animosity between clients and the technical teams. In the past few years the friction between the two has started to wear away, and, in my experiences, the two groups are working together with great results.
I have no problems with telling a client that their request is not doable with the time and financial constraints that they're placing on me. I can not, however, tell them that their requests have to be shelved due to what I know are surmountable technical issues.
Remember that your users primary goals usually are to get a product that works in a way that makes the most sense to their business flow and needs. Unless you worked in their department or industry for a number of years and have now moved over to the technical world, you have no business dictating to them what they should and shouldn't be able to do. We are, after all, problem solvers. It's the nature of our jobs. Embrace that fact instead of working within, and imposing, perceived restrictions.
posted @ Sunday, February 04, 2007 9:10 AM