Привет, я Максим Королев из Петрович-Теха, цифрового партнера сети строительных магазинов «Петрович». Компания специализируется на продаже стройматериалов, комплектации крупных объектов и комплексном обслуживании, включая доставку и подъем на этаж. В первой статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM, во второй — как вынесли бизнес-логику «Дежурного» в CORE и подключили MAX.

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

Привет, я Максим Королев из Петрович-Теха. В прошлой статье про «Дежурного» я рассказывал, как мы ушли от «толстых» обработчиков aiogram к архитектуре CORE + два адаптера — Telegram и MAX.

С замедлением Telegram стало понятно, что нам нужен стабильный резервный канал. Часть команды уже перешла на MAX, часть осталась в Telegram. И вот мы столкнулись с классической проблемой: один коллега пишет в TG, другой отвечает из MAX — диалог разрывается, контекст теряется, инцидент ведется «вслепую». Нужен был мост. И мы ввели параллельную работу в Telegram и в MAX, соединили эти два мира между собой и глубже встроили бота в процессы ITIL 4/ITSM. 

Главное сделали так, что:

12 марта в Санкт‑Петербурге студия разработки цифровых решений CleverPumpkin провела бизнес‑завтрак для руководителей продуктовых, digital‑ и IT‑команд. Собрались поговорить о довольно простой и одновременно сложной вещи: как управлять, когда вокруг постоянно меняется контекст, решений становится больше, а времени на них меньше.

Менторинг, ситуационное лидерство и AI — три темы, которые особенно часто упоминались на бизнес‑завтраке CleverPumpkin. Разговор получился довольно честным. Ведь никто не пытался формулировать универсальные советы. Скорее наоборот, стало ясно, что в нестабильной среде идея одного правильного подхода просто не работает. Руководителю приходится постоянно пересобирать свою роль и способы управления.

Собрали несколько управленческих инсайтов из выступлений и дискуссии.

Привет, я Максим Королев из Петрович-ТЕХа. В предыдущей статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM. Один из ключевых - «Дежурный»: с ним администраторы фиксируют аварии, регламентные работы и прочее, создают задачи в Jira, публикуют уведомления в каналы и в интранет компании.

И тут Telegram ограничивают. Когда у дежурного в разгар аварии «не грузится телега» - это риск для бизнеса. Нужно было срочно решать проблему.

Единственной стабильной альтернативой оказался - да-да - MAX. У него есть Bot API, он не попадает под ограничения РКН и уверенно работает на территории РФ.

Задача не «сделать второго бота с нуля», а сохранить одного логического Дежурного и дать ему второй вход из MAX. В статье расскажу, как я изменил архитектуру: вынес всю бизнес-логику в отдельный слой CORE, а Telegram и MAX сделал вызовами команд этого ядра.

Привет, я Максим Королев из Петрович-ТЕХ, занимаюсь уровнем сервиса. Моя роль — в том числе про “как хороший сервис показать пользователю, чтобы тот не отказался от нового/сложного/страшного инструмента”.

Было так: не все пользователи ходили в техническую поддержку по “правильному” маршруту, через портал. Из-за этого мы теряли случаи, составляющие общую картину проблем, и озадачились: как упростить пользователям заход в поддержку?

Решили сделать семейство Telegram-ботов, которые сократили время на создание повторяющихся задач на 50–70%, подняли заполняемость до 100%, ускорили реакцию на инциденты.

Если в новом году хотите запилить много микроавтоматизаций через боты, наш кейс к вашему столу: вот как вышло у Петрович-ТЕХа.

Привет, Хабр! Я Дима, руковожу отделом информационных технологий бэк‑офиса в «Петрович‑Тех». Давно не делился историями, решил рассказать о нашем проекте по работе с восьмилетним HTML‑легаси, то есть порталом технической поддержки.

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

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

Привет, Хабр! Я Катя Павлова, работаю в «Петрович-Тех». Последние 8 лет я пытаюсь управлять проектами, а 30 апреля 2025 года получила сертификат РМР.

В этой статье поделюсь опытом, как можно сдать на РМР в 2025 году, не продавая душу дьяволу. Ну, почти.

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

Да, у нас есть стандартные коды 400, 404, 500 и прочие популярные ошибки, но есть и куча других. Не знаю как вы, а мне периодически приходится выяснять, что значит та или иная http-ошибка и как их воспроизводить. А когда приходят задачи из категории «проверить логирование ошибок запроса ....», то иду гуглить, как их провоцировать.

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

