Менеджмент

Сколько раз вы сталкивались с ситуацией, когда по документам сервер есть, а в стойке его нет? Или когда компания продолжает платить за сотню лицензий софта, которым давно никто не пользуется?

Если эти боли вам знакомы, значит, вы уже поняли: вести учет «железа» и софта в Excel — это путь самурая, но он ведет к финансовому харакири.

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

Именно поэтому ITAM-системы (IT Asset Management, системы управления ИТ-активами) перестали быть роскошью для корпораций и стали гигиеническим минимумом для любого среднего и крупного бизнеса.

Это вторая статья из серии о том, как я готовлюсь к выходу на рынок труда через стратегический анализ. В первой был общий обзор текущей ситуации в финтехе для СРО в РФ. В этот раз — конкретные выводы из PESTEL анализа.

Я Lead группы развития продуктов в Контуре. До управления продуктом я больше 6 лет занималась маркетинговыми и юзабилити-исследованиями.

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

О чем эта статья

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

Триггерит?

Поздравляем, у вас сломана петля обратной связи.

Привет! Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. В нашей практике — проекты со сложной архитектурой, высокой нагрузкой и широким функциональным объемом. В прошлом году, например, мы рассказывали, как за семь месяцев перевели крупное химическое предприятие ПАО «КуйбышевАзот» с Oracle на 1С:ERP. И в таких проектах быстро становится понятно, что успех зависит не столько от количества разработчиков, сколько от методологии. Если этапы не структурированы, роли не определены, а результаты не отделимы друг от друга, даже сильная команда будет постоянно «догонять» сам проект.

Это первая статья из цикла о нашем подходе к крупным внедрениям 1С. Берите на вооружение — наша методологию сэкономила нам сотни часов на реальных проектах.

Знакомая картина? Вечер воскресенья. Вы, вооружившись мотивацией после очередной статьи о продуктивности, открываете свой календарь и любовно раскрашиваете временные слоты с 8:00 до 22:00. Тетрис сошелся, мозг получает порцию дофамина от иллюзии контроля.

Но наступает утро понедельника. В 10:15 прилетает алерт: на проде отвалился важный сервис (или звонит запаниковавший клиент). Вы идете тушить пожар. Когда дым рассеивается, ваш идеальный график разрушен до основания, а вместо удовлетворения вас накрывает липкое чувство вины: «Я снова выбился из плана».

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

Roadmap часто делают для презентаций, а не для работы — и через месяц она расходится с реальностью. В статье вы найдете: 5 форматов визуализации дорожной карты, когда какой уместен, почему PDF — худший выбор, и почему roadmap должна жить там же, где задачи команды.

Meet-Up: делаем видеоконференцсвязь (ВКС), которая не бесит

TL;DR: Накатили свою платформу для видеозвонков на Laravel + WebRTC. До 1000 человек в комнате, без лимитов времени, разворачивается за час на VPS. Коробочная версия + облако. Ищем тестировщиков, которые будут ломать и критиковать.

Disclaimer: ещё один велосипед

Да, мы знаем. На рынке есть Zoom, TrueConf, Телемост, VK Teams и ещё десяток решений.

Но когда на очередном созвоне коллега 20 минут не может подключиться, а ты платишь за функции типа "3D-аватары" и "встречи в метавселенной", которыми никто не пользуется - начинаешь думать.

А можно ли проще?

Спойлер: можно.

Разберемся поподробнее...

Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в эфире. Я смотрю на экран и понимаю, работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да.

Выгорел, следя, чтоб не выгорела команда — иронично.

Специалисты, поработавшие много лет в IT, иногда чем-то напоминают людей преклонного возраста, которые встретившись, начинают рассказывать о наболевшем.

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

Привет, Хабр! Меня зовут Егор Дудин, я технический руководитель юнита «Деловые услуги» в Авито Услуги. В этой статье я излагаю своё видение построения и работы с обратной связью и её роли в крупной IT-компании. 

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

Под катом - кейсы из практики, примеры работы с фидбэком и 13 советов от меня.

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

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

Фаза 1 – высокие стандарты как источник перфекционистской культуры

Высокие стандарты – это естественная часть профессиональной среды. Однако проблемы начинаются, когда эти стандарты превращаются в культуру, где нет места для «неидеального» процесса. Это происходит незаметно:

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

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

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

Детективный контроль позволяет выявлять подобные случае по мере возникновения неблагоприятных событий. Наоборот, предиктивный контроль пресекает подобные исходы на корню. Именно на последних мы и остановим внимание в данной статье. Применительно к программному обеспечению подобный вид проверок тесно связан с термином SOD (Segregation of Duties).

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

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно. Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления. Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: 

• не ломали команду,

• не показывали погоду, 

• работали в пользу продукта и бизнеса. 

Ограничения и рекомендации:

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

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

Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных.

Я выбрала метрики завершенного цикла (рефлексии): они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе «О метриках».

Привет! Я Алексей, мне 31 год, и почти десять лет я работаю в ЮMoney — сейчас на должности менеджера по продукту. Как правило, крупные компании берут на такую позицию внешних кандидатов с опытом и наработанными твёрдыми навыками. У меня же опыта работы в этой сфере не было, зато я хорошо знал продукт благодаря многолетней работе в службе поддержки. Это и стало ключевым фактором при выборе кандидата.

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

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

Живой пример

Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную, и занимался этим не один-два человека, а аж целый отдел. Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

На связи — Катя Лысенко и третья часть статьи о системе онбординга. В первых двух (ч.1 и ч.2) мы разобрали основы: как подготовить почву, выстроить маршрут и создать понятный трек для новичка. Но структура — это только половина системы. Вторая половина — то, что делает её живой: регулярная рефлексия, честный разговор и поддерживающая среда, где человек не боится расти и пробовать.

Служба поддержки может блестяще укладываться в метрику SLA (service level agreement) и «закрывать» сотни чатов в день. Парадокс, но при этом обычно повышается температура: выгорают сотрудники, подгорает у клиентов и они уходят, и, как следствие, сгорает синим пламенем прибыль компании. Ещё один парадокс: это руководство компании само поставило специалистов в такие условия.

Готовых модулей для связки 1С с маркетплейсами сделали уже много, и на лендингах они все выглядят примерно одинаково: заказы, остатки, цены – все в комплекте. Разница проявляется позже — на возвратах, пересорте, маркировке, нескольких складах и попытках переехать на другую конфигурацию 1С без полной пересборки процессов.

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