Представь, что ты пришел на новый проект, который находится в состоянии глубокого информационного хаоса. Требования разбросаны по десяткам файлов, нет протоколов встреч, идеи Product Owner'а меняются слишком быстро, а ключевая информация теряется между переписками в мессенджерах и электронной почтой.

К сожалению, так бывает! И попытки сразу перейти к структурированию в текущих условиях - очень большая ошибка. Потому что без предварительной оценки есть огромный риск потратить большое количество времени на “работу в стол”.

Про Gherkin слышали в основном те, кто связан с тестированием. Среди аналитиков он встречается крайне редко. Но если отбросить всё связанное с BDD и тестами, то Gherkin это формат описания поведения системы, где сценарий это обычный текст, написанный в структурированном виде “Given‑When‑Then”. Не код, не диаграмма, а короткое текстовое описание того, что происходит в системе в определённых условиях.

Не потому что модно, не потому что “так надо”, а потому что это удобно. Можно описать фактически всё: контекст, событие, результат - в трёх строках. Удивительно, что это не стало стандартом. Но как это работает на практике? Чтож… Щас выскажусь!

Есть два типа системных аналитиков: те, кто на слова "Acceptance Criteria" кивают уверенно, и те, кто кивают с лицом человека, которому эти слова не приносит радости. А потом открываешь их спецификацию и понимаешь, что критерии приёмки там формулировал кто угодно, но только не человек, который собирается это реализовывать.

Если ты читал мою прошлую статью на Хабре про Gherkin, то уже знаешь, что синтаксис GWT - это не просто красивый способ писать тесты. Это способ фиксировать поведение системы в формате, который понятен и бизнесу, и тестированию и разработчику.

Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.

Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.

Новое исследование показало, что устойчивость к антидепрессантам встречается чаще, чем считалось: 48% людей с депрессией пробовали по крайней мере два препарата и НЕ наблюдали эффекта, а 37% пробовали четыре или более. Это говорит о необходимости пересмотреть подход к лечению депрессии.

У Kafka есть множество способов применения, и у каждого способа есть свои особенности. В этой статье разберём, чем Kafka отличается от популярных систем обмена сообщениями; рассмотрим, как Kafka хранит данные и обеспечивает гарантию сохранности; поймём, как записываются и читаются данные.

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Привет, Хабр! На связи снова я, Егор Марюшко, архитектор решений в «Ростелеком Информационные Технологии» и основатель образовательного центра STENET school.

Весной я выступил на конференции «Второй Аналитический Курултай в Центральной Азии», которая прошла в прекрасном городе Алматы, Республика Казахстан, где рассказал о том, с чего начать и с помощью каких инструментов навести порядок в хаосе из требований и документации. Само выступление можно посмотреть и послушать здесь, ниже я приведу его текстовый вариант. Надеюсь, мой опыт окажется полезным многим читателям!

Привет, Хабр! Меня зовут Егор Марюшко.
Работаю в IT с 2014 года. За свою карьеру я развил отдел бизнес и системного анализа с 5 до 45 человек, реорганизовал отдел аналитиков внедрения из 30 сотрудников, а также работал в международной компании, где было 4000 аналитиков. 

Эта статья написана по мотивам моего доклада “Размер имеет значение: как растут и развиваются отделы бизнес и системного анализа” (запись выступления). 

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

Всем привет! Я Ангелина Набатчикова, BA/SA в QIC digital hub. Я работала аналитиком в нескольких продуктовых командах с различными подходами к документированию и постановке задач. Этот опыт показал мне, что даже в условиях гибких методологий Agile нельзя недооценивать важность детальной и структурированной документации.

Хотя манифест утверждает, что «работающий продукт важнее исчерпывающей документации», качественная документация на самом деле поддерживает порядок и слаженность работы команды, а главное — ускоряет поставку, а не замедляет ee, как иногда ошибочно считают. Давай разберем чуть более убедительные аргументы на эту спорную тему.

Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик и системный аналитик. Сегодня задачи аналитика включают в себя множество различного функционала, границы которого намного шире, чем просто работа с документацией. Одна из таких нетипичных задач, по моему опыту, с которой системные аналитики все чаще сталкиваются на сегодняшний день – проектирование пользовательских интерфейсов.

