Менеджмент

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

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

Я работаю в ИТ-отделе на производстве. Пришла задача от гендира: «Найти систему для документооборота и работы с проектами. В перспективе будем подключать кадровый электронный документооборот. Поищите, что нам подойдет».

У нас не массовое производство и не ИП, на заводе +-300 человек. В руководящий состав входят примерно 20 человек. Заоблачных требований к ПО нету.

От системы и нас хотели 3-ех вещей:

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

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

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

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

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

Если эти боли вам знакомы, значит, вы уже поняли: вести учет «железа» и софта в 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 — сейчас на должности менеджера по продукту. Как правило, крупные компании берут на такую позицию внешних кандидатов с опытом и наработанными твёрдыми навыками. У меня же опыта работы в этой сфере не было, зато я хорошо знал продукт благодаря многолетней работе в службе поддержки. Это и стало ключевым фактором при выборе кандидата.

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