Business Analyst Group (Virtual)

There is a lot of discussion about AI in software development, especially around Vibe Coding

. But what about Business Analysts? 

In my view, BAs can — and should — use AI. Not to replace analysis, listening or critical thinking, but to speed up parts of the process. 

AI can be very useful for things like:

• organizing interview notes;
• turning rough ideas into requirement hypotheses;
• suggesting discovery questions;
• identifying gaps or ambiguities;
• supporting the writing of user stories and acceptance criteria;
• comparing scenarios and impacts.

Maybe this is a kind of “Vibe Requirement”

: using AI to move faster from rough notes to a more structured understanding of the problem. 

But there is one important point: governance

. 

Not every piece of information should be entered into any AI tool. Client data, internal processes, sensitive information and business strategy must be handled responsibly. 

A Business Analyst can use AI, yes. 

But they need to know what to share, what to anonymize and where to use it.

In the end, AI can help us write better. 

But understanding the problem is still the BA’s responsibility.

AI suggests. 

The BA questions. 

AI organizes. 

The BA validates. 

AI accelerates. 

The BA ensures business value.

The point is not to use AI to write requirements faster. It is to use AI to write better requirements.

ENG

Questions that Elevate Technical Solutions 

Today’s post is an excellent read by Prof. Tarcísio Almeida regarding the important task of proposing solutions for the most varied situations.

“Question the presented solutions more.”  

This is common guidance that leaders give to their teams.

“Guys, bring ideas. Question more.” 

But then someone presents a technical document, an architecture proposal, or a product solution…

And the meeting ends like this: Silence. No one questions anything.

Most of the time, this doesn't happen because people lack ideas. It happens because they don't know exactly

A simple way to contribute to any technical discussion is to look at the four pillars of any delivery:

Time, Cost, Quality, and Scope.

If your question helps improve any of these points, it is already a great contribution.

Time

• Is there any way to deliver this faster?
• Can we break it into smaller parts and validate them sooner?
• Is there a simpler solution for a first version?

Cost

• Does this solution increase infrastructure or operational costs?
• Is there a simpler alternative, perhaps reusing something we already have?
• Are we creating something that requires heavy maintenance in the future?

Quality

• Are there risks regarding performance, scalability, or reliability?
• How does this solution behave in failure scenarios?
• Are we taking on any significant technical debt?

Scope

• Does all of this really need to be done right now?
• Is there a smaller version that already solves the main problem?
• Are we trying to solve more problems than necessary at this moment?

Another powerful question in any discussion is: What alternatives were considered, and what are the trade-offs of this proposal compared to the others? 

Good technical discussions are rarely born from opinions, but rather from good questions.

So, the next time someone presents a solution, try looking through this lens:

If your question helps improve any of these four points, it is likely already elevating the quality of the team's decision. 

Post and article link: https://www.linkedin.com/feed/update/urn:li:activity:7437581888506118145/