Programme

The presentation showcases the practical experience of our product team in using the Customer Journey Map (CJM) as a source of new valuable business requirements and growth points for a corporate IT product, and, most importantly, the specifics of applying CJM to the development of an internal IT product. We will examine the main reasons why corporate IT product development teams sometimes do not use CX tools. I’ll tell you what prompted us to use CJM, how we were able to take a fresh look at our product and users, what challenges we faced in finding respondents, conducting interviews in a corporate environment, and securing funding, as well as the pros and cons of CJM for corporate IT products. I’ll share the “pain points” we identified using the map — not only for our IT product but also for related services — and the specific business requirements that emerged from the CJM insights, and how they affected the product and our users’ loyalty.

Many teams fall into the "prototype trap": in a sandbox the AI agent looks flawless, but in production it breaks under load, network connectivity issues, drift, and hallucinations. Classic systems analysis falls short here: there are no interfaces anymore, and blind trust in an LLM leads to incidents.

The talk presents an original framework for designing production-grade AI agents, based on hands-on experience deploying agentic systems at the country's largest bank. We'll cover the analyst's shift from screens to deterministic skills, specifications, and safe execution environments.

You will learn:

• How to filter out non-agentifiable processes using a risk funnel and an autonomy matrix.

• Why pure ReAct is dangerous in production and how to build a hybrid graph (StateGraph + MCP + HITL).

• How to move from static tests to LLM-as-a-Judge and SDD.

• How to protect the environment: 4 layers of defence and model risk management.

You'll walk away with a checklist for designing reliable enterprise agents.

The lion's share of development time is spent not on writing code, but on endless clarifications like, "What did the customer actually mean?" We are used to jumping straight into the language of solutions instead of the language of goals. As a result, teams face constant rework, endless iterations, internal conflicts, and generic trial-and-error guesswork instead of finding elegant, low-cost solutions.

In this workshop, we will dissect the root causes of this pain point. Based on TRIZ approaches, we will break down a universal framework for precise problem framing.

This approach has proved effective in practice across a wide range of projects. It will be valuable for hardcore IT tasks and complex business challenges, as well as for those daily urgent requests that constantly distract you from core work.

Key Practical Outcomes:

Shift in Focus: An algorithm to translate customer "wishlists" from the solution domain into clear and measurable goals.

Over many years working at various companies, I've noticed that the first thing that comes to mind when people hear the word "optimisation" is cost reduction! The reaction of employees often resembles a vampire’s response to sunlight. I say my "stop phrase": "Hello, I'm an analyst. I specialise in optimising business processes," and I go from being a charming, promising specialist to being an enemy of the people.

What is optimisation really about?

It's not about downsizing, not about saving resources, and not about lowering salaries.

Optimisation is about the value of the product and the effective use of resources.

I propose that we discuss my experience and mistakes and consider options for preparing to start the optimisation process.

We won’t be talking about perfect prompts, AI agents, or whether AI will replace analysts. Neural networks are already a great help to analysts: they write requirements, bring structure to chaos, and eliminate the "blank page" syndrome. But this speed comes at a price — AI can be very convincingly wrong. Generated artifacts often look so professional that it's dangerously easy to miss logical gaps and hallucinated business rules.

Using real-world examples, we will explore how AI amplifies cognitive biases, why "beautiful text" gives a false sense of security, and how critical thinking and emotional intelligence (EQ) help an analyst uncover the client's true needs — things that AI will never read between the lines.

Customer service at T-Bank is not just a service—it's a client-centric ecosystem where every interaction aims to resolve issues quickly, effectively, and with empathy. To accelerate service delivery and improve quality, we are transforming existing processes and actively integrating AI—from chatbots and LLM agents to intelligent routing.
We will discuss:

• What customer service means, its structure, and key stages in resolving client issues.

• What lies "under the hood" of customer conversations and the technical challenges involved.

• Flexible versus rigid LLM agents: when hallucinations cannot be tolerated.

• Whether AI tools can be scaled on top of architectural debt and what solution we implemented in a payment transaction cancellation use case.

• The flip side: when AI stops enhancing service quality and leads to unnecessary costs—sometimes it's more cost-effective to fix the existing process and stick to an algorithmic approach.

How do you turn a user's "pain point" into a working web application with an AI agent — without wrestling with infrastructure and lengthy setup? We present a new format — Vibe-Hack, a hybrid of a hackathon, design sprint, and vibe-coding workshop.

In just 20 hours, participants go through the full cycle:
— explore the problem and formulate hypotheses,
— design user scenarios and flows,
— get a structured technical specification from an AI agent,
— and use vibe-coding to build a web application with an AI agent under the hood.

We use only cloud-based tools—Replit, Lovable, Gradio, and Streamlit—that are available to everyone without installation. This allows us to focus on building the product rather than configuring servers.

Key takeaway: Participants learn not to write code for AI, but to design solutions together with AI — and do it fast.

A dark pattern is dangerous not only because it irritates users: it also leads to abandoned journeys, support requests, negative reviews, and app uninstalls. Yet interface quality is often assessed subjectively: the business talks about retention, while the user experiences pressure.

This talk presents a quantitative method for assessing dark patterns. We will compare paired user journeys - account registration and deletion, service activation and cancellation, consent and refusal. Each journey will be mapped as a graph with weights for every action and obstacle - a hidden menu item, an unnecessary screen, a channel switch, or a repeated retention attempt. Based on these values, we will calculate the journey cost, the asymmetry ratio, and the risk of user rejection. Using mobile app examples, we will show which elements create the greatest pressure and how audit findings can be translated into measurable requirements while preserving business goals without losing customer trust.

