- Tram Ho
In the software programming world, programmers have a lofty task of solving problems for users. Users will raise their problems and needs, from which programming will seek to handle it. Simply there is such!
If you have never seen software that is both complex and useless, try finding software that the programmers cram all solutions into software for users. To be fair, users are people who understand what the problem is and sometimes they also have solutions to those problems. However the person who raised the final problem is always a programmer and a product maker, not a user.
This problem can get worse if you write software for a small group, especially within the company. These people often have more authority than you, they are the ones who work at executives or higher levels. They have the authority to “order” you to do anything. However, if they want the best solution, they should follow what I said here. Try to think that if we trust enough to give to someone to make a product, we should somehow believe in their decisions. If you don’t believe it, you shouldn’t work together from the beginning. A group of people who don’t trust each other often pull in ineffective groups, but sometimes they shouldn’t be called “groups”.
If the user wants to dominate the programmer’s decision, it is best if they “hit the cards” and hand over the data to the programmer. Because developers need those specific data to make better decisions, of course, that information is also a necessary bridge for end users. If you are a user and you think the software is going astray, give the information you need to help them solve the problem for you quickly. If giving numbers, even inside stories, helps programmers have more clues to navigating product development. Explain to them clearly, why the software is currently inappropriate. Identify how many people are suffering from this problem. Here I would like to emphasize that data is very important in the software development process and how the product maker makes solutions.
On the other hand, programmers are people who have their own problems. As mentioned above, one of the developers’ common errors is trying to create a software that has too many features to solve the entire needs of all user categories. People who make products are sometimes users, they will also see problems that others have. That’s okay, they can rely on data and users’ perspective to offer the best experience solutions. Moreover, programmers often suffer from “illness” that overestimates their opinions compared to the majority of users (the reason is because they often hear feedback from different sources and work with software today. month after month) Remember that those comments come from a group of users.
If you’re looking for a way to solve a programmer-oriented problem rather than a user-oriented approach, you’re spending too much effort and not really helping anyone. Try to see when the whole team works on one person’s idea, but then people will feel “stuck” after release of the product because the users out there cannot use it. And moreover, I often find that when trying to solve the programmer’s problems, the software will go in a much more complicated direction. So try to find out what the user needs and solve the problem right away.
I believe that no developer can offer a solution as well as a perfect solution, and so do users. However, both parties need compromise and understanding of each other. To be fair, only users understand what the problem in their product experience is, and only the developer can make the right decisions after understanding the needs of people. What do you want? Having a great combination from both sides, the software will be developed in the most perfect way.
ITZone via Codesimplicity
Source : Code Simplicity