Цепков Максим Александрович
Главный архитектор решений - CUSTIS
Moscow, Russia

IT-архитектор, бизнес-аналитик, эксперт и навигатор по миру Agile и бирюзовых организаций. Проектированием корпоративных и банковских систем занимаюсь 20+ лет, а всего IT 30+. Я убежден, что автоматизация открывает новые возможности для развития, а создавая IТ-системы, мы открываем путь прогрессу и делаем мир лучше. Работа в больших проектах позволяет сравнивать классический и гибкий подходы. Я знаком с Agile с 2008 года и вижу, что это - способ менеджмента будущего. Я активно участвую в профессиональном IT-сообществе, веду блог на своем сайте http://mtsepkov.org/, вхожу в программные комитеты конференций SECR и Analyst Days, открыт к общению с коллегами на различных площадках и в соцсетях.

Talks (29)
  • 29.12.2023
    Systems thinking and it's place in the work of an analyst

    Systems thinking is a powerful tool for building models of the real world and designing its changes. I talked about it and the underlying rational thinking at the autumn Analyst Days. But are such powerful general tools really necessary for analysts and architects in their daily work? Perhaps simpler techniques are sufficient: highlighting the glossary of the domain area, mindmap for structuring, bpmn for processes, c4 model and Archimate for the architecture of the IT landscape, OOP for building data structures, user story and use case for describing the users' activity, DDD and Event storming for complex domains? All of them are designed for IT and work successfully. 


    My experience is that applied methods are good and correct, but without the support of systems thinking, their formal application leads to design errors. In the talk, I will focus on points in the project where mastery of systems thinking is essential and will show how applied methods rely on it.

    • Average
    • 40 min
    • Analyst Days / 18
  • 15.09.2023
    Self-determination: What do I want from life and work?

    The modern world assumes you actively define your path rather than follow the standard career ladder. To successfully self-determine, you need to be able to address various questions:

    • How do you determine whether to move forward or stay in your current position?
    • How can you envision different development options and choose among them?
    • How do you distinguish between the challenges of learning and exhaustion when pursuing something not your own? 
    • How do you know when it's time to take a vacation to prevent burnout or focus on your family?


    Answers to such questions are not taught in school or university; you must learn them independently. I will share some frameworks that enable you to think systematically about all of this and make decisions.

    This is not my first talk on this topic; previous ones are on my website. However, in preparation, I discussed current issues with the Program Committee that testers often encounter, and the focus of the talk will be on them.

    • Easy
    • 40 min
    • SQA Days / 33
  • 31.07.2023
    Rational and systems thinking: practices and competencies of an analyst

    The essential skill of an analyst is to identify objects and their relationships and determine the types and workflows of documents – in general, to build models. This should be done during interviews, analyzing documents and Excel files. Typically, object-oriented approach is used for this purpose. OOA is a specific instance of systemic thinking methods based on rationality. They teach how to structure information about the world: to mark up texts and other narratives to build models by considering the world as a collection of interacting systems. Understanding these thinking methods provides a powerful apparatus for analysts to solve complex problems. This is analogous to integration methods: there are specific approaches for particular integrals, and there are general approaches.

    In the presentation, we will discuss applying rational and systemic thinking methods for solving analytical tasks. 


    • Easy
    • 40 min
    • Analyst Days / 17
  • 27.01.2023
    Requirements or Model: how to write the statements

    There is an idea that systems should at first be described as a black box, and requirements engineering is devoted to ways of such description. Goal: if we check the system for compliance with the requirements, we guarantee that the system is adequate for business needs. But it doesn't work that way. So, it makes no sense to go too deep into the requirements, but you should quickly start to make models or use easy formats for requirements. 

    I'll review different approaches to writing statements: procedural and object approaches, DDD, use case, user story and others.

    • Average
    • 40 min
    • Analyst Days / 16
  • 29.09.2022
    Self-determination: What I want from life and my work

    The modern world assumes that a human seeks an image of his future and independently builds a path to it. Standard career ladders are irrelevant, the rapid development of technology requires changing specializations and mastering new things. And, unlike in the past, work becomes not just a source of income, but also an activity of professional development, which gives drive, self-realization, energy, and happiness. A person should be active, serve as a driver of his own changes and make choices rather than handing over control of his life to others. The events of this spring have greatly raised the urgency of the topic, including the solution of internal conflicts of value: geopolitics has begun to influence professional self-determination much more actively. 

    In the talk, there will be approaches and schemes that allow technologically solving the problems of building an image of the future and your trajectory of movement.

    • Average
    • 40 min
    • SQA Days EA / 2
  • 19.08.2022
    Document states: button click and real actions

    We all realise that changing a task status only reflects the actual activities of the person who performed the task: writing staging or code, running test cases, or doing something else. And we never reduce the status change to simply moving the task to another column. But when the analyst thinks, for instance, about the work with the order, the actual activity is left out of his/her mind, and he/she thinks only about the work with the system. As a result, solutions are created that are not suitable for real life, although formally, the system has all the necessary features. 


    The talk will consider examples of such problematic situations. It will show how changing the status of documents reflects the task flow just like the familiar task flow on the board, including the decomposition of a large task into several tasks and bundling tasks into release packages.

    • Easy
    • 40 min
    • Analyst Days / 15
  • 25.01.2022
    How to create vision of future and your way to it - schemes for self-determination

    The modern world assumes that a person is looking for an image of his future and way to it. Standard career ladders are not relevant, the technology renovation demand to change specializations and learning. Unlike in the past, a job becomes not just a source of money, but also a professional activity that provides drive, self-realization, energy and happiness. A person himself must be active, serve as a driver of his own changes and make a choice, and not give control of his life to others: then you will get happiness and drive only with luck. 


    The talk includes approaches and schemes that allow technologically solving the problems of building an image of the future and its own trajectory. Previous versions of the report "How to build your professional path" https://mtsepkov.org/SelfDet2 focused on building a path to the image of the future, this one is expanded with approaches to building such an image of the future, which will give meaning to life, drive, self-realization and energy.

    • Average
    • 40 min
    • Analyst Days / 14
  • 02.10.2021
    Q&A: session with experts

    Our experts Maksim Tsepkov, Grigory Pechenkin, Alexander Baikin and Dmitry Bezugly will answer your questions.

    • Easy
    • Analyst Days / 13
  • 12.07.2021
    Design practice in different development cultures, technologies and paradigms

    There were several cultures of developing software projects. Each of them generate not only its own methods of project management but also its own ways of maintaining requirements and designing software. Programming paradigms changed: OOP came to replace the procedural approach, DDD appeared, and later the focus shifted to interfaces, usability and UX. 

    The architecture of the application also changed: first, they switched from client-server to three-tier, then the desktop client was replaced by the web with the concepts of MVC, MVVM and many others, then mobile applications appeared, reactive programming approaches appear, the application consists of many services, and the user switches between devices. All this required new approaches to design, new books appeared on the implementation of new concepts, while the old ones remained relevant. 

    The talk will be devoted to the logic of the development of methods and actual modern design problems that has no books and courses yet.


    • Average
    • 40 min
    • Analyst Days / 13
  • 16.01.2021
    Test design in a service architecture. Case study

    At last SQA Days, I told about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-SQA). This model allows you to design scenarios for checking asynchronously communicating services, including checking complex cases to ensure application resilience under various failures. 


    The talk will continue with a workshop in which the model's application will be explored using specific cases from the participants. Those whose cases are reviewed will get solution ideas, while others will see the model's practice, evaluate it and think about applying it to their work.

    • Average
    • 1h 30 min
    • SQA Days / 28
  • 16.01.2021
    Design an application in microservice architecture. Case study

    At last Analyst Days, I talked about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-AD). Such a model is consistent with the code and allows you to design changes as the application evolves and measures them against the complexity of the model's changes. 


    The talk will continue with a workshop in which the model's application will be explored through specific cases of the participants. Those whose cases are taken apart will receive ideas for solutions, while others will see the practice of working with the model, evaluating it, and thinking about applying it in their own work.

    • Average
    • 1h 30 min
    • Analyst Days / 12
  • 21.10.2020
    Application models for different programming paradigms

    For a long time, most applications were developed as large monoliths or systems of large modules, in which the processing of user requests could be represented as a procedure. And for testing, it was enough to check the application response for the user and the changes in the database. Based on this model, you can write test cases or checklists. 

    Today we see in use microservice architecture or the actor model with asynchronic messages, that can be lost during transmission or double operated and produce various complex effects. In this case, the classic application model is no longer sufficient for developing application testing - it does not provide an idea of ​​the problems that arise. Other models are needed that are adequate to the applied programming paradigms, based on which it is possible to develop scripts for checking complex cases that ensure the stable operation of the application in complex situations. Such models will be discussed in my talk.

    • Average
    • 40 min
    • SQA Days / 27
  • 27.12.2019
    Domain models for various programming paradigms

    During a long time, the main development approach was OOP. In this case, the construction of the object model of the subject area in the form of structures of references and documents and business logic in each object is a suitable design method for the analyst, and the developer easily transfer it to the code and the developer can change the model during realization if choose different way. Therefore, the model reflects the code, and complexity of model changes due to new requirements allow to evaluate the cost of development. However, other paradigms for the implementation of high-load applications, such as microservice architecture or the actor model, are becoming quite popular. In this case, analysts need different methods to describe the requirements and domain model, that they are adequate to the programming paradigms. I talk about some of them in my speech.

    • Average
    • 40 min
    • Analyst Days / 11
  • 15.12.2019
    How long does the tech spec remain?

    On the one hand, the Requirements Specification cannot die. The specification of requirements is a direct expression of the essence of a systematic approach and thinking. The more complex the system, the more accuracy and care required when making any changes. And the created systems do not become easier... 

    On the other hand, the Facts are a stubborn thing - honest process/architectural work with a cascade of formed specifications, classic As-Is To-be transitions come across much less often, from start-ups unicorns are born, and certainly there weren't any specifications in them... 

    We invite you to a discussion at the round table: 

    • Influence of two paradigms on Business and System Analysis: design and product. 
    • How to move from one paradigma to another with minimal personal and organizational losses.

    • Average
    • Analyst Days / 11
  • 26.11.2018
    Visual models of corporate application

    When designing complex enterprise applications, it is effective to use models that describe the subject area and the application itself in accordance with the Domain Driven Design approach. At the same time, good visualization is an indispensable attribute of the model. We will exchange experience in building an application architecture using three main models: a domain model, represented by a class diagram, a resource movement model, represented by accounting diagrams, and a workflow model based on a state diagram. All this is complemented by a business process model based on the activity diagram (activity diagram) and combined by the Archimate enterprise architecture model, and complemented by a system metaphor when it comes up to be invented. We will show examples of diagrams from real projects.

    • Average
    • 40 min
    • Analyst Days / 9
  • 31.10.2018
    Spiral dynamics model for multicultural communication of analysts

    Analysts work between the cultures of customers and the dev team. Even in one company, the cultures in divisions often vary dramatically. Analysts must have the competence to recognise the culture of users and customers quickly and align to it because the culture sets an implicit context and defines the meanings of concepts. Later they should transfer the meanings and implications to the development team based on their culture. Also, the sensation of the culture is significant during the maintenance of software to provide joint activities of people of different cultures.


    For fast and effective operations in various cultures, we can’t explore the corporate culture of a company or a division separately. We need to have cultural models in our kit. I'll talk about the spiral dynamics model that describes and operates with the values and culture of people and organisations. This talk continues and develops my lectures and articles about it, with a focus on the activities of the analysts.

    • Average
    • 40 min
    • Analyst Days / 9
  • 04.02.2018
    Solving the client’s problem rather than blindly doing the task

    Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.


    My presentation demonstrates how it can be done and provides the examples of how the immersion into the business plan of the project changes the ways of solving the problem.

    • Average
    • 40 min
    • Analyst Days / 8
  • 22.10.2017
    Tester and DevOps: Can you effectively resolve incidents using interface of your system?

    One of the tester's tasks is to look on the system through the helpdesk's eyes, to check whether the interfaces of the system can effectively resolve incidents according to SLA. Good resolution of the incident is not only to localize the error in the system, but also to help the user solve his business problem, find a workaround "here and now." Even in the case, then the cause of the problem is situated in the another system. Experience shows that this is often a weak point and requires the involvement of developers to directly analyze the data and correct it directly in the database.

    Based on my experience, I will tell you what functions are useful in the system for the effective resolution of incidents of inter-system integration, as well as incidents related to processing of special business situations and deals not provided for in the system. I think the story will help listeners look at their system in terms of compliance with the SLA.

    • Average
    • 20 min
    • SQA Days / 22
  • 13.09.2017
    Agile: what does the analyst need to know for action?

    Quite regularly you hear questions like the following: "We have a Scrum project, I need to write test cases for the testers, and I do not understand where I get information from." When you start to discuss, it turns out often that the word "Scrum" in the project they know some original design, while the inquirer is precisely sure that this is exactly Scrum. Meanwhile, Scrum and other Agile methods are a normalized model, about which you can read the documents, and from which you can get answers to this and other questions. But I will not provide the documents. I will show how to think in the logic of Agile mindset, get answers to this and other issues. Of course, as long as such values of the Agile Manifesto as working software, cooperation with customers and others do not seem to be a mere sound. I will show everything on real cases from listeners, solving their problems.

    • Average
    • 1h 30 min
    • Analyst Days / 7
  • 13.09.2017
    Stakeholders satisfation - two different meanings

    Later...

    • Average
    • 20 min
    • Analyst Days / 7
  • 22.03.2017
    Technology for Self-determination

    The problem of self-determination, planning and building own future becomes more and more actual nowadays, comparing to the past, when you determine only ~2 times, when define your profession and create your family, and moreover, this was pre-defined by your family. 

    Today you should do that regularly, moreover - in fast changing world, we see that especially in the IT-world, when technologies change rapidly.

    I've built and prepared a bunch of schemes helping to do that. I'll tell about them in my talk, and then I'm ready to solve your cases in the bar camp format. 

    • Easy
    • 40 min
    • SQA Days / 21
  • 20.01.2017
    Methods of requirements processing and design: what is the best for your project?

    Methods of design and requirements processing should ensure effective communication between team members and provide agile development of software with the possibility of further modernization. In the course of evolution, IT has accumulated a rich set of practices for projects with different complexity, scale and purpose: user story, use case, BDD, TDD, FDD, DDD, architectural work in SAF, and more traditional approaches. As it always happens with a wide range of tools, the problem of choice appears. Well-known tools or methods' comparision on model tasks are mostly preferred. But what's good for small tasks, not always suits long project.


    The report provides an overview of various practices that help to solve communication problems and the conceivable models of labour division within the team. The presentation also considers approaches to support the product development and modernization on a long life cycle. This report develops the ideas of my "Agile Engineering practices" post.

    • Average
    • 40 min
    • Analyst Days / 6
  • 31.08.2016
    Essence of Responsibility for Quality in Different IT-Projects and Sharing Principles

    Many QA professionals are convinced that IT industry has perfect vision of the quality and the means of its achievement. Therefore, the situation, when you switch to another company this ideal appears to be different, most values are being challenged, and common ways of working are very distinguishing, becomes an unexpected shock.

    The fact is that understanding of the quality criteria in IT-projects has come a long way from orientation to the perfect engineering product to meeting the steak-holders’ interests and providing prospects for business. Currently the awareness appears that different projects require different quality, and its criteria vary during the project.

    The report considers the space of quality criteria description and shared responsibility in the projects, which are to be examined for detailed examples.

    The speech develops my preceding reports (http://mtsepkov.org) about the evolution of quality criteria (AgileDays-2015) and sharing responsibilities (AnalystDays-2015).

    • Average
    • 40 min
    • SQA Days / 20
  • 16.03.2016
    Communication with different MindSet: Taxonomy vs Folksonomy

    An analyst starts his work with building a hierarchical structure of terms, where all clears and understandable for all stakeholders. This is a scientific mindset. However, there is an alternative - a tag cloud of concepts with associative chains. Therefore, thinks the child, when still cannot create logical structures. Previously we believed that a professional’s mindset should be based on hierarchical structure, but now comes the understanding that second mindset also works effectively: marketing, political technologies and media follows by this way.


    There was even a special word – folksonomy – contrary to the taxonomy for logical classification. Imagine that you describe a clear hierarchical architecture to a colleague and it seems he knows all the words. Only in his head instead of taxonomies - cloud folksonomy in which your design will fall quite differently.


    The analyst must be able to work with it, and in the talk, I will give a few methods based on schemes of SMD-methodology.

    • Average
    • 40 min
    • Analyst Days / 5
  • 02.02.2015
    Sharing responsibilities in the custom development

    Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing. The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

    • Easy
    • 40 min
    • Analyst Days / 4
  • 06.11.2014
    Spiral Dynamics: understand values - and act

    Last autumn my range of vision was extended by such model as Spiral Dynamics. It gave me systematic viewpoint of many trends such as community development or IT (as well as not IT) management.

    I spoke about the Spiral Dynamics itself on Agile Days conference. Here I’m going to explain how it influences on understanding of processes used in the company, in the industry and in the world in general. Also I'll unfold how it might give you knowledge about how you can find proper place in these processes and how to make decisions more wilfully.

    I’m going to do it from Software Test Engineer point of view. Precisely from Software Test Engineer who is going to grow into Manager. I’ll consider some important questions and provide Spiral Dynamic’s answers on them.

    • Average
    • 40 min
    • SQA Days / 16
  • 29.10.2014
    Sharing responsibilities in the custom development

    Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing. The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

    • Easy
    • 40 min
    • SPM Conf / 4
  • 01.04.2014
    DDD - model instead of requirements

    There are many methods to develop requirements (user story, use case and so on), but all of them mainly describe behavioural aspects. But how to work in the sphere of complex business requirements where objects change their behaviour as the context may admit? Domain-Driven Design (DDD) is an approach that allows to create clear and clean vision of domain area. Ubiquitous language gives ground for communication between customers, analytics, developers, testers and end-users. And we can use models developed in this language instead of traditional requirements, which are used only to build models in this process, and then they lost their actuality. This approach significantly simplifies design process and reduces risks in complex IT-projects enabling business professionals to fully verify Models. And then, while in operation, Models allow to develop and expand software system efficiently for many years following changes of customer’s business processes.

    • Average
    • 40 min
    • Analyst Days / 3
  • 28.02.2014
    You and Customer: solve problems instead of operate requirements

    Who among of us has not faced with a situation when customer requirements were implemented thus he did not required at all? Hence, the implementation were changed many times, unless excluded. In the report we will talk about establishing that kind of relationships with customer when main goal is to solve customer problems and not just to working out requirements. This report is not about “how to live”, it based on real (!) cases that was arising in relationships with customer. We would like propose a method establishing relations, analyze the combination of formal and informal communication, as well as deal with labor costs and payment issues. We also will consider the psychological side on different project phases. There is no way without that, because teamwork assumes no formal interaction, but communication and collaboration, with establishing partnerships for produce the value. As a result, this approach leads to mutual success and improving realization of the potentials of you and your team.

    • Easy
    • 40 min
    • SQA Days / 15
To leave a feedback you need to

or
Chat with us, we are online!