Привет, Хабр! На связи Давид Саргсян. Я занимаюсь системным анализом цифровых продуктов банка ПСБ.

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

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

Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

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

Теперь у нас есть имена для различных практик Use-case, с учётом уровня их детализации.  

В рамках текущей статьи, приведено основное, краткое содержание руководства Use-case 3.0 — без отступлений, и дополнительных пояснений по тому или иному пункту.

Четыре года назад я упёрся в стену. Я работал QA инженером, изучал инструменты, автоматизацию, базы данных — но карьерного роста не было. Мне хотелось развиваться, двигаться в сторону тест-менеджмента, но одних технических навыков оказалось недостаточно. Тогда я впервые осознал, что не только харды определяют успех.

Soft skills стали тем, что помогло мне выйти на новый уровень. Я научился планировать, делегировать, вести переговоры, работать с командой. Всем привет! Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке и в этой статье я расскажу, какие soft skills действительно важны, как их развивать и почему без них сложно расти в IT.

При подготовке специалиста в области проектирования Информационных систем, важно учитывать конъектуру применения навыков в дальнейшем. Это может быть либо роль «Проектировщик» в каком‑то из проектов, либо постоянная профессия «Проектировщик ИТ‑продуктов».

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

В этой статье покажу, что участие в Open Source проще, чем кажется. Расскажу, как регулярная работа с чужим кодом помогает быстрее разбираться в незнакомых кодовых базах, писать тесты и лучше документировать решения. А также объясню, почему публичная активность на GitHub выгодно отличает вас от других разработчиков, особенно в эпоху повсеместного использования ИИ.

Привет, Хабр!

В этой статье рассмотрим классическую проблему «мягкого удаления» на уровне схемы баз данных и её влияние на аналитику.

Почти в каждой системе встречается требование «не удалять данные окончательно».

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

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

Цель статьи — помочь понять, нужен ли вам на проекте системный аналитик или нет.
А также предостеречь о потенциальных трудностях тех, кто только собирается стать системным аналитиком.

Последние восемь лет я работаю системным аналитиком и до сих пор не перестаю удивляться тому, насколько противоположные мнения об этой роли встречаются даже среди опытных специалистов. Ещё в далёком 2008 году был доклад на близкую тему — «Аналитик в Agile: архаизм или необходимость?». С тех пор прошло семнадцать лет, а ситуация принципиально не изменилась — тема по-прежнему вызывает ожесточённые споры.

Всем привет! Меня зовут Бодров Иннокентий. Я — продакт, аналитик и архитектор с более чем 17-летним опытом в разработке информационных систем, построении успешных продуктов в телеком-индустрии, финтехе, электронном документообороте и корпоративных порталах.

Последние несколько лет я активно продвигаю идеи работы на основе здравого смысла, бережливости и современного, гибкого (в хорошем смысле слова) продуктового подхода. И один из инструментов, который мне помогает в этом — это Domain-Driven Design (DDD).

Многие считают DDD чем-то исключительно для разработчиков. Я же уверен: это прежде всего коллаборативная техника. Она полезна аналитикам, продактам, архитекторам, менеджерам. Но особенно важно, чтобы в DDD погружались те, кто ближе к бизнесу. Потому что именно у них есть шанс выстроить мост между миром предметной области и кодом.

О том, как это сделать — и будет эта статья.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

«Я только решил, что выбрался, а меня продолжают затягивать обратно!» С лукавой ухмылкой, к которой я скоро привыкну, Пол Гинспарг цитирует Майкла Корлеоне из «Крёстного отца». У Гинспарга, профессора физики Корнельского университета и стипендиата Макартура, может быть, и мало общего с мафиози в исполнении Аль Пачино, но обоих объединяет чувство, что им отказали в изящном уходе из созданной каждым из них организации.

Почти 35 лет назад Гинзпарг создал arXiv, цифровое хранилище, где исследователи могли делиться своими новыми результатами — до того, как эти результаты уходили на систематические обзоры или проверки. Зайдите сегодня на сайт arXiv.org (он произносится как «архив»), и вы всё ещё увидите его старый дизайн в стиле Web 1.0 с красным баннером и печатью Корнельского университета, который является институциональным домом платформы. Но за непритязательным фасадом arXiv скрывается тектоническая перестройка, которую он вызвал в научном сообществе. Если бы arXiv перестал функционировать, учёные со всех уголков планеты испытали бы немедленное и глубокое потрясение. «Все математики и физики пользуются им, — сказал мне Скотт Ааронсон, компьютерный учёный из Техасского университета в Остине. — Я этот сайт сканирую каждый вечер».

Вчера Skype окончательно ушел в прошлое. Не просто из России — из нашей цифровой жизни. Microsoft официально делает ставку на Teams и закрывает эру, в которой Skype был символом новой свободы общения. Это не просто новость — это повод вспомнить последние 22 года и то, как небольшая программа изменила мир.

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

На связи руководитель PT Application Inspector, Сергей Синяков, я прошёл десятки планирований, как в простых, так и в сложных продуктах, работал как с B2C-, так и с B2B-решениями. Хочу поделиться мыслями, опытом и примерами того, как систематизировать управление бэклогом, чтобы удержать баланс между разными направлениями развития продукта.

Если в B2C этот процесс можно свести к работе с большими данными, где решения принимаются быстро и на основе четких метрик, то в B2B всё скорее напоминает разработку кастомного решения для enterprise-клиента: длинные циклы, множество стейкхолдеров и высокая сложность продукта. Классические фреймворки приоритизации, такие как RICE, MoSCoW или Kano, отлично работают в B2C, где пользовательские потребности относительно схожи или однородны, а циклы обратной связи короткие. Однако в B2B они часто дают сбой. Почему?

Знакомо ли вам чувство, когда смотришь на BPMN-схему и видите лишь хаос из непонятных значков? Прямоугольники с плюсиками, пунктиры, ведущие в никуда, кружки с молниями… Моё первое впечатление было таким же: «Этот язык создали, чтобы запутать аналитиков!».

Но сейчас я использую их, чтобы:

→ Сокращать совещания — когда процесс визуализирован, спор «как мы это делаем» исчезает.
→ Находить дыры в логике до внедрения — те самые «а что, если…».
→ Объяснять сложное за 5 минут даже тем, кто терпеть не может диаграммы.

Если вам надоело тратить время на бесконечные уточнения — давайте разбираться. BPMN может быть простым!

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