The post has been translated automatically. Original language: Russian
This is my first text in the Astana Hub community, so I won't start with a big methodology, but with one observation from working with technology teams.
A product often grows faster than the system around it. And at an early stage, this is normal.
The team is small, people are constantly in touch. The founder remembers who wrote the first version. The CTO knows which services are connected. The contract with the contractor can be found in the correspondence. The decision to try a new AI tool is made in one conversation.
As long as everyone is nearby and the context is still fresh, this design works.
And then there is a question from the outside.
First, everything fits in the head of the team
A young product rarely has a separate process for each decision. And it's not always needed.
If you describe all possible rules at the start, the team will spend time on a system that has nothing to maintain yet. Therefore, a lot is based on trust, speed and direct communication.
But with the product, the number of connections grows. A new developer is coming. A contractor is being activated. Another cloud service is coming up. The client is requesting an unusual integration. Employees are starting to use AI assistants in their work. The company is moving beyond the first market.
At some point, the context no longer fits in one head. At the same time, the product itself can continue to work quite well.
Then comes the external question
Usually, this transition becomes noticeable not during an internal discussion, but before a specific event.
A large customer asks which suppliers receive their data. The investor wants to understand how the key elements of the product were created. The partner specifies who is responsible for the new integration. The government customer requests to see the roles, procedures, and records. Entering a new market raises issues that previously seemed local.
Each question individually sounds quite reasonable. The difficulty is different: the answers may be in different places and do not add up to one picture.
In one software project, I came across just such a situation. The product existed, and the team was developing it, but information about rights, data, and decisions was distributed among people and documents. Locally, each fragment made sense. There was no common map yet.
This does not necessarily mean that the team was doing something wrong. Rather, the product has moved to a stage where the previous way of storing context is no longer sufficient.
Three places where the map usually ends
The first is the product creation story.
Someone wrote the code before the company was registered. The contractor did something. Libraries, external APIs, images, datasets, or materials created using generative AI appeared inside. The team knows that they are using it all. But the history of the appearance of each critical element is not always fully assembled.
The second is the movement of data and tools.
The user sees one interface. It may contain cloud infrastructure, analytics, support, spreadsheets, external services, and AI tools for employees. Each team member has their own piece of this picture, but the overall scheme quickly becomes outdated.
The third is the movement of solutions.
The phrase "this is a CTO issue" does not yet explain who can connect a new supplier, coordinate data transfer, accept an exception, or stop the release. When a decision is made in a conversation, it is useful to understand what will remain after the conversation and who will update the information later.
A little check before the next step
You don't need a big audit to get a first look at this system. You can take one event that the company really needs: a new enterprise client, integration, an AI function, an investment round, or entry into another market.
And ask four questions:
1. Which people, services, data, and components will be affected by this event?
2. What decisions will have to be made and who will be able to make them?
3. Where are the answers now: in the document, in the system, or in the memory of a particular person?
4. What will change after the launch and who will update the map?
If two team members respond differently, this is already a useful result. If the answer exists only in one person's memory, this is a good point for the first small change.
Sometimes one live registry becomes such a change. Sometimes there is a clear route of approval. Sometimes it is enough to write down who returns to the question and at what event.
The size of the solution is less important here than its relation to the actual work of the team.
What I want to talk about next
A system around a product rarely appears in one project. It grows with new people, customers, suppliers, and markets.
In the following texts, this topic can be analyzed in more depth.: how to restore the history of product creation, how to draw a working data map, what is changing with the advent of AI tools, and how not to turn it all into a document library that no one opens.
In the meantime, I'm interested in starting with the experience of the community itself.: What was the first external question that made your team look not only at the product, but also at the system around it?
Это мой первый текст в сообществе Astana Hub, поэтому начну не с большой методологии, а с одного наблюдения из работы с технологическими командами.
Продукт часто растёт быстрее системы вокруг него. И на ранней стадии это нормально.
Команда небольшая, люди постоянно на связи. Фаундер помнит, кто написал первую версию. CTO знает, какие сервисы подключены. Договор с подрядчиком можно найти в переписке. Решение попробовать новый AI-инструмент принимается за один разговор.
Пока все находятся рядом и контекст ещё свежий, такая конструкция работает.
А потом появляется вопрос извне.
Сначала всё помещается в голове команды
У молодого продукта редко есть отдельный процесс для каждого решения. Да он и не всегда нужен.
Если на старте описывать все возможные правила, команда потратит время на систему, которой пока нечего обслуживать. Поэтому многое держится на доверии, скорости и прямой коммуникации.
Но вместе с продуктом растёт количество связей. Приходит новый разработчик. Подключается подрядчик. Появляется ещё один облачный сервис. Клиент просит необычную интеграцию. Сотрудники начинают использовать AI-ассистентов в работе. Компания выходит за пределы первого рынка.
В какой-то момент контекст уже не помещается в одной голове. При этом сам продукт может продолжать работать вполне хорошо.
Потом приходит внешний вопрос
Обычно этот переход становится заметен не во время внутреннего обсуждения, а перед конкретным событием.
Крупный клиент спрашивает, какие поставщики получают его данные. Инвестор хочет понять, как создавались ключевые элементы продукта. Партнёр уточняет, кто отвечает за новую интеграцию. Государственный заказчик просит показать роли, процедуры и записи. Выход на новый рынок поднимает вопросы, которые раньше казались локальными.
Каждый вопрос по отдельности звучит вполне разумно. Сложность в другом: ответы могут находиться в разных местах и не складываться в одну картину.
В одном software-проекте я встретила именно такую ситуацию. Продукт существовал, команда его развивала, но сведения о правах, данных и принятых решениях были распределены между людьми и документами. Локально каждый фрагмент имел смысл. Общей карты ещё не было.
Это не обязательно означает, что команда что-то делала неправильно. Скорее продукт перешёл в стадию, для которой прежнего способа хранить контекст уже недостаточно.
Три места, где карта обычно заканчивается
Первое — история создания продукта.
Кто-то написал код до регистрации компании. Что-то сделал подрядчик. Внутри появились библиотеки, внешние API, изображения, датасеты или материалы, созданные с помощью генеративного AI. Команда знает, что всем этим пользуется. Но история появления каждого критичного элемента не всегда собрана целиком.
Второе — движение данных и инструментов.
Пользователь видит один интерфейс. За ним могут находиться облачная инфраструктура, аналитика, поддержка, таблицы, внешние сервисы и AI-инструменты сотрудников. У каждого участника команды есть свой кусок этой картины, но общая схема быстро устаревает.
Третье — движение решений.
Фраза «это вопрос CTO» ещё не объясняет, кто может подключить нового поставщика, согласовать передачу данных, принять исключение или остановить релиз. Когда решение принимается в разговоре, полезно понимать, что останется после разговора и кто обновит информацию позже.
Небольшая проверка перед следующим шагом
Для первого взгляда на эту систему не нужен большой аудит. Можно взять одно событие, которое действительно предстоит компании: новый enterprise-клиент, интеграцию, AI-функцию, инвестиционный раунд или выход на другой рынок.
И задать четыре вопроса:
1. Каких людей, сервисов, данных и компонентов коснётся это событие?
2. Какие решения придётся принять и кто сможет их принять?
3. Где сейчас находятся ответы: в документе, системе или в памяти конкретного человека?
4. Что изменится после запуска и кто обновит карту?
Если два участника команды отвечают по-разному, это уже полезный результат. Если ответ существует только в памяти одного человека, это хорошая точка для первого небольшого изменения.
Иногда таким изменением становится один живой реестр. Иногда — понятный маршрут согласования. Иногда достаточно записать, кто и при каком событии возвращается к вопросу.
Размер решения здесь менее важен, чем его связь с реальной работой команды.
О чём хочется поговорить дальше
Система вокруг продукта редко появляется за один проект. Она растёт вместе с новыми людьми, клиентами, поставщиками и рынками.
В следующих текстах эту тему можно разобрать глубже: как восстановить историю создания продукта, как нарисовать рабочую карту данных, что меняется с появлением AI-инструментов и как не превратить всё это в библиотеку документов, которую никто не открывает.
А пока мне интересно начать с опыта самого сообщества: какой внешний вопрос первым заставил вашу команду посмотреть не только на продукт, но и на систему вокруг него?
Share
