Менеджмент

Вы слышали про 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% задач руководителя.

Привет, Хабр! Я Анастасия, ведущий менеджер проектов в ЮMoney. Помните поговорку «Одна голова хорошо, а две лучше»? В этой статье — наш живой пример: как мы усилили команды новой ролью куратора и что из этого вышло.

Привет, Хабр! Меня зовут Лиля Ермакова, Service Delivery Manager в Cloudmaster. В своей работе нам часто приходится помогать компаниям настраивать отображение затрат по инфраструктуре в соответствии с бизнес-потребностями

Сначала я хотела рассказать, как просто и быстро проставить метаданные (теги) на виртуалках в VMware Cloud Director и получить первый отчет о расходах. Но, начав писать, пришла к мысли, что FinOps и тегирование — это целая модель учета. Если внедрять ее абы как, без правил, можно сделать еще хуже. А нам этого не надо. Поэтому будем делать по уму и разберем все в подробностях.

Чтобы полностью раскрыть тему и не перегружать информацией, я разбила статью на три части:

Представьте, вы добровольно передаёте партнёру свою долю в доверительное управление — на основе соглашения и дружеского рукопожатия. Вы верите людям, с которыми давно знакомы. А через пару лет вынуждены возвращать эти доли через суд. В офисе полиция, отсутствуют все важные документы и со счетов пропали деньги, в том числе на зарплату 150 человек… Нет, это не сюжет корпоративного триллера — это моя реальная история. Моему первому бизнесу уже 17 лет, и я прошел через арбитражные процессы, прокуратуру и доследственные проверки; сейчас, оглядываясь на трехлетнюю «корпоративную войну», хочу поделиться опытом, чтобы другие не попали в ту же ловушку.

Много кто на Хабре знает мое имя из-за моего проекта dnevniklib - Python библиотека для работы с API МЭШ (Московская Электронная Школа). На пике популярности ее скачали с PyPI 3000 раз! Данный проект являлся моей моей визитной карточкой, многие мои знакомые, которые как и я програмисты, нашли меня именно через мой Github. Да, это было круто, но потом произошло затишье... Я кинул проект в архив и он до сих пор там валяется. Но почему?

Эта статья расскажет о чем сразу стоит позаботится, прежде чем выпускать какой-либо продукт (даже open source) в main ветку

Работая над статьёй ИИ не изменит IT, я обратила внимание, что ключ ко многим проблемам нейросетей — это закон Гудхарта: «Когда мера становится целью, она перестаёт быть хорошей мерой». Закон этот настолько универсальный, что захотелось посвятить ему отдельную статью.

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

«Сделал и забыл» — это не про сайты, не про SEO и не про цифровой маркетинг. В этой статье разберёмся, почему это не чья-то злая воля, а системная закономерность. И как, понимая её, выстраивать устойчивые процессы.

Сотни сообщений без смысла, игнор просьб, срочные задачи в полночь — вот настоящая «корпоративная культура». Я собрал 7 самых больных кейсов рабочего общения.

Говорят, стажёрам нельзя доверять прод — сломают, наделают ошибок, а потом мучайся. В «Авито» решили доказать обратное: дать ответственность сразу и посмотреть, что будет.

В статье — о том, как выглядят испытания для стажёров и у кого точно нет шансов попасть в команду.

Научный коллектив НИУ «МЭИ» разработал обучающую программу «Оценка согласованности проектной команды при принятии решений в управлении качеством». Программа имеет немаловажное значение для сбалансированной работы всей команды при выполнении проектов по менеджменту качества.

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

Привет, Хабр.✌️ Это Люба и Кристина, менеджеры разработки в Контуре. Кроме менеджерских дел мы ведём в Контуре настолки про Kanban.

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