How can I improve my requirement analyst skill?

Question

I have been working as a software developer for ten years now. I was happy working in my past company for four years, but the dark side is that I had three projects dead at the very end of the job because the user reported that they were happy with the old system and didn't like the new system, which imposes more restrictions and has an inferior UI...

Then I moved to a new company but was fired after two months because they complained that I had just directly copied the logic from the old system being migrated, without studying the physical mechanism, and the meaning of the program, behind it.

After three months of unemployment, I have found a new job and I really fear to repeat those mistakes. Therefore, I am asking for suggestions and books that can help improve my problem analyst skills.

Answer 1

No matter the role, to improve you need to practice. You need to pick up the books on a routine basis and study not only new stuff but to restudy the old stuff. You need to practice by doing. You need to do your own personal lessons learned when both you had some success as well as set backs and, most importantly, learn from those lessons. You need to seek out counsel, both on a case by case basis as well as with an established mentor. And maybe most importantly, you need to be persistent. Persistence wins.

Failure is a great teacher. But when that happens, you need to truly analyze the drivers that disabled success so you can figure out a new way of doing it next time around. We have a tendency of insulating ourselves when we fail by attributing the cause externally. When we succeed, we attribute the success internally, of course. That's a bias called misattribution error. So if you really want to learn and improve as a practitioner, check that bias at the door.

Stay positive and be persistent and don't be afraid to blame yourself so you can learn from it.

Answer 2

Documenting the system requirements before it is built can help the key stakeholders buy-in.

A user representative should sign-off at each stage before software is crafted. A system requirements review and system design review: each ending with signoff from the user representative will ensure the the users are engaged and invested: they MUST have 'skin in the game'.

If the project does not have a strong executive sponsor that will champion the new UI, Logic, I would cancel the project