The post has been translated automatically. Original language: Russian
Every product, analyst, or project manager has at least once heard a phrase from a business: "Listen, this is a great report, but add another column to it — for example, Programs or Sources of funding. We just need to take a look, it's fast!"
You shake your head, resort to a programmer, say: "Listen, put one field in there, it's done for five minutes." The developer sighs, twists something... and then the fun begins. The report breaks down: the amounts start to double, empty lines appear instead of data, and if the user decides to swap the groupings, everything collapses into one common pile, where nothing is clear. As a result, a simple task freezes in the sprint for a week.
I recently came across a similar story myself and realized one thing: in any large systems and databases, "just adding a field" is an adventure.
So that you don't step on this rake and keep your nerves (both for yourself and the developers), I've sketched out a simple checklist. Check these 5 things BEFORE putting a task in the backlog.
1. Was the data collected at all?
The most banal jamb: a business asks for some kind of analytics to be included in the report (for example, the same Expense Programs), but forgets to check whether it was filled out by accountants or managers before that day. If the field appeared in the documents only yesterday, then you will see nothing but emptiness in the report for the last month or quarter.
- The rule: First, we check whether this account was kept in the database at all.
2. Check for "rearrangement of seats"
Users love to twist reports however they want. Today they need to look at the data in the context of "Counterparty $ ightarrow$ Agreement $ ightarrow$ The program". Tomorrow they will move the Program to the first place. If the developer rigidly prescribes the logic of the totals in the code for one option, then with any permutation the report will go blind and give only the total amount without details.
- The rule: Immediately write in the task that the structure of the totals should adapt to any whims of the user.
3. Order matters.
In databases, everything is laid out strictly on the shelves. If the system is used to having the Counterparty on the first shelf and the Contract on the second, you can't just swap them on the accounting account itself. The code will start looking for one thing, find another, and the report will give you the kind of mess that you will then catch for weeks.
4. Database freeze test
On a test base with three cripples and two postings, any report flies in a second. But when you add new sections and complex groupings to the real database, the load grows like an avalanche. Before you send the report to the prod, make sure that it does not hang the entire company in the middle of the working day.
5. The Ghosts of the configurator
This is a purely technical joke that I came across: if a developer created a new subconto in the Configurator, updated the database, and then realized that it was not needed and deleted it, the platform uses it... it won't delete it. She will remove it from the code, but leave it in the database itself as "custom" so as not to break old documents. And this "ghost" will get in the way in the system until it is cleaned by hand in Enterprise mode.
What is the conclusion?
Don't believe the phrase "there's work for a couple of minutes" when it comes to reports and analytics. Respect the database architecture, ask the business the right questions on the shore, and your developers will thank you.
Еще несколько лет назад создание цифрового продукта занимало месяцы или даже годы. Нужно было искать разработчиков, дизайнеров, копирайтеров, маркетологов и тратить значительные средства еще до появления первой версии продукта.
Сегодня ситуация изменилась. Благодаря современным AI-инструментам один человек или небольшая команда способны за месяц пройти путь, на который раньше уходило полгода. Искусственный интеллект помогает быстрее исследовать рынок, сформировать концепцию, написать код, создать дизайн интерфейса, подготовить документацию, разработать маркетинговые материалы и даже получить первые отзывы пользователей.
В этой статье мы разберем, что действительно можно успеть сделать за 30 дней, если грамотно использовать современные технологии и сосредоточиться на создании MVP — минимально жизнеспособной версии продукта.
Первая неделя — поиск идеи и анализ рынка
- Как выбрать проблему, которую действительно стоит решать.
- Как проверить спрос без больших затрат.
- Как определить целевую аудиторию и конкурентов.
- Как сформировать ценностное предложение.
Вторая неделя — разработка MVP
- Создание структуры продукта.
- Разработка интерфейса.
- Написание первой версии кода с использованием AI.
- Подключение базы данных, авторизации и основных функций.
Третья неделя — тестирование и доработка
- Поиск ошибок.
- Получение обратной связи от первых пользователей.
- Улучшение пользовательского опыта.
- Добавление только тех функций, которые действительно нужны.
Четвертая неделя — запуск продукта
- Публикация проекта.
- Создание лендинга.
- Подготовка презентации.
- Первое продвижение через социальные сети, профессиональные сообщества и тематические площадки.
- Анализ первых пользователей и план дальнейшего развития.
Share