В этой статье мы рассмотрим основные аспекты проектирования интерфейсов для системных аналитиков, принципы UX/UI и теории проектирования, а также связь требований с прототипами.

Я недавно решила углубленно разобраться, какие архитектуры бывают в разработке ПО, и написать об этом простую статью. Это моя первая попытка поделиться своими мыслями и объяснить сложные вещи на понятном языке, поэтому буду рада вашей обратной связи

Здесь я рассказываю про монолиты, микросервисы и микрофронтенды без сложных терминов и технических деталей, чтобы те, кто только начинает разбираться в теме, могли понять, что к чему. Надеюсь, вам будет полезно и интересно. Поехали! 🚀

Привет Хабр! Меня зовут Татьяна Ошуркова, я разработчик, аналитик и автор телеграм-канала IT Talks. Сегодня большой популярностью пользуется термин «System design», что дословно в переводе означает «Системный дизайн». Направление, которое обозначает данный термин тесно пересекается с архитектурой и проектированием. Но в чем же его отличие и есть ли оно вообще? Что включает в себя направление системного дизайна?

В этой статье я расскажу о том, что такое системный дизайн, какие задачи он решает и какие ключевые принципы лежат в его основе. Подробно разберу, чем системный дизайн отличается от архитектуры, а также покажу, как эти понятия связаны друг с другом. Расскажу, какую роль в процессе системного дизайна играет системный аналитик, и приведу примеры реальных задач.

Вопрос о необходимости документации при разработке вызывает много споров. В динамичном мире IT, где изменения стремительны, я часто слышал холиварные обсуждения: а так ли необходима документация?

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

В прошлой статье я рассказывал, как работал в проектах без документации. В этот раз под катом опишу аргументы в пользу ведения документации и поддержания её в актуальном состоянии.

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами. 

Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

Под катом выжимка из главы и нашего выпуска, а также практический опыт Dodo Engineering, как правильно оформлять и хранить архитектурные решения.

Marlin – корпоративный архитектурный репозиторий и система автоматизации процессов жизненного цикла программного обеспечения, которая может сэкономить сотни часов менеджерам проектов и команде разработчиков. Под катом подробное описание процесса сборки, развертывания и тестирования приложения, а также создания зависимостей между другими корпоративными системами.

Так уж получилось что как держатель профессии системного анализа я не раз в ходе занятий со студентами, собеседований, и ассесментов сталкивался с проблемой непонимания базовых принципов и ценностей работы сервисов очередей. Люди не понимают ни как оно работает ни для чего нужно. И раз уже до ИТ мне посчастливилось почти 10 лет отслужить в армии то пример, который очень зашел даже далеким от ИТ людям, со временем родился сам собой.

Итак, вводные данные: военная столовая, мы — проектировщики системы (командиры). Помимо вас в задаче имеется погреб с картошкой и необходимость ее почистить. Для этого у нас есть почти неограниченное количество не особо сообразительных исполнителей — солдат, которым можно поручить эту работу. Согласно нашим вводным солдаты, как и информационные системы, не умеют и не должны сами принимать решения, они делают только то, что мы им поручили.

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

С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.

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

Технология Backend-for-Frontend упрощает разработку сервисов, с которыми одновременно работают множество разных клиентов: компьютеры, смартфоны и планшеты со всеми возможными ОС.

В прошлом, аналоговом мире корпоративными системами пользовались только сами компании. Чем больше развивалась цифровизация и омниканальность, тем больше фокус перемещался из корпоративной инфраструктуры вовне. Покупатели стали покупать товары онлайн и со смартфонов, бизнес-партнёры – взаимодействовать с компанией через веб-платформы. Бизнесу стало важно выстроить такую архитектуру, которая позволила бы открывать такой доступ к корпоративным ресурсам.

Просто о том, чем отличаются HTTP1, HTTP2 и HTTP3, а также почему HTTP3 ещё и QUIC. Статья для junior'ов, интересующихся и готовящихся к собеседованиям.