5 differences analyst work in projects and product development
When it comes to the role of the analyst in IT, you always have to add a bunch of clarifications. Business or systems analyst? Analysis in product development or project, as is, for example, often happens in consulting? On the internal development or custom? .. Customer state or non-state? And so on.
Before joining Tutu.ru, I worked in IT consulting on ERP projects and in custom-made product development, and here I am engaged in system analysis in the Avia internal product. Our system analysis department consists of 9 analysts and 1 technical writer. Further, in my experience, I will tell you what changes in the specialist’s head and workflows when changing the format of activity to internal product development from the point of view of analysis, and at the same time I will share how the process as a whole works in our Tutu.ru.
In custom development (i.e. in project implementation for specific business tasks - most often, but not necessarily, from scratch) or in projects for implementing existing IT solutions, analysts are limited by the requirements of the customer as the primary competency holder in their field, an expert in business methodologies and legislation, or are limited by the capabilities of the standard functionality of the implemented solutions. For the latter, they sometimes release localization packages (additional parts of the standard functionality focused on business and legislation of certain regions), which should alleviate the situation a little, but, frankly, they are not often useful. In such work, the task of the analyst is to propose a solution that is not too difficult to implement without breaking the current architecture. And all this, I repeat, within the limitations imposed by the basic functionality.
')
I agree, this phrase was quite boring to read. And this is a rather narrow field for creativity, isn't it? Nevertheless, creativity is present here, and restrictions can serve as an incentive to develop very bizarre and at the same time working mechanisms!
As it was in the products : When I switched to product development, it was not easy to switch to the idea that I could come up with absolutely anything. The instincts acquired over the years called for action within the framework of existing decisions. After all, if it comes to your own product, you need to connect the fantasy, give out options and alternatives. Until the creation of new processes, functions, and in general changes of everything, anything.
Fighting this reflex takes some time. At first, every now and then you catch yourself thinking that around the border, the border, the border. But these boundaries are only in the head.
How it works in Tutu: As part of working on each task, we discuss possible solutions with the team, team leaders, and product owner (he is Product Owner, aka software), who encourage creative ideas, even if the most simple version of proposed. If necessary, we can collect brainstorming - including with colleagues from other departments (for example, from our contact center or the sales support department of tours), who are happy to share their observations and advice.
In the design work, where there is always an established Customer (no matter how many individual “sub-customers” would be within the framework of the One Big), more often it is not necessary to think too much about why this or that requirement is needed. The customer said so-and-so, it does not contradict the accepted business rules, methodologies, and hitherto developed functionality - it means it should be. The customer will not go against himself and his business! Thus, the task of a system analyst includes more description of business processes, collection and specification of requirements, local development of the architecture and, possibly, documentation of all of the above.
In products, expertise is often inside, and we, as a development team, can, want, and even possess carte blanche for greater autonomy to work out solutions. A new important question - is it possible to do something conceptually differently, in a different way? Is there a need? How else can you solve the problem, the problem, the pain and the need? Is this the best option, and will it be useful for users and businesses? Are we sure we will help someone with our decision? These are the questions that I, as an analyst (and other team members), should think about at the very beginning of the analysis. It turns out, in a sense, my colleagues and I are endowed with tangible power in making decisions, but at the same time, a very big responsibility.
How it works in Tutu: The customer - that is, the voice of the end user - is most often the owners of the products (software). But at the same time, our software attentively listens to the opinion of the development team, although the decision point is precisely on their side. As they say, one brain is good, but six is ​​better. That is why sometimes we discuss tasks all together. In the end, all of us are not only developers, but also passengers, who will later use the finished product.
Speaking about different frameworks and models of the software development process - such as Waterfall, RUP and others, it is worth remembering that these are not just different approaches and management techniques, they can also be fundamentally different cultures and behavioral patterns. For example, in consulting, the situation is quite familiar when, when new important requirements or new introductory ones arise (which have been forgotten - this happens, the projects are large), the contractor finds a letter in which you agreed on such a certain amount and composition of work, and new requirements were not specified. as part of the plan. Such a letter can serve as an official permission not to take into account the requirements now, to postpone the development to the next stage of the project, as part of a new task and for additional funds. That is, in extreme cases, the obligations may be higher than the resolution of the pain of the customer - otherwise the boundaries of the project and plan may grow to infinity.
In Agile as a whole (here I do not insist specifically on product development), with the emergence of new knowledge, it is possible, and often even necessary, to overestimate and change the behavior and development plan. Even if this very development is already in the process, and even that was just completed. Yes, it may not be very pleasant, but it should not be a disaster, including for a system analyst. However, an important note: not every new requirement must be taken to work right this minute. New requirements should be assessed and prioritized in the carousel of other tasks (for example, the MoSCoW method can be of help).
How it works in Tutu: we try to carry out the analysis as fully as possible before starting the development - this allows developers to deal with issues of their field, and testers know exactly how future functionality should behave. However, due to the large number of stakeholders and a variety of carriers, it happens that the new priority requirements for the task arrive after the fact.
In such cases, we can act on the situation: either decide to change the development plan right away, even if it is not very convenient (if external circumstances have changed, for example, new requirements of carriers with a certain period have appeared), or to make some final version without new requirements, but be sure to set the task with the new requirement for the next sprint-two. So we play with the balance of speed / quality analysis within the framework of common sense.
Already, there are a dozen or two other ways to process and store project documentation. Oh, these requirements for project documentation and its structure ... Analysts like to type with knowledge of the standards GOST 19, GOST 34. Methodology Oracle AIM offers a dozen or two templates for various types of documents: functional design, settings directory, role library, all templates are approved and coded. Documentation is kept up to date, any employee can refer to any document and correct anything there (of course, with indication of authorship, application and nature of changes). And if all this is “not supported” in time - will the improvements be counted in the audit of labor costs?
But you have your own product and suddenly you are the owner of yourself and your knowledge base. If you work on the description of processes, products, functionality, requirements, it will be good. If you write badly, then it will be bad for people who will need these texts with requirements and descriptions, including yourself. Despite the fact that no one will stand with a gun at his temple and force, under pain of death, to write texts according to GOST, it is in your best interest to document and do it optimally (in a way that is convenient for you and everyone).
How it works in Tutu: We use Confluence and local analytic standards for maintaining various documents, and the tasks themselves can be maintained in JIRA. We agree on what volume is necessary and sufficient: despite the fact that lightweight documentation is popular in the company (without unnecessary details), for some teams we describe the requirements in more detail. Documents are not a harmonization tool (as is the case in customized development), but they allow us to form a complete understanding of the product and individual blocks of functionality both by us, the development team, and external stakeholders (for example, colleagues from other products and departments).
Sometimes this picture from the past arises to this day. Some kind of bug arrives, and now, you need to drop everything, quickly draw logic and code in 10 minutes, then another 5 minutes for testing and another 5 minutes for installation on production. And then you can exhale if another similar bug has not arrived. Which, most likely, flew ... With the introduction of the same accounting, several urgent, critical tasks for datafiles flew in every month - the data could not be corrected manually, and the financial period with incorrect data cannot be closed. Let us also recall the SLA under the project agreement, for violation of which you can be fined or get a scolding. And users are worried, I do not want to worry them again.
And you stay with these modifications until midnight, until one in the morning - until the system administrators reach home computers and flood them into the production base, and you do not write to the users a later letter “everything is fixed, you can close!”. And on the weekends the same ...
But no. Still, the products that are truly blocking tasks, because of which you need to pan up a little, occur very rarely, IF we are not talking about high-loaded products, where the cost of downtime is very high. In a standard situation, most of the bugs (I do not claim that all of them) hardly require a solution here and now, in one instant: you can stop, exhale, think about what and how we rule. Tasks with problems are often simply given an increased priority, and they go out of turn in relation to other tasks of the plan or sprint, but at the same time they pass through regular releases.
Thus, it can be said that there is a difference not only between projects and products (although there is one here), but between the load levels of the functionality used by the users, on the part of the available data volume.
Although, I confess to you honestly: sometimes a long-forgotten reflex sometimes works - well, you need to sell right now, right after 10 minutes!
How it works in Tutu: Since our travel service is highly loaded, of course, we have the concept of a “blocking task” - the one that needs to be done right now. Nevertheless, we try to carry out this task across all roles, including analytics and quality testing by the tester at all the required stands, except that we do it in a more operational mode. This allows us to identify risks and avoid future rework, unnecessary crutches in the code and violations of user logic. In other cases, the task is given priority "increased", or it goes into backlog of bugs, which is supervised by our dear testers.
What is better - projects or products? Here such words as “better” or “worse” are completely inappropriate, in this IT-world there is a place for both one and the other. It is necessary to understand the features of different approaches, to form correct expectations and to consider each project / product individually. In general, I made my choice, but I do not impose it at all. Everyone has their own experience, their own background, their own expectations from work. I - about the products, and you - decide for yourself.
Before joining Tutu.ru, I worked in IT consulting on ERP projects and in custom-made product development, and here I am engaged in system analysis in the Avia internal product. Our system analysis department consists of 9 analysts and 1 technical writer. Further, in my experience, I will tell you what changes in the specialist’s head and workflows when changing the format of activity to internal product development from the point of view of analysis, and at the same time I will share how the process as a whole works in our Tutu.ru.
1. Dobby is free! About imaginary frameworks in the analysis
In custom development (i.e. in project implementation for specific business tasks - most often, but not necessarily, from scratch) or in projects for implementing existing IT solutions, analysts are limited by the requirements of the customer as the primary competency holder in their field, an expert in business methodologies and legislation, or are limited by the capabilities of the standard functionality of the implemented solutions. For the latter, they sometimes release localization packages (additional parts of the standard functionality focused on business and legislation of certain regions), which should alleviate the situation a little, but, frankly, they are not often useful. In such work, the task of the analyst is to propose a solution that is not too difficult to implement without breaking the current architecture. And all this, I repeat, within the limitations imposed by the basic functionality.
')
I agree, this phrase was quite boring to read. And this is a rather narrow field for creativity, isn't it? Nevertheless, creativity is present here, and restrictions can serve as an incentive to develop very bizarre and at the same time working mechanisms!
As it was in the products : When I switched to product development, it was not easy to switch to the idea that I could come up with absolutely anything. The instincts acquired over the years called for action within the framework of existing decisions. After all, if it comes to your own product, you need to connect the fantasy, give out options and alternatives. Until the creation of new processes, functions, and in general changes of everything, anything.
Fighting this reflex takes some time. At first, every now and then you catch yourself thinking that around the border, the border, the border. But these boundaries are only in the head.
How it works in Tutu: As part of working on each task, we discuss possible solutions with the team, team leaders, and product owner (he is Product Owner, aka software), who encourage creative ideas, even if the most simple version of proposed. If necessary, we can collect brainstorming - including with colleagues from other departments (for example, from our contact center or the sales support department of tours), who are happy to share their observations and advice.
2. A little about areas of responsibility
In the design work, where there is always an established Customer (no matter how many individual “sub-customers” would be within the framework of the One Big), more often it is not necessary to think too much about why this or that requirement is needed. The customer said so-and-so, it does not contradict the accepted business rules, methodologies, and hitherto developed functionality - it means it should be. The customer will not go against himself and his business! Thus, the task of a system analyst includes more description of business processes, collection and specification of requirements, local development of the architecture and, possibly, documentation of all of the above.
In products, expertise is often inside, and we, as a development team, can, want, and even possess carte blanche for greater autonomy to work out solutions. A new important question - is it possible to do something conceptually differently, in a different way? Is there a need? How else can you solve the problem, the problem, the pain and the need? Is this the best option, and will it be useful for users and businesses? Are we sure we will help someone with our decision? These are the questions that I, as an analyst (and other team members), should think about at the very beginning of the analysis. It turns out, in a sense, my colleagues and I are endowed with tangible power in making decisions, but at the same time, a very big responsibility.
How it works in Tutu: The customer - that is, the voice of the end user - is most often the owners of the products (software). But at the same time, our software attentively listens to the opinion of the development team, although the decision point is precisely on their side. As they say, one brain is good, but six is ​​better. That is why sometimes we discuss tasks all together. In the end, all of us are not only developers, but also passengers, who will later use the finished product.
3. About analysis after analysis
Speaking about different frameworks and models of the software development process - such as Waterfall, RUP and others, it is worth remembering that these are not just different approaches and management techniques, they can also be fundamentally different cultures and behavioral patterns. For example, in consulting, the situation is quite familiar when, when new important requirements or new introductory ones arise (which have been forgotten - this happens, the projects are large), the contractor finds a letter in which you agreed on such a certain amount and composition of work, and new requirements were not specified. as part of the plan. Such a letter can serve as an official permission not to take into account the requirements now, to postpone the development to the next stage of the project, as part of a new task and for additional funds. That is, in extreme cases, the obligations may be higher than the resolution of the pain of the customer - otherwise the boundaries of the project and plan may grow to infinity.
In Agile as a whole (here I do not insist specifically on product development), with the emergence of new knowledge, it is possible, and often even necessary, to overestimate and change the behavior and development plan. Even if this very development is already in the process, and even that was just completed. Yes, it may not be very pleasant, but it should not be a disaster, including for a system analyst. However, an important note: not every new requirement must be taken to work right this minute. New requirements should be assessed and prioritized in the carousel of other tasks (for example, the MoSCoW method can be of help).
How it works in Tutu: we try to carry out the analysis as fully as possible before starting the development - this allows developers to deal with issues of their field, and testers know exactly how future functionality should behave. However, due to the large number of stakeholders and a variety of carriers, it happens that the new priority requirements for the task arrive after the fact.
In such cases, we can act on the situation: either decide to change the development plan right away, even if it is not very convenient (if external circumstances have changed, for example, new requirements of carriers with a certain period have appeared), or to make some final version without new requirements, but be sure to set the task with the new requirement for the next sprint-two. So we play with the balance of speed / quality analysis within the framework of common sense.
4. A couple of words about the "technical specifications" and documentation
Already, there are a dozen or two other ways to process and store project documentation. Oh, these requirements for project documentation and its structure ... Analysts like to type with knowledge of the standards GOST 19, GOST 34. Methodology Oracle AIM offers a dozen or two templates for various types of documents: functional design, settings directory, role library, all templates are approved and coded. Documentation is kept up to date, any employee can refer to any document and correct anything there (of course, with indication of authorship, application and nature of changes). And if all this is “not supported” in time - will the improvements be counted in the audit of labor costs?
But you have your own product and suddenly you are the owner of yourself and your knowledge base. If you work on the description of processes, products, functionality, requirements, it will be good. If you write badly, then it will be bad for people who will need these texts with requirements and descriptions, including yourself. Despite the fact that no one will stand with a gun at his temple and force, under pain of death, to write texts according to GOST, it is in your best interest to document and do it optimally (in a way that is convenient for you and everyone).
How it works in Tutu: We use Confluence and local analytic standards for maintaining various documents, and the tasks themselves can be maintained in JIRA. We agree on what volume is necessary and sufficient: despite the fact that lightweight documentation is popular in the company (without unnecessary details), for some teams we describe the requirements in more detail. Documents are not a harmonization tool (as is the case in customized development), but they allow us to form a complete understanding of the product and individual blocks of functionality both by us, the development team, and external stakeholders (for example, colleagues from other products and departments).
5. Flexibility against Panic
Sometimes this picture from the past arises to this day. Some kind of bug arrives, and now, you need to drop everything, quickly draw logic and code in 10 minutes, then another 5 minutes for testing and another 5 minutes for installation on production. And then you can exhale if another similar bug has not arrived. Which, most likely, flew ... With the introduction of the same accounting, several urgent, critical tasks for datafiles flew in every month - the data could not be corrected manually, and the financial period with incorrect data cannot be closed. Let us also recall the SLA under the project agreement, for violation of which you can be fined or get a scolding. And users are worried, I do not want to worry them again.
And you stay with these modifications until midnight, until one in the morning - until the system administrators reach home computers and flood them into the production base, and you do not write to the users a later letter “everything is fixed, you can close!”. And on the weekends the same ...
But no. Still, the products that are truly blocking tasks, because of which you need to pan up a little, occur very rarely, IF we are not talking about high-loaded products, where the cost of downtime is very high. In a standard situation, most of the bugs (I do not claim that all of them) hardly require a solution here and now, in one instant: you can stop, exhale, think about what and how we rule. Tasks with problems are often simply given an increased priority, and they go out of turn in relation to other tasks of the plan or sprint, but at the same time they pass through regular releases.
Thus, it can be said that there is a difference not only between projects and products (although there is one here), but between the load levels of the functionality used by the users, on the part of the available data volume.
Although, I confess to you honestly: sometimes a long-forgotten reflex sometimes works - well, you need to sell right now, right after 10 minutes!
How it works in Tutu: Since our travel service is highly loaded, of course, we have the concept of a “blocking task” - the one that needs to be done right now. Nevertheless, we try to carry out this task across all roles, including analytics and quality testing by the tester at all the required stands, except that we do it in a more operational mode. This allows us to identify risks and avoid future rework, unnecessary crutches in the code and violations of user logic. In other cases, the task is given priority "increased", or it goes into backlog of bugs, which is supervised by our dear testers.
***
What is better - projects or products? Here such words as “better” or “worse” are completely inappropriate, in this IT-world there is a place for both one and the other. It is necessary to understand the features of different approaches, to form correct expectations and to consider each project / product individually. In general, I made my choice, but I do not impose it at all. Everyone has their own experience, their own background, their own expectations from work. I - about the products, and you - decide for yourself.
Source: https://habr.com/ru/post/358626/
All Articles