Артем Воронов

любой B2B SaaS - это в первую очередь понимание болей бизнеса и каналов привлечения клиентов. Код и архитектура даже не вторичны, они на самом последнем месте до тех пор, пока нет стабильного потока клиентов и денег. Напротив, даже самое забагованное и неудобное говно будет приносить деньги, если оно решает проблему и за это платят, и не важно что там под капотом.

ИИ за тебя роадмап не прочитает, это полностью твоя ответственность. И то в каком порядке и как ставить задачи. Кнопки "сделай все за меня и идеально" нет и не будет.

Так что закатываешь рукава и сам бьешь свое решение на задачи. Под каждую задачу:
- пишешь спецификации, можно вместе с клодом или кодекс. Если достаточно продвинут, можешь делать executable specifications, которые будут твоими тестами. Челенджить надо до упора, особенно если не понимаешь решения, которые тебе предлагает клод.
- как только удовлетворен спецификацией - запускай в работу клода.
- проверяй результат, как функционально так и по коду. ИИ будет тебе периодически подбрасывать дичь, просто проси исправить. Дожимай каждую задачу до конца и переходи к следующей.

Как только минимальный набор фич готов - идешь продавать.
Как появились первые клиенты, начинаешь навешивать аналитику и прочие радости взрослого продукта.

Ну и самое главное, не городи переусложненное техническое решение из 100 микро сервисов и MCP пока тебе за это не платят.

В целом наблюдаю, тренд что БА и СА постепенно совмещаются в одну роль - БСА, даже в крупном энтерпрайзе. По крайней мере вижу это в своей отрасли.

Как уже написали в других ответах:
- Без глубокого понимания доменной области БА неэффективен. И это не то, чему учишься по книжкам. Это в первую очередь намеренность и сотни часов общения с бизнесом.
- БА не должен писать код, но обязан понимать о чем говорят разработчики. Иначе на этапе постановки задачи будут постоянные недопонимания.

Одна из больших проблем - слабый БА создает дополнительную работу для команды, которая в конечном итоге будет выкинута. В случае больших команд и продуктов, потери могут составлять сотни тысяч евро и дополнительно задержки разработки. Из-за этого за последние 2 года пришлось поменять 3 БА в своей команде.

Начинающий системный аналитик, еще и на фрилансе - это что-то из области фантастики. Единственный рабочий вариант который мне встречался, это контракты на 3-9 месяцев для уже опытных аналитиков, но это не Upwork, и тем более FL.ru, Kwork.

Как нанимающий менеджер, я жду от системного аналитика:
- глубокого практического опыта проектирования информационных систем, желательно с бэкграундом разработки\бизнес-анализа
- понимание архитектуры, плюсов и минусов монолита, микро-сервисов, где NoSQL воткнуть и т.п.
- знания как на все это дело навесить метрики и логирование
- понимание конкретного бизнес-домена и напористости, чтобы челенджить решения которые будут навязывать стейхолдеры, другие аналитики.

То есть в идеале, должна быть карьерная траектория типа: разработчик -> системный аналитик, бизнес-аналитик -> системный аналитик, архитектор -> системный аналитик. Как минимум несколько проектов за плечами и набитые шишки.
Просто взять системного аналитика-новичка без соответствующего предыдущего опыта - это как посадить за штурвал самолета человека, который до этого управлял только самокатом. Теоретически взлететь сможет, но с высокой долей вероятности разобьет самолет и разнесет все вокруг.

Можешь решить топорно, путем подключения статично словаря в csv файле. Но это прям неинтересно.

Лучше сделай вызов к OpenAI API или GigaChat, подтягивай объяснение слова и кэшируй результат в любом key-value хранилище для последующего переиспользования. Заодно реализуешь асинхронные вызовы, обработку сетевых ошибок, retry-логику и т.п.

Результат можно отобразить в тултипе, как уже предложил VoidVolker

Не переусложняй:
1. Маленький проект, быстрый прототип - можешь смело держать все в одном проекте и не париться.
2. Долгоживущий проект с несколькими микросервисами, сложной бизнес логикой и т.п. - выделяй микросервисы в отдельные проекты, фронт держи отдельно.

Есть как минимум два подхода к решению этой проблемы:
- Посмотреть на чем сделаны аналогичные продукты, например Plex https://himalayas.app/companies/plex/tech-stack
- Делать на чем умеешь и по мере роста продукта заменять технологии. Исходя из формулировки вопроса, речь идет о pet проекте. Если так, то не стоит тратить дни на поиск идеального решения, надо просто начать делать. В ходе реализации придет понимание того, что действительно нужно.

