Менеджмент

Появление новых требований в разгар проекта — настоящая головная боль для любого проектного менеджера. Они возникают внезапно, как метеорит в SimCity, и угрожают разрушить сроки, бюджет и нервы команды. Неважно, кто виноват — аналитик, недоглядевший нюансы, или заказчик, который понял, что надо было делать по-другому Важно, что эти «межпланетные тела» могут разрушить всё, если не знать, как с ними справляться. В этой статье мы разберём, как с помощью системы класса service desk превратить хаос изменений в управляемый процесс, сохранить при этом контроль над проектом и доверие заказчика.

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

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

Так я увидел, на что реально трачу время. Много думал.

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

Знакомо?

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

«Я не боюсь того, кто изучает 10 000 различных способов управления. Я боюсь того, кто изучает один 10 000 раз». Выбрали по одному самому «смертоносному» инструменту планирования и управления, и объяснили почему.

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

Вот для примера КХЛ, которая далеко позади футбола по прибылям, чтобы показать на пальцах, сколько зарабатывают клуб и стадион.

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

Поэтому давайте разберёмся, как же зарабатывают стадион и клуб.

Эти сущности часто неразлучны, как Бойль с Мариоттом. В России всего два-три футбольных клуба, которые реально владеют своими стадионами. Это, например, «Открытие Арена» у Спартака или «Краснодар» Галицкого, который вообще частный. Все остальные, по сути, просто арендуют площадки.

Как попытки быть ближе к пользователю иногда отдаляют от цели

В одномстартапе мы решили сделать по уму — активно собирать и учитывать обратную связь.
Видим комментарий: «Сделайте поиск попроще» — переделываем.
Пишут: «Темная тема нужна обязательно!» — добавл яем.
...

Создавать что-то новое — неважно, будь то продукт или команда — интересно и сложно. Зачастую по чужим готовым лекалам действовать не получается. А если это «новое» создаётся в большой компании, изменения надо стыковать со многими элементами действующей структуры. Короче, задачка получается со звёздочкой.

Меня зовут Даша Боровик. Сейчас я руководитель команды экспертов по клиентскому опыту и доступности в RUTUBE. А пару лет назад передо мной встала непростая задача — внедрить новую роль в компанию и собрать команду с нуля. Я искала материалы, которые бы подсказали мне, что и в какой последовательности делать — но, казалось, ни одна из найденных статей и заметок не подходила мне идеально. 

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

Карьерный рост инженера — это не всегда про переход в менеджмент. Есть и другой путь, в котором нет подчинённых, one-on-one и KPI, зато есть влияние на архитектуру, стратегию и технологическую зрелость компании. Уровни Staff и Principal Engineer — это не просто «старшие разработчики», а ключевые технические роли, которые помогают бизнесу двигаться вперёд.

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

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

Мы — команда тестирования в IT-департаменте крупной компании. За годы работы мы накопили опыт борьбы с рисками, которые возникают при выпуске релизов. Сегодня расскажем, как мы их классифицировали, минимизировали и превратили в управляемый процесс.

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

Привет, Хабр! меня зовут Антон Тарасов, я — продакт менеджер и автор телеграм‑канала «Будущее работы» о трендах на рынке труда, о которых нужно знать всем айтишникам, чтобы не остаться за бортом в ближайшее десятилетие.

Недавно я прочитал книгу «Rethinking Work». Название можно перевести на русский как «Переосмысление работы» автора Рашида Тобакковала. Она пока вышла только на английском языке, но я решил собрать основные идеи о работе в IT в этой статье.

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

Книга написана о современности и будущем работы в целом, как для нанимателей, так и для наёмных сотрудников. Но так как мы все здесь работаем в ИТ, затрону моменты, которые будут полезны именно айтишникам.

Итак, поехали!

Всем привет! Меня зовут Макаров Иван, я руководитель программы Tech for Tech проектов в Magnit Tech. Последние 1,5 года мы реализуем масштабный технологический проект по выносу наиболее критичных информационных систем из единой платформы-монолита на выделенную инфраструктуру. Проект интересен своим масштабом и сложностью, и сегодня я расскажу, как мы справились с высоким уровнем неопределенности, скрытыми зависимостями, требованиями бизнеса и другими трудностями.

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

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

Мы в редакции журнала «Конверт» (экс блог Unisender) собрали подборку подкастов, которые помогут прокачать управленческие навыки и подскажут, как перестать «чинить баги» в рабочих процессах и начать строить сильную команду.

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

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

Привет! Меня зовут Герман Лышков, я руковожу проектами в диджитал-продакшене Далее. Если вам когда-то приходилось оценивать разработку сферического коня в вакууме, это статья для вас. Я расскажу, как это сделать и дам пару советов из личного опыта. 

Всем привет!

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

Года полтора назад я проводил интервью с IT-предпринимателями и инвесторами в рамках одного проекта для айтишников — «Zero or One». Проект через некоторое время пришлось заморозить, но от него остались хорошие и полезные материалы из тех самых интервью.

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

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

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

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

Докажем, что регулярные переработки — самовоспроизводящее зло, и покажем, в чём это проявляется, чтобы руководство и сотрудники максимально дистанцировались от этой практики на постоянной основе.

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

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

Главная мысль: переработки плодят ещё больше переработок и гробят бизнес.

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

Когда‑то давным‑давно, аж в далёком 2002 году, мы с другом проходили первую часть Silent Hill на первой PlayStation. В этом месте могли бы быть слова восторга и трепета от атмосферы, саспиенса, сюжета и музыки моего любимого Акиры Ямаоки, но сегодня мой пост не про это.

Полностью игру нам тогда пройти не удалось... И не потому что она была сложная или страшная. Нет‑нет. Потому что там была корявая локализация. Те, кто играл в видео‑игры в конце 90-х и начале 00-х должны помнить «замечательные» переводы от Фаргус с их слоганом‑издевательством «только качественные переводы». И если по сюжету всё было более‑менее понятно, то с головоломками, где важны нюансы, была полная беда. И если на экране был виден текст оригинального письма, записки, таблички, то знание английского спасало (хотя тогда он был у меня так себе). А поменять язык полностью нельзя было. В итоге мы упёрлись в ряд квестов, которые решить было нереально, так как текст перевода был и кривой, и битый. Walkthrough тогда не было, поэтому игра так и осталась незавершённой где‑то на 95%.

К чему эти мемуары? Прошло больше 20 лет, но что‑то я сталкиваюсь с похожими парадоксами и по сей день. И это не игры, а мобильные приложения крупных международных компаний. Дабы быть local‑friendly, разработчики делают автоматическую локализацию приложений в соответствии с регионом или системными настройками смартфона. В итоге это выглядит иногда кринжово, иногда смешно, но чаще очень раздражающе, когда надо воспользоваться сервисом, а там «утюг для корочек парашюта». И речь идёт не про автоматическую локализацию каталогов, как у «алика» например, а даже про какие‑то базовые фичи. И вишенка на торте — язык вручную поменять нельзя.