Меня зовут Александр Мачулин, я основатель Gramax – open source системы для ведения документации в подходе Docs as Code с визуальным редактором.
Сегодня я расскажу вам идею, как вести всю документацию по проекту и весь цикл разработки в одном Git-репозитории и настроить backward-трассировку требований в Git.
Все разработчикам знаком момент, когда заказчик просит что - то сделать, но толком не вдается в детали? У меня были примеры, когда заказчик вообще не описывал требования, а ожидал, что ему ЧТО-ТО создадут, а ну уж потом он/она скажут что не так. Или так. Или не так. Предлагаю разобраться, когда гибкость превращается в ад.
В последнее время в информационном поле мне всё чаще попадается информация о заблуждениях в сфере налогового контроля, и по большей части эти заблуждения исходят от людей, которые называют себя специалистами или экспертами. Таким образом формируется в корне неверное представление о том, чем на самом деле занимается служба и как она осуществляет свой контроль. Вы наверняка видели подобные заголовки: «эксперты предупреждают», «юристы советуют» - смотреть и читать это уже просто больно.
Поэтому на правах бывшего сотрудника ФНС, прошедшего три контрольных отдела - предпроверочный анализ, контрольно-аналитический отдел и отдел выездных проверок, я решил подготовить статью с разбором самых популярных мифов, которые встречались мне за последнее время.
Если в этой статье я разберу не все популярные мифы, и вы слышали что-то ещё, что на ваш взгляд не похоже на правду - пишите в комментариях, или в личные сообщения. Я добавлю это к разбору в следующей статье.
Современные цифровые продукты выглядят устойчивыми.
Они работают, масштабируются, удерживают пользователя, демонстрируют высокую вовлечённость и формальную эффективность. На уровне метрик всё выглядит корректно: система не падает, пользователь остаётся внутри, взаимодействие продолжается.
Проблема в том, что эта устойчивость всё чаще достигается не за счёт формы самой системы, а за счёт скрытой компенсации со стороны человека.
С помощью Python математически проследил эволюцию философских взглядов поэта на его творческом пути.
Это не книга про Excel как электронную таблицу и не сборник «трюков и рецептов». Литературы по Excel существует огромное количество — от пособий для бухгалтеров до массивных справочников по формулам. Excel как продукт существует почти 40 лет, и на фоне Python, R, BI-платформ и облачных аналитических стеков может показаться, что в середине 2020-х годов писать о нем уже нечего. Однако книга Джорджа Маунта показывает обратное. Здесь Excel рассматривается как полноценная аналитическая платформа, встроенная в современный стек анализа данных — со своим ETL, моделью данных, языками запросов и элементами augmented analytics и машинного обучения.
Если с 2022 по 2024 год рынок проходил момент пика количества вакансий при нехватке специалистов, то сейчас ситуация обратная. Кандидатов много, но предложений меньше, а требования к системным аналитикам выше.
Меня зовут Филипп Сенцов, я Lead Solution Architect в финтех-компании и ментор курса «Системный аналитик» в Яндекс Практикуме. В этом тексте расскажу, какие сложности переживает рынок найма и как начинающим и опытным специалистам с ними справиться. Некоторые утверждения будут актуальны только для системных аналитиков, но многие — для всех IT-специалистов.
Всем, у кого есть любимая интересная работа, наверное хотелось рассказать о ней своим детям, увлечь их, показать, как это здорово и полезно! И пусть они не пойдут по нашим стопам, но хотя бы будут уважать и ценить то, чем увлечены родители.
Может быть это мечты, иногда хочется попробовать рассказать в красочной и интересной форме о нашей работе своим детям.
Хочу познакомить вас с одной аналогией, которая в своё время помогла мне усвоить, как же работает микросервисная архитектура.
Разберемся, чем микросервисы похожи на клетки, поднимемся на уровень модулей и органов, а потом посмотрим на продукт как на организм.
Почему большинство корпоративных ИТ-систем устаревают в момент внедрения и как этого избежать
Если вы хотя бы раз сталкивались с документооборотом в компании, то знаете, что это огромная и неповоротливая махина, наладить которую сложно, пустить на самотек нельзя, а выстроить идеально практически невозможно. Или все-таки возможно? Какие проблемы возникают при работе с системами электронного документооборота и как их избежать еще на этапе внедрения, попробуем разобраться в этой статье.
Привет! Меня зовут Любовь Черкасова. Я больше 13 лет работаю в ИТ и занимаюсь цифровизацией бизнес-процессов в крупных компаниях. За это время я руководила командами аналитиков и отделом внедрения, участвовала в проектах по запуску и развитию корпоративных систем, а также выводила на рынок собственный продукт — LDM.КЭДО.
Последние годы я занимаюсь развитием CSP-платформы и регулярно вижу и исправляю последствия архитектурных решений, принятых на этапе внедрения. Поэтому многие из наших проектов - устранение этих последствий и замена существующих систем. Я ни раз наблюдала проекты, в которых система формально внедрялась успешно, но уже в процессе реализации становилась неактуальной для бизнеса: требования менялись быстрее, чем шёл проект. Именно этот опыт и выводы из него легли в основу статьи. Я расскажу о том, как наша команда изменила подход к реализации систем электронного документооборота (СЭД), и что из этого получилось. Надеюсь, наш опыт будет полезен кому-то еще.
Все кейсы, описанные в статье, реальные, они действительно из жизни наших клиентов.
Вы написали безупречное техническое задание. Провели двадцать интервью. Заполнили сто страниц в Confluence. Проект запущен, а через месяц ключевой стейкхолдер говорит: «Нет, это не то, что мы хотели». Знакомо?
Классический бизнес-анализ даёт нам инструменты для работы с озвученными потребностями. Но настоящая магия (и главные риски проекта) скрыта в зоне неозвученных мотивов, страхов и психологических игр. Сегодня поговорим о том, как применять методы, условно называемые «психоанализом стейкхолдеров», не будучи психологом.
Это не история про плохих менеджеров или выгорание. Это история о профессиональной эволюции: о том, как я, системный аналитик, осознала, что моя задача — не только передавать требования, но и активно участвовать в улучшении процессов, выявляя и устраняя узкие места.
Всем привет! Меня зовут Сидоров Антон, я руководитель отдела технической архитектуры в департаменте сопровождения информационных технологий ПСБ. Моя команда занимается архитектурой инфраструктурных систем, и сегодня я хочу рассказать вам про наш первый опыт использования подхода «Архитектура как код»
Ранее видел много публикаций и скептических комментариев на тему использования нейросетей в трейдинге, и хотелось бы поделиться своими наработками и мнением.
Всем, кто имеет большой опыт в торговле, знаком такой термин, как «тестирование стратегии на истории», а что, если я скажу, что с приходом к нам нейросетей мы можем тестировать наши стратегии на будущем?
То есть на будущем для нейросети и прошлом для нас. Такой метод будет наиболее эффективен для результатов, кроме того, мы можем использовать неограниченное количество индикаторов и выявлять те из них, которые бесполезны.
Например, таким образом я узнал, что RSI индикатор совершенно бесполезен в техническом анализе. Сильное заявление? :-)
Многие из вас, оцифровав и обучив нейросеть своей стратегией, могут сильно разочароваться, когда увидят, что результаты оставляют желать лучшего.
А какие-то индикаторы, которыми мы даже не пользовались, отнюдь покажут ошеломляющие результаты в обучении.
Для всех ищущих в индикаторах, в том числе нейросетевых, панацею и кнопку «бабло» отвечу сразу, что это всего лишь способы улучшить свое статистическое преимущество.
Любой индикатор не добавляет информации. Он берёт уже известные данные — цену, объём, диапазон — и пересчитывает их с задержкой, сглаживанием или нелинейным преобразованием.
Поэтому индикатор не может давать гарантированный результат. Он лишь немного смещает распределение вероятностей: в одних состояниях рынка вероятность исхода становится выше, в других — ниже.
Работа индикатора — не «предсказать», а слабым сигналом подсветить контекст: перегрев, инерцию, отсутствие направления, смену режима.
Привет, Habr! Совсем недавно мне посчастливилось выступить на конференции Analyst Days’21 с темой, которая, как мне кажется, актуальна и для начинающих, и для продолжающих аналитиков, так как все мы время от время сталкиваемся с новыми проектами, задачами, вызовами. В этой статье поделюсь своими лайфхаками о том, как быстро погрузиться в предметную область клиента.
В 2025 году команда abgroup.tech внесла продукт OpenForm в Реестр российского программного обеспечения, подтвердив статус надежного open-source решения для отечественного рынка
OpenForm — это система ввода данных, предназначенная для создания отчетов в соответствии с корпоративными регламентами. Система обеспечивает сбор и структурирование информации. Продукт адаптирован под сложные бизнес-процессы, поддерживает многостраничность, расчеты и строгий контроль данных, а также избавляет от ручного ввода и ошибок в Excel.
abgroup.tech занимается разработкой систем управления данными и аналитических порталов
Самые интересные новости финансов и технологий в России и мире за неделю: Трампу подарили Нобелевку, отмена виз в США для россиян, Telegram стали замедлять сильнее, в ChatGPT вставляют рекламу, GPT-5.2 впервые решил сложную задачу Эрдёша, в Siri встроят модель Gemini, а также свежее фото новой Ларочки.
Сравнение натриевых и литиевых аккумуляторов
Сейчас литиевые аккумуляторы используются почти везде, так как у них наибольшая плотность энергии по сравнению с доступными на практике альтернативами. Однако в настоящее время появились ниши, где масса и объём менее критичны, а ключевыми факторами становятся стоимость, безопасность и низкотемпературная работоспособность.
Натриевые аккумуляторы потенциально обладают этими преимуществами по сравнению с литиевыми.
Также натрий гораздо более распространенный и дешевый элемент, что тоже имеет немалое значение.
Уровень развития технологии
Вот, что мне удалось найти, относительно серийного выпуска натриевых аккумуляторов:
Привет, хабр!
Сегодня мы разберём полный цикл создания торговой системы на Python: от бэктеста стратегии до её запуска в реальном времени на бирже BingX. Стратегия будет основа на индикаторах и математике, но они будут довольно неклассические и, думаю, многим это будет интересно.
Я опишу логику стратегии, покажу код и объясню каждую часть шаг за шагом. Это не просто копипаст - это полноценный гайд, чтобы вы могли адаптировать систему под себя. Мы используем библиотеки вроде Pandas, NumPy, Matplotlib и API бирж (Binance для данных, BingX для торгов).
Сейчас система находится в тесте около 2 недель. На данный момент профит составляет 5% к капиталу бота, но потеря капитала также возможна. Разберём полностью торговую систему и как провести тестирование.
Все файлы этой торговой системы, а также pine script выложил на github — можете посмотреть на код сами.
Когда релиз раскатан не на всех, классическая схема "до" и "после" начинает рушиться: метрика растет или падает одновременно из-за сезонности, внешнего фона и изменений в каналах, а не только из-за продукта. При этом AB теста может не быть, но данные по группам есть почти всегда: по гео, сегментам, кластерам, витринам.
В этой статье разбираю два практических подхода, которые позволяют оценить эффект релиза в таких условиях. Первый - diff-in-diff: сравниваем, насколько изменилась метрика в затронутой группе относительно контрольной, и тем самым вычитаем общий фон, который влияет на всех. Второй - синтетический контроль: строим базовую линию для затронутой группы как сумму метрик нескольких контрольных групп с весами, подобранными так, чтобы до релиза эта конструкция максимально повторяла историю затронутой группы.
Отдельный акцент на том, что обычно искажает выводы: заметный рост или падение разницы между группами до релиза, изменения состава, локальные акции или технические инциденты в контрольных группах, а также ситуации, когда базовая линия плохо повторяет период до релиза и тогда мы измеряем в основном ошибку модели, а не эффект релиза. В конце показываю, какие проверки стоит сделать, чтобы результат не держался на удачно выбранных границах периода или на одной контрольной группе.
Если в первой части мы работали с одной временной линией метрики, то здесь переходим к более распространенному случаю: несколько групп, частичная раскатка и необходимость отделить влияние релиза от общего шума.