Когда нанимаю себе бизнес аналитиков, смотрю следующие моменты в порядке важности:
- аналитические способности. Какие человек задает вопросы перед тем как начать работать над задачей, как подходит к выбору источников информации, как выстраивает логику решений и оценивает стоимость реализации
- софт скилз. Насколько хорошо человек умеет общаться и выстраивать отношения как со стейкхолдерами, так и с другими командами и разработчиками.
- системность в ведении документации и написание user stories. По моему опыту несистематичный аналитик увеличивает расходы на реализацию проектов временами на 50-100%, в особо запущенных случаях на 300%+
- понимание доменной области. Это наименее важный пункт, нормальные аналитик за 3-6 месяцев может разобраться даже в самых специфичных доменах.

Не смотрю на:
- курсы и образование, вообще ни о чем не говорят
- формальную сертификацию. Работал с людьми прошедшими сертификацию IIBA, которым приходилось объяснять базовые вещи
- технические скиллы. Даже самый слабый аналитик из тех с кем работал, за неделю освоил основы SQL и начал самостоятельно забирать данные для анализа. Сейчас при помощи ChatGPT проще простого подтягивать технические навыки

Любой современный треккер позволяет настроить частоту передачи и отправлять данные в API.
По большему счету для обычных нужд подходит любой треккер и частота передачи раз в 1-10 минут.
Если нужно еще мониторить показания топливных датчиков и дополнительной телеметрии надо брать что-то подороже.
Ну если задача стоит трекать спортивные мероприятия, необходимо подбирать специфичные профессиональные датчики.

Звучит как задача для Elastic (хранение логов) + Kibana для визуализации.

Сейчас работаю над аналогичной задачей:
- сотни источников данных, на разных языках и в разных региональных форматах
- данные фрагментированы, разные атрибуты одной и той же записи приходят из разных источников
- встречаются опечатки и мусор в данных

Что попробовали, но работает не очень:
- собственный DSL. Слишком дорого в поддержке, онбоардинг разработчиков превращается в ад.
- Использование шаблонов и маппингов специфичных для каждого истончика с помощью специфичного софта типа Xceptor. Опять таки дорого в поддержке и недостаточно гибко.

Что работает хорошо:
- Разделение процесса на этапы, все по классике Data Science: очистка данных от мусора, стандартизация форматов и т.п. Это позволяет не дублировать одну и ту же логику в отдельном обработчике для каждого источника, а консолидировать правила в одном месте.
- Elastic для перевода, синонимов и обработки опечаток
- Кросс проверки с дополнительными источниками данных, где это возможно

Notion как алтернатива Obsidian. Ультра просто и удобно.

Я собрал 3 подобных сервиса, как для Glonass/GPS, так и для AIS. В текущем решении 180 000 единиц транспорта отслеживается. Вот несколько базовых моментов из опыта:
1. Приборы отправляют данные на сервер сами, а не наоборот. Твоя задача принимать и быстро сохранять данные в бд. В какой - не важно. У меня хорошо работает связка из реляционной бд для оперативных данных типа текущего положения, nosql для архива.
2. Протоколов у трекеров огромный зоопарк, у каждого производителя свой. Не привязывай свою реализацию к конкретному протоколу. Сделай общий API для сохранения данных в базу, а затем уже подключай протоколы по мере необходимости.
3. Если тебе нужен геофенсинг, сразу закладывай event-driven архитектуру. Опять таки не важно какой ты возможешь брокер сообщений.
Все остальное вторично. Для отображения данных хоть на любом low-code забирай данные напрямую из оперативной базы и отображай на карте.

решал подобные задачи связкой TeamCity + Jira + Confluence: При деплое на Prod TeamCity подтягивала список заплоенных stories из GIT. Далее небольшой скрипт формировал страницу в Confluence, подтягивая детали stories из Jira. Завершалось это все сообщение в Slack c ссылкой на полученную страницу.
Это требует договоренностей с командой разработки, например, user story Id должно присутствовать в описани коммита.

Для получения данных об ограничении скорости не нужно отдельное устройство.
Если уже подключены как-то к круиз контролю, почему бы не получать текущие координаты от бортой системой навигации? Полученные коордианты и надо испольовать для запроса скоростных ограничений. Не стоит также ничего конвертировать в текстовый формат. Вместо это надо дергать API специализированных сервесов, например Google Roads - Speed limits. Наверняка аналогичные API есть у Яндекса и 2ГИС.

Для таких проектов не надо тратиться на разработку. Нет разработчика - нет проблем. Так же нет смысла на старте вкладывать в дизайн, можно просто купить готовую тему.
Вместо WP, лучше взять Ghost или Gatsby. В них нет стольких дыр сколько в WP и опять таки не требуются дополнительные знания.

В таких случаях хорошо сработает связка из NoSQL + GraphQL.
NoSQL даст возможность использовать одну и туже коллекцию для всех страховых, то есть сможете легко строить аналитику без 100500 join
GraphQL позволит гибко настраивать payload для внешних API

Наверняка вы уже трекаете активность пользователй в приложении. Если юзер не активен в течение N дней\месяцев, помечайте его как удаленный\замороженный\etc.
Заодно можно пуш кинуть ему от системы, чтобы попробовать активировать опять.