Avsnitt
-
В этом выпуске говорим с Кириллом Егоркиным — архитектором решений — о том, как на самом деле создаются IT-системы: от первой идеи бизнеса до проектирования, разработки, MVP и пилота.
Часто кажется, что система начинается с задачи в разработку. Но на практике всё начинается намного раньше: с бизнес-идеи, Vision, верхнеуровневых требований, оценки масштаба, выбора архитектурного подхода и постоянных компромиссов между бизнесом, сроками, бюджетом и техническими ограничениями.
В выпуске обсудили:
— кто приходит с идеей новой системы;
— как формируется Vision проекта;
— когда подключать системного аналитика;
— чем отличаются Solution, Enterprise и корпоративные архитекторы;
— как изучать бизнес-процессы перед проектированием;
— что делать, если бизнес сам не может сформулировать требования;
— где зона ответственности архитектора, а где системного аналитика;
— какие артефакты делает архитектор, а какие — аналитик;
— как бизнес давит на проектные решения и как с этим работать;
— когда выбирать монолит, а когда микросервисы;
— как определять границы микросервисов;
— почему MVP часто понимают неправильно;
— чем занимается архитектор во время разработки и пилота;
— как системному аналитику развивать архитектурное мышление.Этот выпуск будет полезен системным аналитикам, бизнес-аналитикам, начинающим архитекторам, разработчикам и всем, кто хочет понимать, как IT-системы проектируются не на уровне “нарисовали схему”, а на уровне реальных решений, компромиссов и ответственности.
Подписывайтесь на канал — впереди новые выпуски про системный анализ, архитектуру, требования, проектирование и реальные кейсы из IT.
-
В этом выпуске говорим с Юлией Литвинюк — архитектором прикладных решений — о том, как на самом деле проектируются интеграции между системами.
Интеграции часто выглядят просто: одна система должна передать данные в другую. Но на практике всё сложнее: грязные данные, дубли, разные форматы, ограничения безопасности, отсутствие прямого доступа, старые интеграции без документации и бизнес, который говорит: «Сделайте как было».
В выпуске обсудили:
— какие требования нужно собрать до проектирования интеграции;
— зачем нужна диаграмма потоков данных;
— как выбрать способ обмена: API, веб-сервисы, файловый обмен, SFTP, база данных, шина или брокер сообщений;
— что такое мастер-система и почему это важно;
— как искать ключевые поля и не получить дубли на проде;
— почему нельзя верить словам «у нас с данными всё хорошо»;
— какие нефункциональные требования влияют на интеграцию;
— что фиксировать в документации, чтобы через полгода не страдать;
— как логирование и мониторинг помогают расследовать инциденты;
— какие реальные фейлы случаются на интеграционных проектах.Этот выпуск будет полезен системным аналитикам, бизнес-аналитикам, архитекторам, разработчикам и всем, кто работает с интеграциями, API, обменом данными и проектированием IT-систем.
Подписывайтесь на канал — дальше будет больше выпусков про системный анализ, архитектуру, требования, процессы и реальные кейсы из IT-проектов
Наш телеграм канал (32.000 человек) с полезной информацией для системных/бизнес аналитиков - https://t.me/+92X0XIrrmaNlNjJi -
Saknas det avsnitt?
-
В новом выпуске подкаста Ольга Пономарёва говорит с Владимиром Бурмистровым — системным аналитиком с 18-летним опытом в IT.
Тема выпуска — антипаттерны в IT-системах: как хорошие на первый взгляд решения становятся проблемой, почему “сделаем быстро, а потом перепишем” часто превращается в годы поддержки, и какую роль во всём этом играет системный аналитик.
Обсуждаем, чем архитектурный компромисс отличается от антипаттерна, почему микросервисы не всегда лучше монолита, как временный сервис может остаться в системе на годы, чем опасны цепочки вызовов, “бог-сервисы” и одна общая база данных на всех.
Также говорим о том, кто должен принимать архитектурные решения, зачем фиксировать их через ADR, как аналитик может заметить риски ещё до разработки и почему ошибка аналитика иногда обходится команде дороже всего.
В выпуске:
— что такое паттерн и антипаттерн;
— когда плохое решение может быть осознанным компромиссом;
— монолит, микросервисы и выбор архитектуры под задачу;
— организационные причины архитектурных проблем;
— интеграционные антипаттерны и цепочки вызовов;
— общая база данных и проблемы с развитием системы;
— как выходить из антипаттернов;
— какую роль системный аналитик играет в архитектурных решениях;
— заменит ли ИИ системных аналитиков.Выпуск будет полезен системным аналитикам, бизнес-аналитикам, архитекторам, разработчикам, тимлидам и всем, кто участвует в проектировании IT-систем.
-
В этом выпуске подкаста Ольга Пономарёва общается с Аней — выпускницей курса «Системный аналитик для начинающих», которая смогла перейти из продаж в системный анализ и найти первую работу в новой профессии.
Обсудили, как Аня решилась на смену сферы после 5 лет в продажах, почему выбрала именно системный анализ, с какими страхами столкнулась в начале пути и что помогло не сдаться. Поговорили про обучение, поиск работы, собеседования, стажировку и первые реальные задачи уже в роли аналитика.
Это честный разговор о смене профессии без прикрас: про сомнения, отказы, 150+ откликов, неоплачиваемую стажировку и путь к первой работе. Выпуск будет полезен тем, кто тоже думает о переходе в аналитику и хочет понять, как этот путь выглядит в реальности
-
В этом выпуске разбираем реальную работу бизнес-аналитика в продуктовой команде — без теории и “идеальных процессов”.
Гость подкаста — Никита Рублев, бизнес-аналитик в финтехе.
На примере автокредитования обсуждаем, как на самом деле устроена работа аналитика, какие задачи он решает и с какими проблемами сталкивается каждый день.Поговорили о том:
— кто такой бизнес-аналитик и чем он занимается в продукте
— как выглядит реальный рабочий день (и правда ли, что это одни созвоны)
— в чем разница между бизнес-аналитиком и системным аналитиком
— где проходит граница ответственности между БА, продактом и командой
— зачем аналитик задает вопрос «зачем» — и как он может полностью изменить решениеОтдельно разобрали:
— как работать с бизнесом, который приходит сразу с «готовым решением»
— что делать, если стейкхолдер сам не понимает, чего хочет
— как аналитик влияет на продукт и архитектуру
— почему требования часто пишутся «для галочки»И самое интересное:
— когда аналитик действительно не нужен
— можно ли быстрее сделать без требований
— почему половину задач можно было решить просто разговором
— реальные фейлы аналитики, которые стоили дорогоВ конце — блиц про навыки, карьеру и будущее профессии:
— что важнее: скорость или качество
— хард vs софт скиллы
— заменит ли ИИ аналитиковЭтот выпуск будет полезен:
— новичкам, которые только думают идти в аналитику
— действующим БА и СА
— продактам и разработчикам, которые работают с аналитиками
