The path of the analyst. Bug work
I want to share with you a true story about the beginning of the formation of me as an analyst. I hope the information and conclusions will be useful to novice systems analysts, business analysts.
It was 2006. My journey as a system analyst began in a very large company with a well-established development life cycle.
Analysts, project managers, programmers, testers, architects have worked in the company for more than one year. Long before my appearance in the team, the company approved the format for the specification of requirements, convenient for all, familiar and understandable.
They told me: do this, and there will be happiness for everyone. And so it was ... before the release of the first serious project. It was there that it turned out that simply following the pattern correctly, and then agreeing the document with the necessary list of persons is not enough.
And I found out this already after half a year of work as an analyst.
')
What did I do for half a year, you ask?
I was assigned a description of small changes about which one way or another everyone was aware of even before my arrival at the company. Experts knew what to do; future projects have been repeatedly discussed earlier. A specification of requirements was rather a “piece of paper” for collecting signatures. The signed document served as a flick: “you can start, people are allocated, the budget was approved and the project started” (I understand that now, but not then!).
My responsibilities also included the description of standard tasks (configuration or minor, simple changes in the system). Such requirements were also understood by everyone. In general, the document was a reminder of what needs to be done, but no one really read it.
And after half a year I was assigned a difficult task. At the beginning of the project, I, as usual, met several times with a customer representative, we discussed the necessary changes, I described them, agreed with everyone. Having received the necessary set of signatures on the title page, I was very pleased with the work done, gave the document to the manager and safely went on vacation. “My work in this project has been completed,” I thought naively, drawing on the experience of previous minor tasks.
This is where the fun began. At the depth of the level of detail I described, everything was clear to everyone. All put their signatures on the document. And put in the work of programmers and testers. When it came to testing, I had long since returned from vacation and was engaged in the next task, for which I was allocated 100%. And testers began to come to me with questions (for the first time in my life!). They found differences between requirements and implementation (like a surprise!).
In general, the same text was interpreted differently: by me, by programmers and testers. Thank you, even though my vision coincided with customers. Then we together defended the right option. It was described in such a way that, by digging a little deeper,every specialist who was unfamiliar with the company's processes could find something that was more convenient / clearer for him. I was shocked. But she quickly recovered, “wound this situation around the mustache” and worked on the bugs.
2.1. Quality specifications: requirements were not specific enough. A general idea was described, with a few ways to implement it. And the specific option was important to the customer. Accordingly, it was necessary either to describe the required solution in great detail, or to meet with the team every day at the design and implementation stage, tell what is required, look at what happens. Given the business processes of the company, and even the upcoming vacation, the first option would suit me.
2.2. The participation of the analyst in the life of the project : I participated only in the initial phases of the product life cycle. And an analyst is needed at all stages:
a) during the discussion phase of a business idea, the analyst may suggest:
- whether the implementation is possible,
- methods and cost of implementation.
b) the analysis and design phase: well, that is clear;
c) development and testing phase: answer questions from programmers and testers, actively participate in discussions. Test, verify the implementation of the main functionality. View test cases or prompt testers with "tricky" moments to check. There are always such nuances that only an analyst holds in his head, and no one comes to mind to check them out :)
d) commissioning and use of the product: the analyst often knows the product best of all and can take part in the preparation of product presentations.
If questions or comments arise during operation, the analyst agrees and writes requirements for changes, if necessary.
2.3. Document approval : practice has shown that a signature on a document (document approval) does not always mean an understanding of the requirements to be signed. It is better to once again meet (at least in Skype) with those on whom something depends and for whom the results of the project are important, make a presentation and discuss key requirements, if there is such an opportunity. Make sure you're on the same wavelength.
And another point that I want to note now, but then did not think about it.
2.4. Taking into account the level of the team and the specifics of the project: the new ones in this company were engaged in this unfortunate project
developers and testers. If it were not for this nuance, then perhaps everything would go well for the project in question, even without the preceding paragraphs.
Moral: the method of collecting and describing requirements, as well as the project implementation model, depends on the specific project. What to consider:
- command level;
- team immersion in the project;
- team harmony;
- type of tasks (something standard for this team, configuration, or a complex, unique project);
- project budget and deadlines;
- much more.
But this thought did not come to me immediately, and for some time I was looking for my ideal specification.
3.1. I read a lot: Vigers, Leffingwell, Coburn, etc. went into action. I considered examples of specifications, tried to get the maximum of useful and suitable, and immediately used it in my work.
3.2. She organized timely feedback from testers and programmers in the early stages of the project :
The project manager was surprised when I asked to select a tester to view the specification, but I was going to meet it. After all, there are such questions that come only to testers! And well, when they are considered on time.
3.3. I gathered together some of the customer representatives, programmers, testers, project managers before launching the project: at such a meeting we were convinced that we understood each other correctly, reminded important details, etc.
After a short period of time, programmers began to note progress and thank for the specifications.
And then I realized that I had stalled at some level and I want to move on. I got an obsession: find out how other companies write specifications, and learn something new for themselves. There were forums, a community of analysts. I read “like others,” considered examples, initiated meetings and asked questions.
Separately, I want to note that the world is not without good people, and unfamiliar, but experienced analysts have never refused me to meet and answer questions. Thank you, dear colleagues. Therefore, "seek and find, knock, and they will open it to you."
To be continued…
1. Background
It was 2006. My journey as a system analyst began in a very large company with a well-established development life cycle.
Analysts, project managers, programmers, testers, architects have worked in the company for more than one year. Long before my appearance in the team, the company approved the format for the specification of requirements, convenient for all, familiar and understandable.
They told me: do this, and there will be happiness for everyone. And so it was ... before the release of the first serious project. It was there that it turned out that simply following the pattern correctly, and then agreeing the document with the necessary list of persons is not enough.
And I found out this already after half a year of work as an analyst.
')
What did I do for half a year, you ask?
I was assigned a description of small changes about which one way or another everyone was aware of even before my arrival at the company. Experts knew what to do; future projects have been repeatedly discussed earlier. A specification of requirements was rather a “piece of paper” for collecting signatures. The signed document served as a flick: “you can start, people are allocated, the budget was approved and the project started” (I understand that now, but not then!).
My responsibilities also included the description of standard tasks (configuration or minor, simple changes in the system). Such requirements were also understood by everyone. In general, the document was a reminder of what needs to be done, but no one really read it.
And after half a year I was assigned a difficult task. At the beginning of the project, I, as usual, met several times with a customer representative, we discussed the necessary changes, I described them, agreed with everyone. Having received the necessary set of signatures on the title page, I was very pleased with the work done, gave the document to the manager and safely went on vacation. “My work in this project has been completed,” I thought naively, drawing on the experience of previous minor tasks.
This is where the fun began. At the depth of the level of detail I described, everything was clear to everyone. All put their signatures on the document. And put in the work of programmers and testers. When it came to testing, I had long since returned from vacation and was engaged in the next task, for which I was allocated 100%. And testers began to come to me with questions (for the first time in my life!). They found differences between requirements and implementation (like a surprise!).
In general, the same text was interpreted differently: by me, by programmers and testers. Thank you, even though my vision coincided with customers. Then we together defended the right option. It was described in such a way that, by digging a little deeper,
2. What then I identified problem areas
2.1. Quality specifications: requirements were not specific enough. A general idea was described, with a few ways to implement it. And the specific option was important to the customer. Accordingly, it was necessary either to describe the required solution in great detail, or to meet with the team every day at the design and implementation stage, tell what is required, look at what happens. Given the business processes of the company, and even the upcoming vacation, the first option would suit me.
2.2. The participation of the analyst in the life of the project : I participated only in the initial phases of the product life cycle. And an analyst is needed at all stages:
a) during the discussion phase of a business idea, the analyst may suggest:
- whether the implementation is possible,
- methods and cost of implementation.
b) the analysis and design phase: well, that is clear;
c) development and testing phase: answer questions from programmers and testers, actively participate in discussions. Test, verify the implementation of the main functionality. View test cases or prompt testers with "tricky" moments to check. There are always such nuances that only an analyst holds in his head, and no one comes to mind to check them out :)
d) commissioning and use of the product: the analyst often knows the product best of all and can take part in the preparation of product presentations.
If questions or comments arise during operation, the analyst agrees and writes requirements for changes, if necessary.
2.3. Document approval : practice has shown that a signature on a document (document approval) does not always mean an understanding of the requirements to be signed. It is better to once again meet (at least in Skype) with those on whom something depends and for whom the results of the project are important, make a presentation and discuss key requirements, if there is such an opportunity. Make sure you're on the same wavelength.
And another point that I want to note now, but then did not think about it.
2.4. Taking into account the level of the team and the specifics of the project: the new ones in this company were engaged in this unfortunate project
developers and testers. If it were not for this nuance, then perhaps everything would go well for the project in question, even without the preceding paragraphs.
Moral: the method of collecting and describing requirements, as well as the project implementation model, depends on the specific project. What to consider:
- command level;
- team immersion in the project;
- team harmony;
- type of tasks (something standard for this team, configuration, or a complex, unique project);
- project budget and deadlines;
- much more.
But this thought did not come to me immediately, and for some time I was looking for my ideal specification.
3. What did I do in this situation:
3.1. I read a lot: Vigers, Leffingwell, Coburn, etc. went into action. I considered examples of specifications, tried to get the maximum of useful and suitable, and immediately used it in my work.
3.2. She organized timely feedback from testers and programmers in the early stages of the project :
The project manager was surprised when I asked to select a tester to view the specification, but I was going to meet it. After all, there are such questions that come only to testers! And well, when they are considered on time.
3.3. I gathered together some of the customer representatives, programmers, testers, project managers before launching the project: at such a meeting we were convinced that we understood each other correctly, reminded important details, etc.
After a short period of time, programmers began to note progress and thank for the specifications.
And then I realized that I had stalled at some level and I want to move on. I got an obsession: find out how other companies write specifications, and learn something new for themselves. There were forums, a community of analysts. I read “like others,” considered examples, initiated meetings and asked questions.
Separately, I want to note that the world is not without good people, and unfamiliar, but experienced analysts have never refused me to meet and answer questions. Thank you, dear colleagues. Therefore, "seek and find, knock, and they will open it to you."
To be continued…
Source: https://habr.com/ru/post/262869/
All Articles