Candidates are increasingly turning to AI (LLM) for assistance during interviews. AI listens to an expert's question and instantly provides an answer—it's convenient and effective, especially when the question has a clear answer. Therefore, testing only theory and assigning simple problems is becoming less effective. The winners are not those who truly understand analysis, but those who have learned to find the right wording faster than others. But there are questions that can't be rushed: they don't have a single correct answer and reveal the candidate's ability to reason. These questions straddle the dichotomy of requirements: business and system, what and how, value and feasibility, goal and objective. In this talk, we'll explore how such questions assess not only knowledge of terminology but also the maturity of thinking, the ability to discern conceptual boundaries, and the ability to distinguish true expertise from superficial confidence and skilful use of AI.

Team knowledge is scattered: personal notes, Confluence, Bitbucket—there's no single place. We're increasingly asking LLMs, but the model doesn't understand the specifics of teams (who has what role, how the process is structured), doesn't suggest where to look, and often just makes things up. 

We've found a different approach—not "another smart search" or classic RAG. It's an approach that gathers team knowledge in a single framework and gives the analyst a tool to manage it: a Git database, clear instructions for the AI agent, and human review of changes. 

The talk features a live case study, typical mistakes in practice, and how the role of the systems analyst is changing: from page author to rule setter and agent reviewer. You'll walk away with a framework you can build yourself.

A classic story during an interview or when designing a new solution:

1. We identify and document business scenarios and NFT

2. We design an architectural solution

3. We hand it over to development

4. ...

5. Profit

But wait...

- How will we handle the projected workload?

- How will we scale?

- How will we even support our NFT?

We won't answer these questions, of course.

If you don't want to become the hero of this story, then come to the workshop, where we'll use a real-life case as an example to explore approaches to implementing typical NFT.

This is a practical workshop; teams will draw arrows and squares and discuss the results. For mid-level+ specialists

This report examines the transition from general systems thinking to architectural thinking, with an emphasis on developing architectural solutions. Systems thinking is based on the "part-whole" concept, allowing for analysis at multiple levels: from cells to entire organisms and organizations. It helps identify conflicts between levels—for example, the desire of individual departments for growth, which may be viewed as a threat to the company. Architectural thinking encompasses a broader range of structures: functional, modular-interface, control, informational, and financial. Architecture involves selecting key components that inform important decisions governing the operation of an object. The course will also explore First Principles Framework (FPF) architectural patterns aimed at improving collective thinking and interaction with AI agents. Attendees will not only gain a deeper understanding of systems and architecture but also apply AI techniques to solving various problems.

Assessing a Systems Analyst's Soft Skills in a Technical Interview: "How to assess soft skills systematically and impartially. 

Hard skills show what you can do now; soft skills show how you'll grow tomorrow."

In this talk, I'll share a real-world case study of implementing an in-house ATS at Lenta — and how the BA role grew far beyond requirements gathering. I'll cover the multiple roles I juggled, how we built relationships with the contractor, and the personal and organisational pain points the project revealed — along with the fixes we put in place.

I'll explain how we connected with the client: found common ground, respected their expertise, and became "one of them" — especially crucial after a prior failed implementation. I'll also show how I built long-term trust by teaching the client BA basics, process modelling, and IT tools.

Finally, I'll bust the "terrible client" myth, argue why investing in both our own and our clients' competencies matters, and share the concrete results we achieved together.

How can we teach a model to produce a clear, compact document that meets our specific practices and constraints, rather than a faceless stream of generic tokens? For this purpose, there's the Agent Skills standard, which allows us to use simple descriptions to guide the agent in the right direction and monitor the results. During this workshop, we'll develop a simple skill: creating compact records of architectural solutions. Participants will benefit from this specific skill, as well as the ability to create other similar tools.

AI Disrupt PDLC says that those who don't implement Spec-Driven Development by 2027 will be hopelessly behind. But the essence of SDD is revealed only when the process begins with the analyst.

 For us, SDD is a single specification artifact that runs the entire path from customer requirements to automated tests, without getting lost in translations between roles.

Using real projects — a long-standing monolith without documentation and a system with microservices—I'll show:
— how we restructured requirements workflows for specs;
— what changed in the analyst's daily work when working with AI agents;
— how we adapted the analyst team and what didn't work the first time;
— how we explained and agreed on the new process with customers who weren't ready for changes in the approval artifacts;
— how the spec extends to testing and bridges the gap between analytics, development, and QA.

Autonomous AI agents don't just advise; they act: they delete data, spend money, deploy to production, and send messages. Through real failures (a production database wiped in 9 seconds, a $4k bill from GPU jobs that never stopped, an agent that locked out its own owner), we'll see why an agent's mistake turns into real-world damage and which controls actually shrink the blast radius. Attendees leave with a working vocabulary and a practical checklist for safe agent usage.

A systems analyst in an enterprise environment spends up to 60% of their time on routine tasks: searching Jira issues, pulling specs from Confluence, analysing logs in OpenSearch, querying Oracle DB, syncing docs across systems. I'll share how I configured an AI agent based on Kilo Code with 9 MCP connections to corporate systems and a swarm of 20 specialised sub-agents — and now delegate all my routine tasks to it. Live cases: morning status check across 6 systems in 2 minutes instead of 30; four-phase incident analysis "logs → metrics → trace → DB" via a single prompt instead of 8 tabs; bidirectional Markdown ↔ Confluence sync without copy-paste. I'll show the architecture: how Context Offloading saves 85% of the context window, why Quick Context notes matter, and how an Obsidian vault becomes an analyst's "Second Brain" with automatic session logging.