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.
Многие стартапы в Казахстане умирают в «долине смерти» еще до запуска, потому что сжигают все бюджеты на этапе разработки. Раньше нужно было нанимать бэкенд, фронтенд, дизайнера и QA. Сегодня один фаундер, вооруженный ИИ, заменяет целую команду. Это не фантастика, а новая реальность.
1. Проверка гипотезы (Неделя 1: Разведка)
- Вместо того чтобы гадать, что нужно рынку, используйте LLM (например, Claude или GPT-4) для анализа трендов Astana Hub и мировых рынков.
- Совет: Прогоните через ИИ данные о конкурентах и попросите его найти «слабое звено» в их продуктах или отзывы пользователей с жалобами. Это и есть точка входа для вашего MVP.
2. Разработка «на лету» (Неделя 2: AI-augmented coding)
- Откажитесь от написания кода с нуля. Используйте Cursor или GitHub Copilot.
- Главная задача здесь — не написать идеальный код, а собрать рабочий прототип. Ваша цель — скорость. ИИ-агенты сегодня позволяют генерировать фронтенд-интерфейсы из эскизов (нарисованных от руки) за считанные минуты.
3. Интеграции и «склейка» (Неделя 3: No-code + AI)
- Не тратьте время на написание своей системы авторизации или платежного шлюза. Используйте готовые AI-интеграции (Zapier, Make), чтобы соединить ваш продукт с CRM, Telegram-ботом или базой данных.
- Важный нюанс: В Казахстане важно сразу предусмотреть интеграцию с локальными API (например, Kaspi/Halyk или системы верификации по номеру телефона), ИИ отлично помогает писать скрипты для этих связок.
4. Запуск и первые метрики (Неделя 4: Growth Hacking)
- Запуск — это не день, когда «все идеально». Это день, когда ваш продукт впервые увидели 100 реальных пользователей.
- Используйте ИИ для создания контент-плана в Instagram/LinkedIn на месяц вперед.
- Ваша цель на этой неделе — получить первую обратную связь. Если пользователи говорят, что функция неудобна — уберите её. Если просят что-то добавить — ИИ напишет этот код за час.
Что добавить от себя, чтобы стало еще лучше:
«Стек инструментов»: Для кода: Cursor, Replit.Для дизайна: v0.dev, Relume.Для маркетинга: Midjourney, Perplexity (для анализа рынка).
Share
