I have been working as a "systems analyst" for over 10 years. During this time, I have participated in many software development projects. I got involved in the work at different stages: both from scratch and at the stage of implementation, or configuration for the needs of the customer. I was lucky to observe the work of large and small teams, as well as participate in several start-up projects. But from project to project, I faced the same problem - my job responsibilities were incomprehensible to people. Moreover, they were incomprehensible not only to the customer of the project, but also to the executor, i.e. to my own team! At some point, I realized that I have to constantly explain who I am. Remind me that I am a "systems analyst", tell me what my responsibilities are, that I am not a "business analyst", "marketer", "developer", or anyone else. You say, that it is good to be a generalist. Perhaps. But when high-quality performance is demanded of your work, you start to think about pumping your abilities in only one direction, and not at once on all fronts of a wide profile desktop support jobs.
One of the last projects showed me that the customer took the "analyst" into the team only because it was "necessary". He did not understand what the analyst was actually doing and how he was useful to a particular project. As a result, each of the participants called my role on the project differently, and put something of their own in the role of “analyst”, close and understandable for a specialist in his field. This situation was the reason for me to create this article. At the same time, I will try to classify the analysts that can be found in the IT environment. This classification does not pretend to be a standard, but describes frequently occurring phenomena in this area. I hope my research will be useful to you and will help you understand who analysts are and what they are.
No comments:
Post a Comment