Управление персоналом *

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

Skill ≠ ресурс

Управленческие навыки – это когнитивные схемы и поведенческие алгоритмы. Они помогают эффективнее решать задачи, но сами по себе не восполняют энергию. Более того, их осознанное применение требует дополнительных когнитивных затрат.

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

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

Классическая кибернетическая модель коммуникации Винера предполагает, что есть источник, отправляющий сообщение с информацией, и получатель, который его принимает. В канале между источником и получателем возможны искажения и потери (например, эмоции, неточные формулировки, если отправитель и получатель это живые люди). Но смысл при этом считается существующим заранее, а задача коммуникации состоит лишь в том, чтобы доставить его без искажений, насколько это возможно. Именно из такой модели исходят, например, авторы книг по регулярному менеджменту, когда описывают принципы постановки задачи подчинённому или объясняют, как сотрудник должен отчитываться о проделанной работе. Та же логика лежит в основе большинства гайдов по проведению маркетинговых или UX-исследований, где предполагается, что исследователь сначала формулирует чёткий список вопросов, задаёт их стандартизированным способом и собирает ответы, из которых извлекается знание о проблеме. Всё это хорошо согласуется с более широкой установкой позитивизма: стремлением уменьшить неопределённость мира с помощью стандартизации и точного языка.

На протяжении всего курса мы постоянно фиксировали некие функциональные роли и круг их обязанностей, характерный для каждой конкретной стадии производства. Теперь постараемся собрать все эти активности в единый атлас ИТ-специальностей, с распределением функций каждой роли, по этапам и стадиям.

Естественно, что весь этот сложный механизм приводится в движение благодаря непрерывному и слаженному взаимодействию всех специалистов в формате командной работы. Мы уже рассматривали основные алгоритмы организации команд в части “4. Классификация производства по структуре команд”

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

В Федеральном законе от 03.12.2012 № 236-ФЗ профессиональный стандарт определяется как характеристика квалификации, необходимой работнику для осуществления определенного вида профессиональной деятельности, в том числе выполнения определенной трудовой функции.

Градация квалификаций основана на нескольких характеристиках:

Привет, Хабр! 

В этой статье я хочу рассказать о том, как и зачем мы в «Рексофт» строили интеграционную платформу BRAIN ERM, которая объединяет HR бизнес-процессы, проектное управление и финансы в одной экосистеме.

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

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

Плюс к тому - высокая стоимость всего HR‑цикла. Найм, адаптация, обучение, оценка, увольнение. На каждом этапе мы теряем время и деньги. И главное - нет системной работы с талантами. Люди, которые могли бы стать лидерами, уходят просто потому, что их проблему заметили только тогда, когда они уже написали заявление.

Страсти по удалёнке не утихают: кто-то выводит сотрудников в офис, кто-то испытывает трудности с построением распределённой хоум-офисной архитектуры, кто-то делает её бонусом и инструментом мотивации. Понять можно всех: на удалёнке иногда непросто работать, удалённой командой непросто управлять. Удалёнщик значительно отличается от офисного сотрудника, особенно если на его «привычку» ушли годы. Если в компании гибридная форма присутствия, появляются конкуренция и подковёрные игры. Если контролировать, люди уходят, если не контролировать — некомфортно менеджменту. Такие ситуации добавляют нервозности и заставляют искать выход, который зачастую оказывается неверным (например, устанавливаются системы слежения для «домашней» команды). Попробуем собрать опыт в кучу и проанализировать, а что такое сложилось за 6 лет всеобщего интереса к удалёнке, что можно всем использовать и при этом никого не обижать 🙂

Протестировала 11 таск-менеджеров для личной продуктивности и управления проектами. Делюсь критериями выбора, типичными ошибками и чек-листом, который сэкономит вам недели на внедрение.

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

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

Через несколько недель погружения стало понятно: дело не в том, что команда работает медленно или недостаточно старается. Мы просто никак не планировали ресурсы. Задачи брали по мере поступления и какое-то время справлялись, но в какой-то момент эта схема перестала работать.

Представьте: менеджер по продажам уходит из компании. Уходит со скандалом, забрав часть клиентской базы. Через три месяца он всё ещё состоит в рабочем Telegram-чате отдела, читает обсуждения новых сделок, видит, кто из клиентов недоволен. Использует эту информацию или просто злорадствует — неважно. Важно то, что компания об этом не знает.

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

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

Я Степан Сорокин, Delivery Manager в Outlines Tech. За 10+ лет в ИТ я несколько раз попадал в компании, где ответственность отделяли от полномочий, а название роли не совпадало с реальной задачей. В статье разберу, что такое агентность в работе менеджера, почему её мало и что с этим делать.

Эта статья — не про методологии вроде TOGAF или Zachman Framework в их классическом корпоративном понимании. Это про системное мышление применительно к построению и масштабированию компаний. Целевая аудитория: технические основатели, CTO, и тимлиды, которые выросли из «решаем проблему кодом» в «строим организацию». Я постарался подсветить выход из тоннеля.

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

Иногда компания ищет такого специалиста 2–4 месяца, проводит десятки интервью — и всё равно не находит подходящего кандидата.

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

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

О каких же процессах пойдет речь? О базовых, конечно!

Откуда растут ноги у проблемы

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

Представьте себе Васю. Он прекрасный дизайнер, и вроде бы всё у него отлично: проекты есть, коллеги доверяют ему как товарищу и профессионалу, да и зарплата достойная. В общ��м, сидит он и никого не трогает. Но тут приходит Люба — очень амбициозный джун, да так вливается в работу, что догоняет Васю всего за год!

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

Давайте посмотрим, как выглядит эта «плевая задачка» на разных уровнях управления.

Спойлер: это хроника погружения в аццкую бездну.

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

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

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

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

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

Вы открываете вакансию. "Дружный коллектив", "карьерный рост", "гибкий график". Красиво. А через три месяца вы сидите в субботу с ноутбуком, доделываете работу за троих и думаете: "Где я свернул не туда?".
Я взяла 146 000 вакансий, прогнала их через семантический анализ и сравнила худшие 10% с лучшими 10%. Оказалось, что «закулисье» выдают конкретные фразы — и их можно перечислить.

Привет, я Виталий, и я управляю проектами в KTS. Это должна была быть третья завершающая статья, где я делюсь своим опытом об обучении в Стратоплане на курсе CTO.

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

- экономическая ситуация;
- ожидания заказчиков — объект поставки сместился с хорошего кода, соответствующего ТЗ, на оптимальное решение едва сформулированной потребности бизнеса;
- производственный процесс — те, кто собирают MVP по два месяца, отправляются на свалку истории;
- требования к кандидатам на рынке труда — приходится искать не просто кодеров, а инженеров с продуктовым мышлением;
- пытаясь не утонуть в этом шторме, поменялся и я.

В этом новом контексте я чувствую особенную важность нескольких тем из курса, поэтому я сфокусируюсь именно на них.

Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются.

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