Менеджмент

Вы запустили рекламу, вложили бюджет, получили заявки... и с ужасом обнаружили, что каждый новый клиент обходится дороже, чем вы зарабатываете на нём. Знакомая ситуация? Вы не одиноки.

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

По данным Gartner, до 70-80% BI-инициатив не достигают поставленных целей, доля активных пользователей не превышает 30-40% количества лицензий, а аналитики тратят половину своего времени не на инсайты, а на рутину. И главная причина этого фиаско кроется не в недостаточной производительности серверов, элегантности дашбордов и даже не в качестве данных. Проекты буксуют, а инвестиции не окупаются из-за людей: их привычек, страхов, устоявшихся ритуалов принятия решений и, как следствие, активного или пассивного сопротивления новым инструментам. В этой статье я расскажу о новом подходе, который позволяет системно подойти к вопросу работы с сопротивлением для CIO, CDO, руководители бизнес-функций, продакт-менеджеров BI и лидеров аналитики. В этой статье мы начнем знакомиться с системным, человекоцентричным подходом к преодолению сопротивления, который уже был неоднократно опробован на практике.

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

Было время, когда все было под контролем у небольшой команды админов и всегда можно было спросить — а чье это и для чего. Но времена меняются. Когда у вас несколько тенантов в Cloud Director, с десяток VDC и куча администраторов, каждый из которых делает что хочет, плюс микс из собственных VMware-кластеров и мощностей у провайдеров, разобраться в этой каше без 100 грамм просто нереально. Наливать мы вам, конечно, не предлагаем (на работе все-таки). А вот системный подход тут необходим как воздух.

Эта статья вторая в серии из трех, посвященных FinOps применительно к Cloud Director. В части 1 мы разобрали теоретическую модель тегирования. Теперь посмотрим, как эту модель применить в VMware Cloud Director и как нам в этом помогут metadata.

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

Решать такие задачи помогают современные SRM-системы. В 90-х эти решения использовались как надстройка к ERP, но с развитием информатизации их функциональность расширилась. Компании пришли к выводу, что обычной автоматизации процессов закупки внутри компании недостаточно и взаимоотношения с внешними контрагентами также нужно автоматизировать. Особенно актуально это стало в 2000-х, когда выросла конкуренция за надежных партнеров, а глобальные цепочки поставок усложнились. Рассмотрим эти решения подробнее.

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

Привет, Хабр! Меня зовут Вадим Крысин, я начальник отдела разработки решений для анализа данных в «Газпром ЦПС». Еще недавно работа с отчетами у нас занимала недели. Данные собирались из разных источников, на разных инструментах, а дашборды каждый отдел собирал по-своему — со своей логикой, метриками и дизайном. BI оставалась удобным инструментом для узкого круга специалистов, все остальные предпочитали старый-добрый Excel.

Этот хаос стал отправной точкой в нашем пути кастомизации BI-системы. В этой статье поделюсь основными инсайтами после перехода на продуктовый подход и улучшениями, которые на 57% сократили время на дизайн и в 7 раз ускорили сборку типового дашборда.

Занимаетесь BI-аналитикой и хотите решать свои задачи быстрее и эффективнее? Нуждаетесь в эффективной и своевременной аналитике для менеджмента проектов, но почему-то не получаете её? А может, вы руководитель в ИТ, уставший по две недели ожидать один дашбоард? Этот текст — о том, как решить ваши проблемы.

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

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

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

Счастливый сотрудник - успешная компания.

Привет, Хабр! Меня зовут Катя, я начальник отдела методологического сопровождения проектов в РГС. Как руководителю мне постоянно приходится балансировать между контролем (чтобы всЁ работало) и свободой действий (чтобы всЕ работали). И на практике это куда сложнее, чем кажется. Поэтому хочу обсудить, как правильно передавать полномочия в IT-команде, какие задачи тимлид должен оставить себе и где проходит грань между развитием сотрудников и банальной эксплуатацией.

Вы слышали про 996? Если нет, то вам крупно повезло, честно. А если да –  сочувствую. Если вкратце, то 996 - это социальный феномен, когда ты пашешь с 9 утра и до 9 вечера, 6 дней в неделю, как раб на галере. И гордишься этим. Вот, например, недавно статья в ленте хабра была. А на фото к статье - спящая в офисе одна из директоров Twitter, Эстер Кроуфорд (которую, кстати, это не спасло от увольнения).

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

А насколько вы уверены, что успех – личный или на работе – должен измеряться тем, как сильно ты себя умучил?

Посвящается всем выгорающим ИТ-менеджерам.

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

Обычно про выгорание говорится с придыханием и чувством глубочайшего самопожертвования. Видимо, это должно обозначать диалог вида: «Коллеги, я со своей стороны выгорел, теперь жду ответных шагов от вас».

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

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

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

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

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление в ИТ.