Всем привет! Это снова Саша Басун — системный администратор «Петрович-Теха». Я пришёл поделиться решением проблемы, которая периодически встречалась мне раньше. Правда, потребность в её решении не была критичной, так как затрагивала минимум пользователей.

Другое дело, когда проблема появляется уже у десятка, а то и у сотни пользователей. Здесь без логичного решения уже не обойтись. Так произошло и в этот раз, но давайте по порядку. Все началось с ухода эпохи Skype и с Windows, не видящего корпоративный софтфон.

Всем привет, коллеги‑тестировщики и интересующиеся. Я Сергей, Senior Manual QA Engineer в «Петрович‑Тех».

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

Сегодня поговорим о не особо упоминаемом, но одном из самых популярных видов тестирования – санитарном тестировании. О том, когда важно к нему прибегать, кто должен им заниматься, почему его часто путают со смок-тестированием, можно ли полностью его автоматизировать и как правильно его организовать.

Привет, Я Саша Басун — системный администратор в «Петрович-Тех». Я уже писал на Хабре о пользовательских проблемах, и мне нравится автоматизировать такие задачи. В их решении есть своя магия.

Статья будет о возможностях донастройки FortiClient VPN под пользователя. Эту информацию также можно вытащить из документации — но парадокс в том, что для её чтения нужен работающий VPN.

Мы устанавливаем VPN-клиент в автоматическом режиме с нужными настройками. Через несколько секунд после подключения к серверу на рабочей станции должен запускаться определённый процесс. Ключевое слово — «должен»: он не всегда срабатывает как должно. Мне нужно было понять, в чём проблема, и найти решение для стабильного запуска.

Привет, Хабр! Я Даша Чумудова, менеджер продукта в e‑com команде «Петрович‑Тех». Вокруг много историй про специфику fintech и edtech. Спустя год в «Петрович‑Техе» мне хочется поговорить про особенности работы в DIY.

Одно дело — разрабатывать цифровой продукт, который имеет самостоятельную ценность. Совсем другое — пилить сайт или приложение для оффлайн‑бизнеса. Без физического продукта это цифровое решение бесполезно, и может показаться, что для продакта в нем не хватает вызовов.

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

Привет, Хабр. Меня зовут Александр, и с недавнего времени я работаю системным администратором в «Петрович-Тех». Не так просто поделиться локальной проблемой, когда регулярно читаешь лонгриды о каких-то масштабных продуктах, в том числе и разделе «системное администрирование» на Хабре.

Но потом я подумал: «А какая у меня цель?». Очень простая. Помочь коллегам, которые, возможно, столкнулись с аналогичной проблемой и не смогли её победить. Да и сама мысль о заметке появилась после того, как я сам не нашёл в интернете решение. Может, просто плохо искал 🙂

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

Всем привет! Меня зовут Сергей, я — Senior Manual QA Engineer в »Петрович‑Тех», и в этой статье я предлагаю разобрать граничные значения на практических кейсах.

Думаю, почти любой тестировщик вспоминает граничные значения первыми из всех техник тест‑дизайна. Особенно на собеседовании. Граничные значения звучат просто и понятно, про них легко рассказать, потому что даже из названия ясно, где и как они применяются.

Несмотря на то, что техника простая — она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой.

Разберем в статье конкретные примеры использования этой техники.

Здравствуй, Хабр! Меня зовут Оняков Федор, я старший Web-программист в Петрович-Техе. Но сегодня мы будем говорить не о моей работе: уже больше четырех лет я развиваю свой умный дом и помогаю делать умные дома друзьям и коллегам.

Одни приходят к умному дому из соображений экономии, другие – ради комфорта, третьи – из любопытства. Среди историй есть драматические: был приятель, который чуть не затопил 9 этажей соседей, другой чуть не устроил пожар из-за камина. После они всерьёз занялись автоматизацией бытовой инфраструктуры. Истории объединяет смена точки зрения: люди думали, что умный дом – это какое-то баловство для богатых, а сейчас выстраивают автономные системы, упрощающие жизнь.

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

Всем привет! Меня зовут Сергей Герасимов, я – Senior QA Manual Engineer (да, хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

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

Привет, Хабр! Меня зовут Марина, и я бизнес-аналитик в Петрович-Техе. 

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

Двигатель изменений мы запускаем осознанно, но есть периоды жизни, побуждающие действовать. И их можно спрогнозировать. От нас зависит, во что выльется желание изменений: в домашние DIY-кейсы или в смену карьерной стратегии. На моем пути случался полный цикл работы этого двигателя. А еще были будильники изменений, которые каждый из вас может найти у себя. 

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

Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”.

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

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

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

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

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

Приступим!