- Good project management
- Good requirements gathering
- Good translation of user requirements to software requirements and design
I have been through it all, but it seems that most of the time, 2 and 3 seems to be lacking in focus. In fact, most of the time, I keep hearing comments that it's of no use doing 2 and 3 properly because requirements always change.
I beg to disagree... I have done at least 1 project that points 2 and 3 did not change after design specs are signed off. In fact, in all the projects that I have done, only 1 project has that dubious honor of ever changing requirements, even after the system is launched. Granted it was done very early in my career but still, once is enough. The key point is the process for points 2 and 3.
To me, this area is where a software architect comes in. A person who can understand the business processes and requirements, and transform it into software requirements that suit the business needs. I like that translation process, although it is very tiring.
Recently I have been reading up on my own on the 4 big areas of software architecting which I felt is important in any organisation:
- Business architecting
- Data architecting
- Application architecting
- Technology architecting
This is where you look at all the IT solutions in a macro view, most often in an organisation view. How different systems will talk to each other to fulfil one common goal, the business processes.
I believe in looking at the solutions from both the micro and macro view. As a result, some people say that I plan for too many contingencies. However if I see a problem, I will nib it at the bud before it happens. This is my style... I can't help doing it.
Now then comes the problem... It seems to me that at least in Singapore, there are few who believes in this type of architecting. I have tried to look for jobs with regards to this area but it seems that I might not be looking hard enough. In fact, I've only found one job description that is similar to what I'm interested in, but to-date, I have not received any reply.
People do comment to me that I have a knack of doing this kind of solutioning. Is it that I'm not ready for this type of solutioning, or organisations are not ready to walk down this path of looking at IT in a different manner? Such jobs seem to be very rare, at least from what I can see from the jobs listing.
Sometimes I wonder if I'm in wrong era or something... Or am I in the wrong country?
8 comments:
Why little emphasis? Don't know, maybe people are lazy/ignorant/can't be bothered.
There is a need to do 2 and 3 properly, but not completely. Those who say requirements always change are correct; but that is not a reason not to do 2 and 3 properly.
The only constant in life is change. User requirements change 'coz it's a fact of life. Users whose requirements do not change either work with a very specific focus or are living in a placebo world.
The key issues are (a) not to brush off doing 2 and 3, and (b) not to assume (or demand) that 2 and 3 will not change.
A good software design actively caters to and for changes, as it recognizes things do change/people do change. Software being layered as frontend-middleware-backend allows changes to be isolated to specific layers --- GUI will change frequently as users discover new/more efficient ways of navigating the system. DB schema would be relatively static.
Ideally, changes should be effected across different software versions. Many projects make the mistake of lumping ver 1,2,3,... altogether, resulting in a never ending project. That, however, is a business issue. It does not equate to software being constant.
Hello! It is me!!
I agreed with your thinking and I think that most IT companies just wanna make the money and go.
No one bothers about the stages you've mentioned.
As a programmer, the stages are so important. Else our life will not be good already...
If only somebody can take the programmers' ideas SERIOUSLY.
Hi Anonymous,
I agree with you that changes are common. In fact, changes are good because that means companies have more businesses. A good software design always cater for scalability, that follows the direction of the product. No use trying to scale a software that is not meant to be used in that way.
However, the key point comes in when is the right time to change. What kind of change? Does it affect the project scope? Timeline?
Even in terms of product development, this is important. A project that sees no end is always bad for morale. Worse still if the requirements keep changing.
User requirements will always change, but it should be managed and prioritized. Many do not do that.
However good the software design is, it will never be good enough if the users are not sure what they want. Worst if you have a group of users doing different functions on the same software.
Hi Rin,
Hope everything is okay with you. Sometimes, it's not about IT companies just wanting to make money and go.
There are a variety of factors involved when you're in a project, especially if you're on the side of the vendor. Somethings are beyond your control.
No matter how well you try to architect the solution, it's of no use if the users refuse to confirm their requirements, and keep changing it even in the design stage.
The problem is that a lot of people do not know that a good software needs to be architected properly, and that means the requirements must be confirmed at least for that phase in order for the design to start off properly. You can't just add things in like that halfway through the project.
That's the problem most face, and that is why IT projects have such a high failure rate.
Hi Little Corner, the main problem is the software developer is trying to get the users to tell him what they want...
If you study human/user psychology, you will find that this is a failing proposition: because users have (absolutely) *no idea* what they want!
History has statistically shown that successful products are a result of an innovator's ideas and hard work, and *not* from users contribution. If Henry Ford had to ask his users what they want, they'd likely say they want a faster horse!
90% of the users are good at refinement, not innovation. Once they see version 1 of a software, they can tell you all the things that are wrong with it (after all, humans are adept at criticizing) and how to improve on it (constructive criticism, hopefully). This is fine and productive. But to ask them how version 1 of a software should be is venturing into the infinite loop of a never ending story...
So your final para "if the users are not sure what they want" should read be "the users certainly don't know what they want".
Hi Anonymous, it seems to me that you're looking at it from a product point of view.
I do agree with you that going from the psychological point of view, most users do not know what they want. To date, I've seen few users who are certain of what they need and want. Some do not differentiate at all between needs and wants.
However, looking at it from the solution and services point of view, it does make a lot of difference because the solution is really from the users' requirements.
There is really no choice in the matter as the project is bounded by it. Software developers in this case, do not ask the users what they want. This is suppose to be determined by the project team, bounded by the project scope. This is where (1), (2) and (3) comes in. Software developers only look at the end deliverable of (3), or maybe involved in the process at (2).
It's really a dilemma. The project scope is bounded by users who do not know what they want.
That's why there is a particular point I admire about Steve Jobs. He dares to build something different based on his idea, stick to it, selectively listens to the feedback, and through the product convince people that it's worth the price.
Over in the solutions and services world, we need someone like that too.
I guess the users are too fickle minded.
When we first ask them what they want: they can say they don't know, so as SA design and propose to them. They nodded their head.
Once things got kick off, then the users wanna this wanna that.
They should be a firm thingy like: All changes are to be done later, at the next enhancement or so.
Having a little change, can simply affects the whole structure to the systems.
We need to tell those folks. They dun understand what SW and SA should doing.
We are not the cha kway tio man, customer wanna add an egg, we just add....
WE are not like that..
I'm fine anyway!! THanks !! :)
first provider of products and presentations that the market is hungry.
Post a Comment