The Best Way to Learn an IT System
Often as business analysts or product managers or project managers, we are thrown into projects when things are already running. Or even new projects can need us to understand the client’s existing system. And I am quite sure that you are no stranger to the kind of documentation or the lack of it, that we sometimes grapple with.
How does one then “learn” the system?
Even before that, let me state what I exactly mean by “learning” an IT system.
After “learning” the system you should be able to go from knowing NOTHING about the system to be able to do this,
You are comfortable with the behaviour of the system and understand the key functional areas
This article, of course, for folks who aren’t very much into tech. Even if you are a techie, this piece may give you a tip or two to “decode” a system.
Before I share my ideas, I wanted to share the story which inspired the ideas I am talking about.
This was back in 2018. I was thrown into an ongoing project for a UK based FinTech. My first assignment was to help the team integrate with an API. Things weren’t going very well for the engagement when I joined.
By “not well” I mean,
- The customer had been frustrated by past interactions with us (the vendor)
- The third party API vendors were hard to catch
- The documentation was non-existent
- The timelines were pressing
- There had been two analysts who were asked to leave the account before I stepped in.
Sounds like Christmas now, doesn’t it? :)
The only help I could received was the credentials to connect to the API via Postman. That’s it. No other documentation or ideas were available and the customer wouldn’t come on any calls with the team and had almost made their mind to take their business elsewhere.
Without anywhere to go, I opened Postman and started passing off the basic requests to the API. A few worked and a few didn’t, which was strange because as per the Swagger file, all those “basic” requests should have worked. I noted what I did, along with the results the API threw back. With each hour, I came up with new scenarios. The API had a few inputs of names, addresses and dates of birth and some configuration flags. I covered all possible permutations of those inputs. After that, I proceeded to include multiplicity. When the exact same data block was repeated in the request, it failed. Minor changes to the duplicate block made it work (like incrementing the ID to make every block unique). More than 4 blocks threw some errors. I noted that too.
While this happened, I also figured out how the front-end application worked. Here, I followed a different approach. I wanted to get to the end of the process as quickly and as “happily” as possible- to basically decode the happy path in the system. A few tries and a couple of calls with our QA later, I figured out how to get a user to the end of the process. Then, I started focussing on the screens that called upon the API.
Within a few days, I had mapped out a behaviour chart for the API in a plain spreadsheet format.
The front end also helped me narrow down and prioritise some of the cases in my spreadsheet. For example, even if the API allowed multiple blocks of names and addresses to be sent, the front-end hadn’t been allowing that. I noted that as a question for the product owner- whether we wanted to build it, as it certainly had value. But I decided not to ask it to the vendor immediately as we wouldn’t be able to send those requests anyway.
When I presented all this to the client over an email (the client wasn’t responding to ANY chats), I finally heard back! They liked the effort and decided to help me reach out to the API vendor. With their weight in the conversation, the vendor responded and I was able to schedule a call.
Months later, we had gone live with the integration and had started work on another front with the same API.
Now, the key takeaway that I want to mention here is just one. There is no list. Sorry.
Just one lousy, powerful line item-
TESTING
I find it the surefire-st way of decoding any system. Of course, I could just reveal it like that, but I don’t think it would have the impact without my story.
Testing is always beneficial, because it
- Shows us how the system actually works vs any collateral or marketing claim
- Prepares us to be able to do better customer demos
- Makes us aware about bugs and issues first hand
- Helps build empathy with the end user (like- how on earth are our users living with this??)
- Forces us to talk to various team members (which is VERY important in these Covid times)
- Gets us acquainted with the data and the constraints that the system works with
Hopefully, with the story and the above reasons, I have convinced you to test any system to learn it and derive so many more benefits!
