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

Системы управления ресурсами и экономикой проектов: обзор PSA- и PPM-платформ.

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

Я не один год провел с P&L в Google Sheets и Excel, и смертельно устал каждый месяц сверять все формулы, обновлять ставки и руками перепроверять каждую строчку.

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

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

Я отобрал пять штук на обзор и постарался разобраться, что к чему. Сравнил Timetta, «Первую Форму», ADVANTA, ELMA365 Проекты и Shtab. Потестил демо, насколько это было возможно, и изучил документацию.

Отправить команду на переработку, нанять дорогих специалистов или пересмотреть план - каждое решение меняет ход проекта. На INFOSTART A&PM EVENT 2026 участники смогут проверить такие решения в бизнес-симуляции ИТЕРРА: за 2,5 часа им предстоит спланировать работу, распределить ресурсы и столкнуться с последствиями собственных действий.

О том, как устроена игра и зачем она понадобилась проектному офису, рассказал один из её создателей - Алексей Клебан, руководитель HR «Кодекс Консорциум», психолог и тренер по образованию.

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

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

Расскажу, как я получил свою первую работу программиста 25 лет назад. Потому что мне кажется, именно в этой истории ответ на вопрос, почему сейчас такой трэш на рынке труда в IT. Компания “HBM”, известная тогда игровая контора набирала людей для нового проекта под “Буку”, в качестве тестового задания надо было за месяц сделать простую РТС на чем угодно, но с работой по сети. Я тогда студент второго курса, без портфолио, без опыта, без вот этого всего. Взял задание и вечерами на кафедре, потому что своего компа еще не было, а папин был за 200 км и особо не наездишься, наклепал стратежку с видом сверху про пакманов и призраков, которые собирают точки и стреляют друг в друга. Я не знаю как она работала, потому что там было столько косяков, что работать он в принципе не могла, а если слишком быстро перемещать курсор, то крашилась, и поэтому некоторые пакманы начинали стрелять в курсор и стопать его, если скорость была выше положеной.

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

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

После технического интервью на позицию Go-разработчика я попросил более подробную обратную связь.

Часть выводов в ней плохо стыковалась и с тем, что реально проверяли на собеседовании, и с моим фактическим опытом. Особенно по конкурентности в Go, эксплуатации инфраструктуры и Python/frontend.

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

Вот удивительный факт: согласно исследованию Harvard Business Review, проведенному в 2024 году, только в 43% компаний из списка Fortune 500 есть главный операционный директор (COO), однако те, у кого он есть, сообщают о повышении операционной эффективности на 23%. Так чем же именно занимается весь день этот загадочный руководитель высшего звена? В этой статье мы попробуем разобраться в данном вопросе.

Привет! Меня зовут Дарья, я руковожу продуктом Naumen Project Ruler. Вместе с командой изучаю задачи пользователей и определяю, какие сценарии и возможности продукта нужно развивать, чтобы эти задачи решать.

На статус-митинге руководитель проекта оценил прогресс в 90%, все показатели в зеленой зоне. Команда движется отлично, все по плану. Через месяц все те же 90%. Показатели снова в норме, но почему процент не увеличился? Еще через месяц цифра по-прежнему не меняется. И вот, за две недели до дедлайна статус «краснеет», и выясняется, что до закрытия всех задач нужно не меньше квартала.

Знакомо? Что за магическое число — 90%, откуда оно берется и в какой момент отображает реальное состояние проекта? И в чем тут проблема: РП приукрасил статус, ошибка в планировании либо расчете прогресса? Попытаемся разобраться.

В первой статье я разобрал аббревиатуры, встречающиеся на производстве: от SCADA, PLC и MES до PLM, BIM, EAM и QMS. Получилась нижняя часть корпоративного ландшафта: системы, которые работают с технологическим процессом, оборудованием, проектными данными и производственными операциями.

