If the development team is lucky enough to have both a tester and an analyst, you can be sure that these guys will ensure that the client receives not only a quality product, but also the product they actually wanted (but it's not certain).

In the best traditions of those tunnelling under the English Channel, we work from different sides but together, like Bonnie and Clyde, like Lolek and Bolek, like Křemílek and Vochomůrka. And we will definitely meet (but it's not certain).

However, it's absolute certainly that the analyst will not let you get bogged down in an endless array of corner cases, will assist with validating the development for compliance with the original business requirements and the overall product concept, and will become your second wing on the way to the common goal. After all, they still have to go to the client for acceptance testing.

Let's talk about what exactly, how, and in what volume an analyst can test, to confidently hand over the finished product to the users.

It seems that a good analyst doesn't consider that he or she has finished his or her work after putting the final dot on the artefact for the developers. So even if there is a tester on the team, it doesn't prevent you from taking the time to check the finished development yourself before release. This will help ensure that the customer gets exactly what was discussed and documented. 

In addition, the analyst may be involved in acceptance testing with the customer's team - there are also subtleties in preparation and execution.

At the last Analyst Days, I talked about how mentoring technologies can be used to train an analyst who is focused on the specifics of a company, its products, tools and technologies. 

However, it is not a secret that analysts are one of the most loosely interpreted professions, despite the existence of as many as two standards. Therefore, each company decides individually which person to call an analyst, what set of skills are required from him or her and what tasks to assign.

I do not want to rekindle the eternal holy war about how a business analyst differs from a systems analyst and whether they are different people. I will simply show you what tasks an analyst can encounter on the way, what roles to combine on projects, and where to develop if you get completely bored. 

I hope that my story will help you discover, with surprise, what your fellow analysts are still like and suggest possible points of growth and development.

Is mentoring only for newbies? I don't think so.

I've worked in companies with different approaches to mentoring for 20+ years. I've been both - mentor and mentee, and I'm sure that mentoring is a powerful tool that can be used to achieve various goals and solve a wide range of tasks.

It can improve the employee's skills, grow and support a positive attitude to work and loyalty to the company, reduce the duration of the adaptation period and save the manager's time and nerves.

We will talk about:

• how to build a mentoring system;
• which goals it can achieve;
• which benefits you will get;
• who can be a mentor;
• how to support employees beyond the mentoring.

If you ask yourself - should I spend my time and money for this - I've made a pretty comprehensive guide with arguments and tips for you to decide.