The post has been translated automatically. Original language: Russian
The repository stores the history of the code. But the product story is usually much broader: it has founders, employees, contractors, external components, data, and solutions that once seemed obvious.
In the comments to the first article, we talked about the moment when the same question has to be collected from scratch for the second time — from people's memories, old chats and documents. The history of product creation consists of just such questions: how did it appear and on what basis does the company use everything from which it is assembled?
At first glance, the answer is simple: "We created it."
But the first version could have appeared before the company was registered. The interface was made by a contractor, and a separate module was made by another team. Inside there are open-source libraries, an external API, purchased images or fonts. The data for the first tests were collected separately. And some texts, designs, or code have already been created using AI tools.
As long as there are people around who remember all this, the story seems complete. Then someone leaves, the product changes architecture several times, documents remain in old folders, and before an investor, a large client, or entering a new market, the team has to deal with archeology.
For the first recovery, you do not need to immediately check the entire product and pick up every document for several years. We need a clear route.
First, determine what exactly we are restoring
The creation story is not a corporate chronicle or a list of everyone who has ever participated in a project. For a practical task, it is enough to link four things:
1. Product element — what exactly was created or obtained from the outside.
2. Source — who created it, transmitted it, or provided it.
3. The basis of use is an employment relationship, contract, license, terms of service, or other basis.
4. Next— the team can confirm this connection now.
It is better to start not with the entire code base, but with one critical contour: for example, a module without which the product does not work; an interface that the customer sees; a main database; a mobile application; a model or AI function.
This is how the work gets a boundary. Otherwise, one question quickly turns into an endless inventory of everything that has ever been opened on the team's laptops.
Step 1. Decompose the product into its elements
In the contract folder, the product often looks like a single object. In reality, it is assembled from different parts.:
- source code, individual modules and scripts;
- architecture, technical documentation and tests;
- interface, design system, illustrations, texts and fonts;
- databases and training sets;
- open-source libraries and other dependencies;
- external APIs, cloud services, and licensed software;
- models, prompta, settings and materials created using AI;
- domains, names, and other brand elements.
On the first pass, there is no need to argue which legal regime applies to each line. First, it is important to see the composition of the product. What is not on the map cannot be verified or consciously accepted as a risk.
Step 2. Build a timeline
It is more convenient to restore the history not by the current team structure, but by product versions.:
- a prototype before the company appeared;
- the first working version;
- connecting contractors;
- major redesign or migration to another architecture;
- launching the mobile app;
- adding data or an AI component;
- current version.
For each point, it is useful to ask: what appeared, who participated then, and in what capacity?
The last part is especially important. One person could first help the founder informally, then become a contractor, and later an employee. Today, the team perceives his contribution as a single whole, but the documents and grounds may have differed in different periods.
Step 3. Look not for one perfect document, but for a collection of traces.
Git really helps: it shows commits, dates, branches, and the development of individual parts of the code. But he won't tell the whole story. It is not always clear from the repository in what capacity the person worked, where the external fragment came from, what conditions the library had, or what was happening outside the code.
Therefore, different sources are useful.:
- repositories and revision history;
- tasks in Jira, Linear, Trello or another tracker;
- Figma and other version files;
- technical specifications and release descriptions;
- contracts, appendices, acts, invoices and correspondence;
- documents on hiring and changing roles;
- licenses and terms of external services;
- old demos, tests, and letters to clients.
None of these traces by itself is bound to provide a definitive answer. Their task is to help restore a continuous chain: element → person or source → conditions → current use.
Step 4. Do not confuse a lack of response with a violation
During such a parsing, it is very easy to turn every empty cell into a red flag. This prevents the team from honestly assembling the picture.
Four statuses are enough for the first pass:
- confirmed — the source, the basis and the evidence are clear;
- we need to verify — the answer is most likely known, but confirmation has not yet been found.;
- external component — you need to check the license, terms of use or restrictions;
- gap — it is unclear who created the element or why the company has the right to use it.
"We don't know" is not a legal conclusion. This is an honestly defined uncertainty that can already be dealt with.
The exact answer about the ownership of rights always depends on the jurisdiction, contracts and circumstances of creation. Therefore, such a card is not a substitute for a legal assessment. It gives it a factual basis — and does not allow you to waste time analyzing a product that exists only in general terms.
What to do if the required document is not available
Sometimes the necessary agreement, application, or act really does not exist. The most dangerous reaction here is to try to quickly make the past more accurate than it was.
First, you should save what is still available: repositories, task history, version files, correspondence, and a list of people who participated in the work. Then talk to them and record the reconstructed sequence of events, separately noting the confirmed facts, memories and places where the versions differ.
Such a record by itself will not replace the missing document and will not resolve the issue of rights. But it will not allow you to lose the last traces and will allow you to decide in detail what can be confirmed, what needs to be processed now, and where a separate legal assessment is needed. The document signed today should also not be perceived as a magic time machine: the way to close the previous period depends on the specific situation and the applicable law.
After that, it is useful to close the way for a repeat breakup. For example, you can agree that a new contractor does not start work until the result, the conditions of its use, and the place where the confirmations are stored are indicated in the card. Or that with each major release, the person in charge checks new dependencies, external materials, and AI tools.
Step 5. Set priorities
All gaps do not need to be closed at the same time. First, I would look at the elements that:
1. determine the main value of the product;
2. they appeared before the company was founded or when the legal entity was changed;
3. Created by contractors, former employees, or external teams;
4. contain third-party code, data, content or components with terms of use;
5. They are needed for the next event — a deal, an investment round, an enterprise client, or market entry.
AI tools are worth mentioning separately. Not because any use of them automatically creates a problem, but because after a few months, the team often no longer remembers exactly where they were used, what materials were loaded into them, and what conditions were in effect at that moment.
What does the minimum work card look like?
To get started, just one table with eight fields is enough.:
- product element;
- version or period of appearance;
- who created or provided;
- the role of this person or organization at that time moment;
- a document, license, or other basis;
- found confirmations;
- limitations and open questions;
- next action and responsible.
There is no need to immediately turn it into a complex system. The value appears at the moment when the team can open one line and see not only the name of the component, but also the entire logic of its appearance in the product.
The approach coincides with the basic logic of the WIPO IP audit: first identify the assets used, then check the grounds of ownership or use, third-party rights and gaps. But for a growing team, the first step may not be a large audit, but one critical product outline.
Fifteen-minute check
Take one element, without which the product will lose a significant part of its value, and try to respond in fifteen minutes.:
1. Who created it or where did it come from?
2. When did this happen?
3. What was the creator's relationship with the company then?
4. On what basis does the company use the element today?
5. Where is the confirmation?
6. What external conditions or restrictions are still in effect?
If the answers are found quickly and match the different team members, the story is already in good shape.
If you have to go to one person, search for an old chat and remember the file name, you have found the beginning of an archaeological dig. And it's better to hold them now, without a deadline from the investor or the client.
I'm wondering which source most often saves the product history of other teams: a repository, a task tracker, contracts — or a person who still remembers what it was like?
Мы научились запускать исследования, анализ и подготовку документов быстрее, чем успеваем их понять. Возможно, следующий навык работы с AI — вовремя остановиться.
Теперь почти для любого вопроса можно организовать небольшую исследовательскую экспедицию.
Один агент соберёт рынок. Второй сравнит документы. Третий найдёт риски. Четвёртый предложит варианты. Через несколько минут на экране появляются таблица, презентация, три сценария и подробный отчёт с приложениями.
Мы читаем первые абзацы, пробегаем глазами выводы, нажимаем Accept и несёмся дальше.
Иногда через неделю запускаем почти такое же исследование ещё раз — потому что уже не помним, что именно было в первом и куда его сохранили.
Мы стали производить информацию быстрее, чем успеваем её переварить.
Узкое место никуда не исчезло
До нейросетей подготовка большого обзора требовала времени. Само ограничение заставляло заранее подумать: зачем он нужен, кто будет его читать и какое решение должно появиться в конце.
Теперь стоимость первого черновика резко снизилась. Но чтение, проверка, осмысление и принятие решения по-прежнему требуют человеческого внимания.
AI не убрал узкое место. Он перенёс его из производства информации в работу с ней.
Из-за этого легко перепутать количество созданного с объёмом сделанного. На диске лежит исследование. В чате есть стратегия. В таск-трекере прикреплён анализ. Но если никто не проверил исходные допущения, не связал выводы с решением и не понял, что изменится дальше, знанием всё это ещё не стало.
Это просто материал, который ждёт обработки.
У каждого ответа есть скрытая стоимость
Кнопка Generate создаёт результат за секунды. После неё начинается менее заметная работа.
Материал нужно:
- прочитать хотя бы в объёме, достаточном для понимания;
- проверить там, где ошибка имеет значение;
- сопоставить с тем, что команда уже знает;
- превратить в решение или действие;
- сохранить в понятном месте либо удалить;
- обновить позже, если от него продолжает что-то зависеть.
Каждый новый отчёт создаёт небольшое обязательство на будущее. Если обязательства копятся быстрее, чем команда успевает их закрывать, появляется что-то похожее на информационный долг.
Он не всегда заметен. Папки заполнены, документы выглядят убедительно, а ответы на одни и те же вопросы приходится собирать заново. У разных людей появляются разные версии «последнего анализа». Старые выводы продолжают цитировать после того, как изменились данные и условия.
Информационная гигиена начинается до запроса
Когда материалов уже слишком много, естественная реакция — искать ещё один инструмент для их хранения, тегирования и суммаризации.
Иногда он действительно нужен. Но первая развилка появляется раньше — до запуска нового исследования.
Полезно закончить одну фразу:
После этого материала мы должны решить…
А затем ответить ещё на четыре вопроса:
1. Какое решение или действие должно измениться?
2. Какой минимальный результат для этого нужен?
3. Кто прочитает материал и что именно должен проверить?
4. Что произойдёт с ним после решения: сохранить, обновлять или удалить?
Если фразу закончить не получается, возможно, запрос ещё не готов. Если для решения достаточно сравнительной таблицы на одной странице, не обязательно заказывать сорок страниц текста. Если никто не назначен читателем, отчёт с большой вероятностью станет ещё одним аккуратно оформленным файлом.
Не всё созданное должно пережить задачу
Мы привыкли воспринимать удаление как потерю. Поэтому сохраняем промежуточные версии, повторные краткие пересказы, полные выгрузки, варианты формулировок и исследования, которые уже выполнили свою функцию.
Но у информации тоже может быть срок жизни.
После завершения задачи обычно стоит сохранить:
- принятое решение и его логику;
- источники и факты, на которые оно опиралось;
- важные ограничения и то, что осталось неизвестным;
- обещания, сроки и следующие действия;
- знание, которое действительно пригодится повторно.
Остальное может остаться временным материалом. Не каждый диалог с нейросетью должен становиться частью корпоративной памяти. Не каждый черновик заслуживает места в личной базе знаний.
Удаление, срок хранения и осознанное «этого достаточно» — тоже элементы информационной гигиены.
Мозг нельзя вынести за скобки
Нейросеть может сократить длинный отчёт. Потом сократить его summary. Затем собрать summary нескольких summaries.
Но момент, в котором человек понимает смысл, замечает противоречие и принимает ответственность за решение, всё ещё требует времени и тишины.
Возможно, следующий уровень AI-продуктивности будет измеряться не количеством сгенерированного. А тем, насколько хорошо мы умеем выбирать, что заслуживает внимания, проверки и памяти — и что можно спокойно удалить.
У вас уже появились правила не только для того, что AI может создать, но и для того, что люди действительно должны прочитать?
Share