Но аббревиатуры на этом, конечно, не заканчиваются. Над производством стоит корпоративный уровень, где планируются потребности в материалах и ресурсах, считаются финансы, собираются данные в отчеты и аналитику, а также работает всеми любимый HR. И, конечно, наборов заглавных букв тут тоже хватает. Во второй части я расскажу, как MRP привел к ERP, зачем нужны BI и EPM, чем HCM отличается от HR-систем и что здесь делают ATS, LMS и WFM.

Наша рубрика «Кем работать в IT» — интервью с представителями IT‑профессий, в которых специалисты рассказывают о тонкостях своей работы: плюсах, минусах, подводных камнях и заработной плате. Мы надеемся, что джунам и стажёрам она поможет больше узнать о том, что их ожидает на карьерном пути, а профессионалам — посмотреть на свою специальность через чужой опыт и, может быть, открыть для себя что‑то новое.

Сегодня о своём опыте работы нам рассказал Юрий Кудрявцев, технический лидер backend‑разработки в компании Альфа‑Деньги.

Привет, Хабр! Меня зовут Георгий, руковожу продажами и маркетингом в Аспро.Cloud. За плечами больше пятнадцати лет в B2B-продажах — TELE2, Samsung, Whirlpool, команды до полусотни человек.

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

Знакомое чувство? У него есть имя и почти шестьдесят лет исследований за спиной, хотя ни один психолог образца 1968 года, конечно, не думал о планерках в Zoom.

Если методолог собирает тесты вручную, обучение становится «бутылочным горлышком», тормозит адаптацию персонала и изменения в работе. Пока проверочные задания готовятся, магазины пользуются старыми правилами. Это значит, компания рискует ошибками в сервисе, возвратами и недополученной выручкой. И все из-за того, что сотрудники вовремя не ответили на несколько вопросов, чтобы обновить знания.

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

Бизнес инвестирует в развитие сотрудников и хочет знать, куда и как были потрачены деньги компании. Поэтому руководитель L&D должен уметь не только запускать эффективные программы обучения, но и измерять их ROI. 

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

Руководителю L&D они помогут управлять рисками и запустить обучение, которое изменит поведение сотрудников и результаты их работы. Компании — получить от обучения измеримый бизнес-эффект и финансовую отдачу.

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

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

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Фридманом — экспертом и методологом по регулярному менеджменту, консультантом и автором книг об управлении, в том числе «Вы или вас? Профессиональная эксплуатация подчинённых», а также ведущим YouTube-канала «Александр Фридман & Регулярный менеджмент».

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

Рабочий день закончился. Вы доделываете свои дела, и тут руководитель просит вас подготовить сложный отчёт: «Срочно, никто кроме тебя не сделает. Успеешь за час?».
Вы уже не раз выручали, и это стало нормой.

Разбираем кейс о психологической безопасности и трудных диалогах.

У нас было два репозитория неоттестированного вайб‑кода, семьдесят пять тяжеловесных SDD‑спецификаций, пять обмазанных смазкой харнессов, солонка, наполовину полная кастомных скиллов и забитых капслоком правил, с десяток дырявых MCP‑серверов, RAG‑база со свежевекторизованным Confluence, самодельная дощечка имаго‑кодинга и целая россыпь автономных агентов всех мастей, от безобидных автодополнялок до галлюцинирующих субагентов, ставящих пакеты со slopsquatting и втихаря сносящих боевые базы.

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

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

Нет ничего более беспомощного, безответственного и испорченного, чем IT‑команда, запустившая мультиагентный оркестр в режиме allow all.

Это критический (и слегка ехидный) обзор того, что произошло с разработкой последние пару лет.

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

С ИИ-ассистентом работа джуна выглядит так же аккуратно, как работа сеньора, и по внешнему виду ошибку уже не найти. Если автор не может объяснить, как получил результат, ревьюер восстанавливает путь сам и по сути делает задачу второй раз. Разбираю, где сгорает время старшего, на примере nginx-фикса, и какие требования к сдаче работы это лечат.

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