Так почему выгорание - это манипуляшка?

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

И если в менеджменте существует такой объективный инструмент оценки эффективности стиля управления - это модель Ситуационного лидерства Пола Херши и Кена Бланшара, которая четко по двум показателям Мотивация и Компетентность позволяет определить уровень сотрудника и, соответственно, предложить адекватный стиль управления сотрудником в конкретной ситуации, то при оценке эффективности бизнеса такой четкой модели до недавних пор не было. Прежние попытки ориентироваться на финансовые индикаторы, типа прибыльность по EBITDA или капитализация на рынке, носили часто спекулятивный, а иногда и откровенно мошеннических характер, когда перед продажей или выходом на биржу, компании просто накачивали либо токсичными кредитами, что было характерно для финансовых организаций, и тут кризис 2008 года наглядная иллюстрация, или дебиторской задолженностью, чтобы показать впечатляющие результаты продаж и охват рынка.

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

И только появление индикатора ESG (Environment(al) Social Governance) позволило увидеть бизнес-процессы компании и выявить ключевые характеристики, важные для понимания, что и как происходит в компании, и как это отразится на перспективе деятельности компании, а также объективно оценить возможные риски этого бизнеса.

Привет! Я Андрей Леонтьев, тимлид разработки в вертикали Авито Товары. В этой статье рассказываю, зачем тимлиду осознанно прокачивать visibility — управляемую «видимость» инженеров — и как это напрямую влияет на калибровки, промо и скорость получения ресурсов. Покажу, куда «светить фонариком», как выровнять систему ценностей и подбирать инструменты под мотиваторы. Материал пригодится тимлидам, техническим лидерам, PM/PO и инженерам.

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

Привет! Я Таня Богданова, работаю в MWS AI на проекте Copilot Platform и лидирую направление автоматизации тестирования. Зумеры и миллениалы — это не просто ребята из мемов, а мои коллеги, которые частенько закатывают глаза, но в конце концов хорошо влияют друг на друга.

В свои 37 я отлично чувствую зумеров и учусь у них балансу и самоценности. И так же хорошо понимаю людей 40+, которые никогда не скажут: «А почему я вообще должен это знать?», ведь если они чего-то не знают, то молча пойдут и разберутся. Вдохновившись ситуациями из рабочих будней, сегодня мне захотелось порассуждать,  в чем мы обычно не стыкуемся — и что с этим делать. Присоединяйтесь!

Если у вашей службы поддержки есть база знаний, а сотрудники пользуются записными книжками или собирают себе FAQ в Google Docs — у вас нет базы знаний. Мало дать инструмент, надо организовать процесс так, чтобы статьи вовремя актуализировались, добавлялись и удалялись. Как? Сейчас расскажем.

Оценка бюджета на создание минимально жизнеспособного продукта (MVP) — это не просто попытка посчитать затраты на разработку. Для зрелых продуктовых команд это способ формализовать уровень неопределённости, задать ритм итерациям и определить, где именно должна закончиться стадия эксперимента и начаться инженерная реализация.

Discovery как инвестиция в уменьшение рисков

Любой осмысленный MVP начинается с discovery-фазы. Это не про «опросы пользователей», а про калибровку гипотез: кто действительно испытывает проблему, какую ценность мы способны доставить и какой функционал минимально достаточен для теста этой гипотезы. На этом этапе команда работает с качественными данными — CustDev-интервью, проблемными интервью, сегментацией по JTBD и построением CJM.

Финансово discovery чаще всего выглядит как работа небольшой кросс-функциональной группы: продукт-менеджер, UX-исследователь, аналитик. Если ресурса нет, этап можно вынести на аутсорсинг в продуктовую студию, но и в этом случае расходы остаются значимыми — от пяти до пятнадцати процентов общего бюджета MVP.
Это инвестиция не в “слайды”, а в снижение вероятности того, что команда потратит месяцы разработки на то, что пользователю не нужно.

Прототипирование и проверка спроса

После того как гипотеза формализована, задача команды — протестировать её на минимально возможной поверхности. Обычно это интерактивный прототип (Figma, Framer) и посадочная страница, которая транслирует ценностное предложение и собирает реальные реакции пользователей. Иногда этого достаточно, чтобы скорректировать позиционирование или выявить разрыв между заявленным и воспринимаемым value proposition.

Представьте, как себя чувствуют отечественные производители ПО, когда приходят к корпоративным клиентам, а им говорят: «Ну вот у SAP всё давно работает, у Oracle – поддержка по всему миру, а у вас опять продукт упал после очередного обновления».

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

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Менеджмент без коучинга и теории — показываю рабочие фреймворки, которые закрывают 70% задач руководителя.