Меня зовут Евгений, я – директор по продукту в IT-компании, которая занимается цифровизацией ЖКХ и автоматизирует рутинные процессы в управляющих организациях. 

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

Один из главных бизнес-процессов в управляющих компаниях - исполнение заявок от жителей. Качество этого процесса можно охарактеризовать SLA (Service Level Agreement), который включает показатели: срок принятия заявки клиента в работу, срок выполнения заявки, маршрут выполнения заявки

В этой статье расскажу, как мы с помощью методов процессной аналитики (Process Mining) проверили гипотезу о наличии зависимости дебиторской задолженности от соблюдения SLA. 

Введение

С каждым годом количество пользователей интернета растет. К началу октября 2020 года 4.9 млрд людей, а это 63.2% жителей земли, пользуется интернетом. А размер данных в интернете достигал 2.7 Зеттабайт (1 ЗБ ~ 10¹²ГБ). И каждый год —количество пользователей и устройств, подключенных к сети, увеличивается на 6% и 10% соответственно. Большая часть этой информации общедоступна. Источники, ссылающиеся на эти данные или на данные из газет, журналов, радио и телепередач, публичных отчетах правительства, называются открытыми. Поиск информации по таким источникам, выбор и сбор, а также дальнейший анализ – это разведывательная дисциплина, именуемая разведкой на основе открытых источников (OSINT).

Недавно мы поговорили о том, что такое causal inference или причинно-следственный анализ, и почему он стал так важен для развития машинного обучения. А в этой статье - под катом - хотелось бы рассказать о трендах в развитии Causal Inference в ML в 2021 г.

Меня зовут Багрянцев Максим, бывший сотрудник компании Роснефть, в настоящее время являюсь frontend developer в компании Mechanica.

Привет, Хабр! Хочу поделиться своим жизненным опытом с теми людьми, кто еще сомневается идти ли в IT или оставить все как есть.

Написать данную статью меня сподвигла сама идея помочь читателю определиться с выбором, так как я хорошо понимаю на сколько трудно решиться кардинально сменить сферу деятельно и начать все с чистого листа.

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

В нашей лабе мы тестируем по 50-60 новых решений по ИБ в год. Я работаю в команде, которая помогает компаниям создавать свои SOC, а специализируюсь, в частности, на киберразведке (Threat Intelligence). Поэтому Anomali Altitude досталась на тест именно мне. Из отчета для коллег родился этот пост. Результаты тестирования, архитектура решения, возможности интеграции — всё это под катом.

Привет, я Таня, QA iOS в 2ГИС. Хочу рассказать, как мы починили процесс передачи задач между командами мобильных платформ и подготовки данных. По ощущениям, до починки мы будто ехали по гравийке, а после — выехали на дорогу со свеженьким асфальтом. Поэтому я хочу поделиться нашим опытом и показать, что есть смысл улучшать даже мелкие шероховатости взаимодействия.

Приходилось ли вам объяснять IT-понятия людям из других сфер? Это хитрая задача: при объяснении одного IT-термина нельзя пользоваться другими, потому что они тоже будут непонятными. Представим, что ваш знакомый захотел «войти в айти», впервые открыл Хабр и офигел — как объяснить такому человеку хотя бы основные слова?

Мне захотелось описать популярные понятия неформальным языком — так, чтобы доходчиво объяснить главное, а не запутывать нюансами. Для этого местами пришлось пойти на упрощения. Но думаю, новичкам не требуется знать «правильнее писать Linux или GNU/Linux». Для начала понять бы, что в разговорах айтишников слово «перформанс» — это не про современное искусство.

Конечно, большинству хабравчан уже не требуется читать такой текст. Смысл публикации в том, чтобы ссылку можно было кидать неайтишным знакомым. А ещё хабрачитатели могут помочь дополнениями в комментариях: у меня описана лишь часть важных понятий, и мои описания наверняка несовершенны, так что совместными усилиями можно сделать всё полезнее.

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

Мы в облачном провайдере T1 Cloud запускаем серию публикаций для ИТ-специалистов. Начнем с компактного дайджеста книг по администрированию Linux. В подборку вошли новые материалы, уже успевшие «промелькнуть» на профильных площадках, а также литература, которая только готовится к релизу. Сохраняйте в закладки и подписывайтесь на блог.

Автоматизация тестирования абсолютно неотъемлема и необходима в современной разработке программного обеспечивания. Ее преимущества известны всем, что делает автоматизацию тестирования желанным для применения. Факт, отказ от ручного тестирования, сокращение затрат и автоматизация в спринте (in-sprint automation) подталкивают компании внедрять автоматизацию как можно скорее в собственные проекты. У каждой компании свой подход к достижению цели. Однако, они все совершают одинаковые ошибки в процессе внедрения автоматизированного тестирования.

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

О личном опыте в обучении тестировщиков и использовании SMART

Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.

Это следующие причины:

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

● Не всегда было очевидно, какие пробелы в знаниях и опыте есть у сотрудника.

● Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.

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

Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.

Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.

Этот тезис больно ударит по вашему самолюбию, если вы привыкли к уровню обслуживания «нет в ТЗ – идите мимо». Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.

Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?

А имеете ли вы моральное право задавать такие вопросы? Проверьте, что из этого списка вы сделали для этого:

Задачи стали проходить тестирование быстрее. Я просто добавил на сервер...

Здравствуйте! Под катом, опыт небольшой команды из Челябинска, которая делала релизы не вовремя, а потом изобрела велосипед. Если вы только строите процессы или вас мучает совесть из-за отложенных релизов, возможно этот опыт пригодиться. Также буду рад критике. Добро пожаловать!