Don’t hire business analysts
Вначале несколько суммирующих фраз:
why business analysts are needed in medium and large businesses, what tasks they can - and what tasks they can't - do.
With analyst , the team is even more distant from the bearer of the idea
In his head he needs the same thing as the project owner, but his area of responsibility is more blurred.
Oh, today we have a super controversial video, I'm afraid to imagine how many dislikes it will gather! However, everything in this video is the result of seven years of running an IT company and diving into different businesses and their IT departments. I see that some people in c-level who faced with low IT efficiency try to split one position for pieces that easy to control and hire, but that splitting process is often done incorrectly - in a way that blurs the responsibilities of others. I'll start with business analysts, and after a while I will talk about testers or QA as well.
CIO.com states that business analysts are people dedicated to bringing IT and business together based on understanding processes, different data, gathering requirements to implement a business need, and providing recommendations for data-driven changes to all stakeholders.
The role of business intelligence is critical, even for a clear mission statement. Development doesn't just make some button, it optimizes some business process that should potentially add a lot of value. That button must be understood and implemented as intended, and in order to be used - it must take into account user support for the new functionality.
The International Institute of Business Analysis (IIBA.org) [defines](https://www.iiba.org/business-analysis-blogs/product-owner-vs-business-analyst/) define business analysts as people who will more accurately articulate the task in the most optimal way from the perspective of the business process, most accurately describe it, as opposed to a busy product-owner. He has more time to look at the necessary data, the process decisions can be made more accurately.
It seems to be no surprise - economic science says that the higher the specialization of labor, the higher the productivity. The higher the productivity, the higher the efficiency. Don't we all want efficient IT? We really do.
That's why, in the vast majority of companies, business analysts are present in some way.
This is what we will talk about today.
Hi everyone, I'm Andrei Putin, and we at Komplizierte Technologien produce many thousands of hours of development, analytics, problem-setting, and everything that is somehow related to increasing the efficiency of our clients with IT development every month.
And today I wanna talk about why business analysts are needed in medium and large businesses, what tasks they can - and what tasks they can't - do.
So, the business in the form of a product owner has identified a value that needs to be done. And starts discussing it with the business analyst. The business analyst generally ensures that this value is communicated to the team in a properly decomposed way into small chunks.
However, what actually happens?
1. The first problem I will highlight is the problem of a clear area of responsibility. The business analyst is not responsible for the success of the product or the value. Here you have a product planner, and he is responsible for the value of the product. His job is to find a methodology so that the value gets to the team without distortion in clear and most simple way. However, if we have a business analyst, what does he determine? I notice that he often draws some complicated schemes and somehow describes the tasks. At the same time, he is often not responsible for the implementation of described tasks - there is a project manager or scrum team for that. And if so, where is the focus of his responsibility? With analyst , the team is even more distant from the bearer of the idea, and BTW in large enterprises the product-owner is often not the final consumer of the product, which makes the situation even worse. The product-owner ceases to fulfill his role in the hope that the business analyst will pull out all that is needed, and the business analyst is not responsible for value, so his performance criterion is expressed in schemes and descriptions describing the task. Value begins to be substituted for a set of described issues. The product-owner can blame the business analyst, the business analyst in turn can blame the product-owner and the team. Besides the fact that the business analyst alienates the development team from the business, the product-owner often does not hire and is not responsible for the business analyst himself - someone has already determined that he needs a business analyst from above, someone has hired him, someone has given him powers that conflict with PO job. Can we really wait for efficiency improvements in that case?
The second problem is the problem that developers can turn from engineers into coders and the project from a set of values into a set of tasks. Domain Driven Design defines that the development team must think in business terms, the business and the team must communicate in the same language. There should be no translator between the code and the business. If the business analyst has done a good job, then the developers become just typists, translating issues from Jira into code.
If the business analyst is doing a bad job, their diagrams and task descriptions are only partially helpful, and the team is still figuring things out as they go along. And if the business analyst worked poorly on the value but described it well? The whole team may get the feeling that the value is well thought out, and then there is no doubt about the described value, but the output is not the same. All variations entail a decrease in team effectiveness. For the same reason, business analysts do not fit into many Agile practices - for example, SCRUM is not aware of such a role, because according to Agile practices, the team should have better value understanding, not better describe it.
The third problem is that the business analyst does not know the product the way the business knows it. The business analyst does not face the management problems that the product owner is supposed to face. He's not the one who sees inefficiencies in processes on the ground every day, and he's not the one who gets the optimization insights. The feedback from end users does not come to him either, or comes in the narrow context of IT functionality. As a result, the business analyst cannot understand what is primary and what is secondary. As a result, he often suggests improving what is not broken or is clearly not a bottleneck. And in general, the business analyst focuses more on the technical side of the issue rather than on management, and in my opinion, the overwhelming problems in IT are exactly because too many features are done in the wrong places - id est the problem is clearly a manager's one.
The fourth problem is the problem of negative selection. In general, a business analyst should be able to make a candy out of fuzzy business requirements, model the future of a product in order to foresee some problems, while being perfectly aware of the subject area and technologies and communicating with the team. In other words, according to Adizes, he is an entrepreneur, a producer and a communicator. How likely is it that a person who can do all these things will come to a position without authority? Such a person would have to be a manager himself. And what profile of tasks does such a person face? To describe the tasks, maybe tell the use cases and variations, to attend a call with 20 people... In short, his tasks are not the most interesting. At the same time there is no authority. How does this affect the selection of the best staff? I think you can imagine.
To summarize the problems, it seems to me that the classical business analyst in software development does not solve the problem of simplifying the search for competence, but rather aggravates it - in his head he needs the same thing as the project owner, but his area of responsibility is more blurred. SCRUM says that team decomposes the task if it needs - and the product owner’s role in share knowledge about values and their priorities with the team. The business analyst doesn't just understand value, he decomposes it - removing the responsibility from the developers and product owners to think through and refine the value.
Businesses, on the other hand, implicitly consider that they may not learn process thinking, they may not learn how to elaborate the goal setting tasks, and they get used to task descriptions that are too complex - there's a whole person for that for a reason!
This in no way cancels out the randomness effect, where a passionate business analyst begins to essentially act as a scrum master and product owner, and digs deep with the business into the value and proper sequencing of this or that change. I'm just saying that random luck is an unsystematic and unsustainable solution to this problem.
So where can a business analyst be useful? And here I have several assumptions.
1. The first is that I find working in many places. A business analyst is useful when you need to collect a lot of routine data before implementing a task - it doesn't matter if it's a type of interface in moqups or a set of attributes to prepare an integration. So why not have them collected by a separate person? In that case, the business analyst is either a configuration specialist or an interface designer. The important thing here is that the team retains responsibility for delivering value and for understanding value, and the business analyst is an equal member of the development team. The problem of implicit responsibility shifting is not easy to solve here, which reinforces the importance of the scrum master, that's why I don't recommend calling that position as business analyst in that design. Call it as a secretary, it would make more sense to the whole team.
2. and the second thing that appeals to me personally is the business analyst as a mentor to executives and product owners. An executive or product owner solves his own problem, not someone else's. He gets insights. He gets the earliest experience from implementing changes and he can also better identify the bottleneck. He already has both the authority and a direct reason to communicate with other departments. For such managers it is important to keep task descriptions systematic and simple, and schemes are working and without technical terms. That is, they have no problems with motivation, but they often have problems with TOOLS. They would be happy to describe the task correctly, if it takes a little time - but they don't know how! If a mentor arrives along with business analysis and concise description and reduction of value with the help of various techniques - unit economics, impact maps, correct use of business processes, then the business wins. Add to that the authority to control the ease of collecting metrics and help define them, and the company starts to have an analytical culture on systemic rails. As we train business customers on these tools, we notice how much IT efficiency increases! When the business starts to think clearly, the backlog becomes much smaller, and value description issues cease to be an issue. Even the design of interfaces becomes easier, because they become much simpler. But agree, don't dare to call this job “business analyst”.
That's all for now. Bye!.
Таймкоды для шортс:
02.22 - 02.30
02.58 - 03.09
04.10 - 04.19
07.59 - 07.07
7:18 - 7:44
09:38 - 09.50
04:59 - 05:11
14:46 - 14:57
0:28 - 0:35