Coding is not a big deal in any language but all it matters is a proper and thorough understanding of the existing system whether it is computer based or manual. It's not rocket science indeed. It's all about understanding user requirement. The main problem with coders is that whenever they got into studying about the requirements they immediately starts thinking about how they should be coding it. It's a very wrong way to think, because coding depends on requirements not the system depends on coding. If you have a proper understanding of the system requirements coding is not a big deal.
Another problem with developers is when they started thinking that their code can never be wrong, ok so is it!. So you should be siting above GOD, because even GOD's creation have a lots of flaws. Jokes apart never try to rectify users rather rectify yourself, learn from your mistakes. It's not important what user wants, it's important the problem they face with their job and the interface they work with. User can never always say what problem they face, circumstances of their problems may be fragmented, but you have to accumulate all their problems and their requirements to design the system . Remember it's not about how well you code but it's about how well you understand the system.
Let us take an example. Suppose user needs to upgrade employee salary periodically after every six months for a particular rate. Now he has to do this manually fetching every record one by one. Now automation is required. But there are some issues. Date for increment is not fixed but lies within a range. So you can create a notification asking user to run the update process within the date range and also give freedom to user about stopping the notification on his system and when he stop the notification an email might be send to him notifying that updation is not done. If it is a top priority even you can block any operation in the system on the last day of such updation until process is done. That is it does not only depends on users choice only but also to the whole system and it's job priority. Now the question is about if the rate of increment varies. Increment rate can be categorised into employee grade or group or designation and can also be employee wise for any special case. So you cannot be biased when designing the system. User will never conform itself for the system, system needs to be designed as such to understand the user. I hard many designers or coders that system is such so you need to follow it, it's totally wrong because what happens in that case that system is designed at the will of the designer but when problems are faced later on system need to be modified in AD-HOC method which turns it into a hotchpotch and it's slowly started becoming complex one, not in the sense of performance but in the sense of poor designing.
And last but not the least. Every system when designed needs a proper documentation. Why?. Does anyone guarantees that he or she will stay with the system for lifetime? no of course so proper knowledge transfer is necessary and that is possible with your documentation about the system. And in that case you should take help of a technical writer because it's not necessary that if you are good programmer you can be a good technical content writer. You can learn a whole lot of books about designing but all that matters is your real life interaction.
Another problem with developers is when they started thinking that their code can never be wrong, ok so is it!. So you should be siting above GOD, because even GOD's creation have a lots of flaws. Jokes apart never try to rectify users rather rectify yourself, learn from your mistakes. It's not important what user wants, it's important the problem they face with their job and the interface they work with. User can never always say what problem they face, circumstances of their problems may be fragmented, but you have to accumulate all their problems and their requirements to design the system . Remember it's not about how well you code but it's about how well you understand the system.
Let us take an example. Suppose user needs to upgrade employee salary periodically after every six months for a particular rate. Now he has to do this manually fetching every record one by one. Now automation is required. But there are some issues. Date for increment is not fixed but lies within a range. So you can create a notification asking user to run the update process within the date range and also give freedom to user about stopping the notification on his system and when he stop the notification an email might be send to him notifying that updation is not done. If it is a top priority even you can block any operation in the system on the last day of such updation until process is done. That is it does not only depends on users choice only but also to the whole system and it's job priority. Now the question is about if the rate of increment varies. Increment rate can be categorised into employee grade or group or designation and can also be employee wise for any special case. So you cannot be biased when designing the system. User will never conform itself for the system, system needs to be designed as such to understand the user. I hard many designers or coders that system is such so you need to follow it, it's totally wrong because what happens in that case that system is designed at the will of the designer but when problems are faced later on system need to be modified in AD-HOC method which turns it into a hotchpotch and it's slowly started becoming complex one, not in the sense of performance but in the sense of poor designing.
And last but not the least. Every system when designed needs a proper documentation. Why?. Does anyone guarantees that he or she will stay with the system for lifetime? no of course so proper knowledge transfer is necessary and that is possible with your documentation about the system. And in that case you should take help of a technical writer because it's not necessary that if you are good programmer you can be a good technical content writer. You can learn a whole lot of books about designing but all that matters is your real life interaction.
No comments:
Post a Comment