Менеджмент

На одном из недавних FinOps X саммитов Джрордж Паркер и Уилл Форрестер из Salesforce представили примечательный, на мой взгляд, кейс построения FinOps-модели, что называется «на вырост». 

Salesforce является одним из мировых лидеров рынка CRM-систем и предлагает облачные решения, основанные на модели SaaS.

В 2020 году компания приняла стратегическое решение о переходе в публичное облако. Этот шаг потребовал не просто технологической перестройки, но и кардинально нового подхода к управлению облачными финансами. Поскольку теперь каждый инженер мог напрямую влиять на расходы (читай — создавать объекты расходов), традиционные методы бюджетирования — когда ресурсы ограничиваются квотой того, что есть в приватном облаке — перестали быть эффективными.

С 2021 года сотрудники в разных исследованиях всё чаще говорят: «я хочу регулярный, полезный фидбэк». В разных выборках от 80% до 96% респондентов отмечают пользу обратной связи и её влияние на мотивацию. Но статистика показывает ужасную разницу между желанием и реальностью: по данным Gallup и Happy Job, более 75% сотрудников не получают достаточно обратной связи, и лишь около 16% считают её действительно полезной.

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

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

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

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

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

Заслуживает ли карьера руководителя твоего внимания?

Почему ты пашешь за троих, а повышают коллегу?

А что, если ты всегда хотел в менеджмент — но не понимал, с чего начать?

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

Зачем вменять совершение финансовых операций и других сделок с денежными средствами, полученными за разглашение коммерческой, налоговой или банковской тайны, в качестве легализации (ст. 174.1 УК)? 

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

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

Я видел сотни команд, которые пытались внедрить систему управления и бросали через пару месяцев. Каждый раз звучал один и тот же вопрос: как сделать так, чтобы команда начала работать в системе?

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

Если вы пишете, потом переписываете, рефакторите, а снова переписываете – вы что-то делаете не так. Другая крайность – пытаться всё сделать идеально с первого раза, а так как это невозможно для сколь-нибудь нетривиальной задачи, то можно войти в ступор. Описанные ниже идеи могут помочь в этих случаях, дав некоторый критерий того, что уже можно писать код, так как понимания достаточно. Или того, что уже нужно писать код, так как понимания достаточно и дальнейшее промедление — это прокрастинация в чистом виде или саботаж.

Привет, Хабр! На связи руководитель проектов редакции компьютерной литературы издательства «БХВ» @Holmogorov. C 15 по 19 октября во Франкфурте проходило, пожалуй, самое известное мероприятие, которое каждый год собирает сотни тысяч читателей и тысячи книгоиздателей со всего мира. Речь идет о международной книжной ярмарке, известной под  названием [Frankfurt Book Fair](https://en.wikipedia.org/wiki/Frankfurt\_Book\_Fair), или, на языке организаторов, Frankfurter Buchmesse. Несмотря на сложную международную обстановку и объективные трудности, превращающие получение европейских виз в увлекательный квест, мы побывали на этой выставке, чтобы оставаться в курсе последних тенденций на рынке компьютерной и технической литературы. О том, что мы там увидели и услышали, мы хотим вам сегодня рассказать.

Представьте: в одном углу опенспейса — молчаливый архитектор, который рисует новую схему взаимодействия микросервисов. Рядом — дотошный QA-инженер, который на код-ревью проверяет не только логику, но и нейминг переменных. Его сосед — бэкенд-разработчик, который одной уместной шуткой снимает напряжение перед дедлайном. А по коридору несётся энергичный тимлид с криком «Ребята, я придумал, как ускорить деплой!». Это не сцена из сериала «Кремниевая долина» — это ваша команда разработки, если посмотреть на неё через призму теории Белбина.

Дисклеймер: эта статья написана для руководителей и владельцев малого и среднего бизнеса, которые не являются IT-специалистами. Если вы — опытный сисадмин или CIO, вы вряд ли найдете здесь глубокую техническую экспертизу. Наша цель — объяснить суть и пользу ИТ-аудита языком бизнеса, чтобы помочь управленцам и айтишникам лучше понимать друг друга.

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

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

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

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

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

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

Перестаньте уводить трафик из Telegram на внешние сайты.

Это "черная дыра", которая сжигает ваш бюджет.

В 2025 году ключ к успеху — нативные воронки.

В этой статье: как построить бесшовную связку "Канал -> Бот -> Mini App", какие рекламные форматы внутри Mini Apps дают максимальную конверсию, и как использовать "снайперский" таргетинг на Premium-пользователей, чтобы находить самую платежеспособную аудиторию.

Мы часто слышим: «Agile умирает». На практике же проблема не в Agile, а в том, как его применяют. Там, где он превращается в набор ритуалов, команды тратят больше времени на согласования и отчеты, чем на сам продукт.

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

Крупные компании используют Jira по привычке — инструмент создавали для небольших команд, но его пытаются применять и в энтерпрайзе. Если вы управляете масштабными продуктами и используете масштабированные фреймворки (SAFe, LeSS и другие), вам нужны специализированные решения, и Jira с этим не справляется.

Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Внедрял гибкие методологии в различных компаниях — от 50 до 1000 человек. В нескольких из них ускорил выпуск новой функциональности в четыре раза, что помогло компании адаптироваться под сложный рынок. Работал с Jira как администратор, настраивал её для получения статистики по командам. Сталкивался с ограничениями этого решения и в маленьких компаниях, и в крупных.

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

Стал замечать, что в современной продуктовой разработке царствует методологический хаос и даже фреймворкоблудие. Продакты и команды мечутся между удовлетворением «потребностей пользователей», решением «задач» через Jobs to be Done и внедрением «геймификационных механик», не особо вникая, как эти концепции связаны между собой.

Результат довольно предсказуем: продукты, которые прекрасны на бумаге, не находят отклика у аудитории.

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

Привет, Хабр! Меня зовут Анастасия Клевцур, я продакт модуля «Структура компании» в Битрикс24. Сегодня расскажу, как мы делали функционал кросс-функциональных команд — решение, которое позволяeт сотрудникам из разных отделов работать над общими проектами, не ломая привычную оргструктуру и не теряя управляемости процессов.

— Сколько у нас специалистов в поддержке?
— Четыре!
— А сколько у нас обращений в час?

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

Всем привет! Меня зовут Полина Кощеева, я бизнес-аналитик в домене «Управление персоналом» «Группы Лента» (Lenta tech). В статье хочу поделиться кейсом, как мы через внутреннее обучение коллег решили одну из «любимых» болей бизнес-аналитиков – бесконечные разъяснения схем бизнес-процессов.

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

Если постоянно работать с Канбаном, он становится привычным и кажется, что уже невозможно в нем что-то изменить. Но нет, эта структура не идеальна.