"Что делать, когда ТОПовые BI-системы стали недоступны и перспективы работы с ними оказались сильно ограничены?". Эта дилемма встает сегодня перед многими компаниями. Меня часто спрашивают, можем ли мы взять и перенести уже наработанные практики на другие платформы, доступные в России на сегодняшний день? К счастью, ответ на этот вопрос положительный, и об одном из вариантов его решения я расскажу сегодня.
Привет! В этом посте мы обсудим Real-time optimization и его влияние на бизнес, само собой, по большей части поговорим про нефтехимию. Но RTO способно повысить эффективность бизнеса и в других сферах, главное — правильно применять этот подход.
Что это вообще такое — RTO?
RTO — оптимизации в реальном времени, целью которой является улучшение экономической эффективности работы производства. Она регулярно моделирует текущий режим и оптимизирует его с учетом экономических предпосылок и технологических ограничений и требований. Эти оптимизации улучшают селективность процесса, перераспределяют продуктовую корзину, повышая ее маржинальность, а также сокращают потребление сырья на тонну продукции и энергопотребление.
Привет! Меня зовут Виктория Кабыткина, я работаю старшим системным аналитиком в компании Lamoda. По своему опыту как в банковской сфере, так и в сфере e-commerce, могу заметить, что во многих компаниях существует тенденция избавляться от монолита и переходить на микросервисную архитектуру.
Тенденция популярна и заставляет задуматься над множеством вопросов. А нужен ли на таких проектах бизнес-аналитик? А системный? А если все-таки нужен, то чем он там занимается? Какие задачи он решает? Полезен ли команде?
В этой статье я постараюсь ответить на эти вопросы и рассказать о роли и задачах аналитика при выделении микросервисов, основываясь на своем личном опыте.
Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.
С чего все началось. Я недавно менял работу, поэтому готовился к техническим собеседованиям. Для удобства составил шпаргалку частых вопросов по основным темам. Когда проходил собеседования и видел, чего я не знаю, то дописывал это в свою шпаргалку. А немного позже решил составить для себя что-то наподобие плана развития. При создании плана использовал личный опыт, опыт коллег, ряд статей, учебные планы нескольких школ, требования из вакансий.
Вопрос обязательности умения/знания/понимания программирования для ИТ-аналитика-проектировщика вызвал жаркие дебаты в профильных группах. Приводились два вида аргументов:
Многим на Хабре уже известны наши конференции вроде Joker, HolyJS или Heisenbug. Теперь к ним добавляется ещё одна, на смежную тему: мы увидели, что есть спрос и на «аналитическое» мероприятие. Поэтому 29-30 ноября проведём новую конференцию Flow, программа и билеты доступны на сайте.
А в этом тексте мы расскажем главное про конференцию. На кого мы ориентировались, когда выбирали доклады? А для кого, наоборот, подходящих докладов там не найдётся? Это оказалось не самым очевидным вопросом.
А для дочитавших до конца — ещё и небольшой бесплатный бонус к конференции.
SAP-практика в СИГМЕ — одна из крупнейших в стране. Однако уход SAP из России повлек за собой существенные изменения на рынке ERP-решений, которые затронули и нашу компанию. Так как преобразования сейчас в самом разгаре, давайте вместе разберемся, что будет происходить на этом рынке в ближайшие годы, какие специалисты будут востребованы, а также — чем может похвастаться российский рынок ERP сейчас и в будущем.
Я в системном анализе уже более 5 лет. За эти годы я достигла значительного роста как горизонтального, так и вертикального. Ежедневно я взаимодействую и консультируюсь со своими коллегами, обращаюсь к их техническим заданиям, разбираюсь в их методах реализации и наставляю новых сотрудников. В начале этого года я поймала себя на мысли, что невольно стала разделять своих коллег на 3 типа системных аналитиков.
Такая градация помогает мне определить подход взаимодействия со специалистом. А также позволяет спрогнозировать, каких результатов от этого сотрудника можно ожидать.
Эта статья будет интересна системным аналитикам и участникам команд разработки. А если среди ваших коллег есть люди, подходящие под моё описание, то, возможно, вы будете понимать их чуточку лучше.
Люди не всегда понимают, что им говорят/передают другие люди. Например, читая книги я частенько сталкиваюсь с сплошными абстракциями (что авторы на самом деле имели в виду - неясно, ты должен догадаться сам, при этом авторы оставляют за собой право судить, правильно ли ты догадался или нет). Как же передавать смысл понятным образом и давать понятные определения - вот о чем статья.
Схемы по методу моделирования бизнес-процессов (BPMN) используются в разных сферах, например, в продажах и ведении проектов. В разработке этот инструмент важен на этапе бизнес-аналитики: с помощью BPMN описываются все сценарии взаимодействия пользователей и системы. Такие диаграммы создавалась специально для того, чтобы найти общий язык между аналитиками и управленцами без технической подготовки.
Как с помощью брокера AMQP RabbitMQ создать отказоустойчивую архитектуру с минимальными потерями лог-данных при сбоях.
Потеря логов при управлении большой инфраструктурой компании-хостера может обернуться имиджевыми и финансовыми потерями. Вместе с тем большое количество управляемого оборудования не вызывает желания создавать системы, в которых логи будут дублироваться и превращаться в огромный и трудноуправляемый массив информации.
Мы в компании Hostkey не стали изобретать велосипед и построили нашу систему на базе Open Distro. В этой статье мы расскажем о варианте архитектуры этого решения, которое благодаря использованию брокера AMQP RabbitMQ обеспечивает отказоустойчивость и минимальные потери лог-данных при сбоях.
Новая функциональность была критически важной, по требованию финансового регулятора, мы были обязаны начать проверку третьих лиц, участвующих в транзакциях с нашими клиентами, по спискам санкций и политически значимых лиц (PEP). Если некий Вася обнаруживался в санкционных списках, или, скажем, был выбран когда-то в городскую администрацию, транзакции с его участием должны были отправляться на контроль в отдел комплаенса. На тот момент уже существовали и другие правила, отправляющие транзакции на контроль, например при превышении определённой суммы.
И вот, разработка и тестирование закончены, одним прекрасным утром трафик переключается на новую сборку, мониторинг показывает, что запросы к API проверяющей фирмы идут, ответы приходят, всё нормально. Но уже через час отдел комплаенса бьёт тревогу – задержанные на контроль транзакции стали попадать на счета клиентов! За такие дела можно и лицензию потерять, поэтому начинается аврал: счета этих клиентов замораживаются, версия срочно откатывается, транзакции правятся вручную. Нервная и неприятная для всех ситуация, иными словами, полная ж… жесть.
Как же так получилось? Ведь были и автотесты и ревью кода, тестирование в песочнице...
Всем привет. Я работаю в заказной разработке уже больше 10-ти лет, и хочется поделиться своим опытом. Рассказать, с какими особенностями в работе я сталкиваюсь. Возможно, это найдет у вас отклик или поможет вам не совершить ошибок, или поможет быть готовым к некоторым рабочим ситуациям.
Бывает, что на этапе пресейла, могут быть даны бездумные обещания, с целью угодить Заказчику. И часто бывает, что эти обещания фактически невыполнимы.
Стратегия соглашаться на все, лишь бы войти в проект и надеяться что потом разберемся, провальная. “Потом” наступит слишком быстро, и последствия могут быть крайне неприятными. Причем разбираться скорее всего придется непосредственным участникам проекта.
На мой взгляд, о том, что возможно сделать и за какой срок, стоит говорить максимально правдиво и обдуманно. Если есть сомнения, то лучше взять паузу, обсудить со специалистами в компании. И уже после этого договариваться о функционале, который может быть реализован. А если остались спорные или непонятные моменты, их можно вынести в ограничения.
Бывает, что Заказчик настаивает на своих хотелках, даже если они нежизнеспособны. Аргументирует это тем, что он платит деньги, поэтому он прав, а мы должны делать то, что он говорит. И его хотелки могут касаться небольших интерфейсных изменений, а могут касаться и кардинальных архитектурных решений.
Мой совет - не нужно сразу бежать реализовывать. Имеет смысл провести ряд встреч для обсуждения. Донести свою позицию, подкрепить ее сравнительной таблицей вариантов, подготовить перечень возможных негативных последствий.
Это третья статья из цикла. В прошлой части мы разбирали типы метрик, и уже там начали встречаться перцентили. Это полезная штука, но для неподготовленного читателя она выглядит просто как математическая дичь. Эта статья поможет разобраться в перцентилях по-инженерному, не заканчивая профильный факультет.
В гибкой разработке как никогда популярно использование пользовательских историй (user story). И если вы слышали или работали с ними, то в курсе, что они пишутся от имени разных пользователей (user types). Определение пользователей важно не только для этого инструмента, но и если используются сценарии (use cases) или иное представление требований. Эта статья расскажет о моделировании персон, о том, как можно определить пользовательские роли для своего продукта.
Можно по-разному подходить к процессу разработки сервисов и приложений. Идеальной методологии не существует, многое зависит от особенностей команды и самого проекта. Тем не менее, некоторые практики показывают себя хорошо, и в ходе различных проектов могут распространяться на все работы, обеспечивая более предсказуемый результат. Это не означает, что для конкретного проекта и команды не будет существовать более эффективного пути организации работы, но согласитесь — лучше иметь постоянно работающий хороший инструмент, чем под каждый проект пытаться найти самый лучший.
Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».
Пока все апгрейдят свою жизнь на всяких онлайн-школах, я решил заняться даунгрейдом. Опыт разработки более 10 лет. Сразу к делу: в какой-то момент мне понравилось держать в руках паяльник. Случилось это в преклонном для электрика возрасте. Примерно тогда же по стечению обстоятельств я решил собрать свой первый АКБ для своего электроскутера и Остапа понесло! Пошли сборки АКБ для электровелосипеда, электросамоката, электроскутера и даже инвалидных кресел на электротяге. Затарился литий-ионными (Li-Ion), литий-железо-фосфатными ячейками (Lifepo4) и Li-NMC.
С паяльником и прочим инвентарем я разобрался. Но был один жирный минус...
В апреле этого года, после нескольких лет успешного развития платформы Waves Enterprise и ее использования в различных проектах мы решили выпустить её open-source версию, чтобы расширить охват потенциальных пользователей платформы. Мы сохранили в ней почти всю функциональность и классные фичи: это контейнеризированные смарт-контракты на любом языке, поддержка трех разных консенсусов, возможность обмена конфиденциальными данными и не только. Убрали только поддержку ГОСТ-криптографии, TLS и PKI.
В этом посте мы сравним наш блокчейн с известными аналогами, расскажем, как развернуть его самостоятельно и настроить мониторинг. В итоге вы получите готовую блокчейн-песочницу для экспериментов и разработки децентрализованных приложений на любом языке программирования.
