Производство хлеба «Никитин-хлеб» закрылось 8 октября 2024 года спустя ровно 9 лет: с 8 октября 2015 года.

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

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

Я не любитель Хэллоуина и всего с ним связанного (ну разве что кроме печёной тыквы). Однако, когда коллеги запланировали активности с размахом, подумалось, что для многих этот день — символ победы над страхом. Помните, как мы в детстве проходили через ночное кладбище или тёмные закоулки, а потом невероятно гордились собой? В этих приключениях заложены сложные биологические механизмы, но мы поговорим не о них — в конце концов, вряд ли на Хабре кто-то собрался выживать и быть лицом к лицу с опасностью жизни и здоровью. Поговорим о страхах других видов.

...и должен ли РП уметь писать ТЗ?

Этому холивару, по-моему, ровно столько же лет, сколько лет проектному управлению в IT.

Границы управления проектами просты: инициация - планирование – исполнение – завершение. Это знает даже джун. Сделай устав, план, делай статусы каждую неделю, а потом проведи финальный показ функционала – и твой проект ждет успех. Все так, правда?

Неправда, так не получается. Оказывается, надо провести нормальный сбор требований на базе качественной постановки задачи, сделать качественное ТЗ, затем сделать детальные спецификации, которые потом разложить в to do на разработку и так далее, и так далее.

Для этого есть соответствующие люди. Должны быть. Но они есть не всегда. Или они есть, но они не обладают достаточной квалификацией. И вот тут начинается «серая зона» ответственности РП, где его может выручить умение в «бизнес-аналитику».  Ну или где РП может гордо сказать, что задач по аналитике нет в его должностной инструкции и пусть все идут нафиг, он не нанимался. Как делать лучше?

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Куда можно пойти поработать, если вы – Руководитель проектов? Есть много сладких названий: Яндекс, Тинькоф, Сбер, Авито, ВК. Есть еще Газ-Нефть-Полиметал-Тех-сырье компании, есть просто ИТ подразделения не ИТ компаний типа Магнита или Технониколь. Есть еще системные интеграторы Т1, IBS, Softline и так далее. Есть ли среди всей этой карусели отличия, и что вы получите, работая в каждой, кроме того что сможете сказать «Я работал в /Name/?

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

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Статья не претендует на 100% знание истины (опыт у каждого свой), но основана на личном опыте автора, который поработал во многих компаниях, прошел больше сотни собеседований сам и прособеседовал не менее нескольких сотен Руководителей проектов из разных компаний.

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

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

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

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

Но, похоже, настало время вернуться к истокам. Всё чаще оказывается, что нужный контент становится недоступным или меняется до неузнаваемости...

Бывает такое, что на вашем проекте есть эксперт, от которого вам надо получить ОК на документацию, или чтобы он сделал важную работу, которая находится на критическом пути проекта. И, внезапно, этот эксперт делать вашу свою работу и давать вам ОК вообще не торопится. Что с ним делать?

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

Эта небольшая статья - продолжение цикла моих статей о том, чего не говорят на курсах РП: о тех самых софт-скиллах, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны эти истории - читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

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

Расскажу, как работать с планированием на ежедневной основе — по сути, на какие кнопки я нажимаю (поговорим про софт), как провожу утро (та самая практика — книга «Магия утра», но в моей собственной интерпретации) и как я лично использую известные фреймворки:

— Getting Things Done, как основа процесса;

— Матрица Эйзенхауэра, как способ приоритизации;

— Метод «Съесть лягушку», как вспомогательный инструмент к Матрице Эйзенхауэра, потому что я всё‑таки ленивый и не всегда сам себе честно отвечаю, что действительно надо сделать в первую очередь.

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

Мы работали на ярких прикольных аймаках, проектируя интерфейсы MES-систем в соответствии с трендами. А потом своими глазами увидели, в какой ад для сотрудников производства это превратилось.

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

На связи Оля Андреева — руководитель группы аналитики по визуализации данных в каршеринг‑сервисе Ситидрайв. Мы в компании внедряем лучшие практики, строим систему отчётности и развиваем BI. Моя команда нацелена на создание красивых, понятных, непротиворечивых и удобных дашбордов для практически всех департаментов компании — от операций, маркетинга до HR. И здесь не обойтись без правильно выстроенной коммуникации с заказчиком.

В самом начале своего пути в аналитике мне очень помогла книга Тома Гривера «Articulating Design Decisions», которая убедила меня в том, что успешно выстроенные отношения с заказчиком творят магию. И хотя она посвящена преимущественно дизайну продукта, 90% описанных в ней практик идеально подходят и для разработки дашбордов. Для меня это лучшее руководство по коммуникациям для аналитиков — я рекомендую всем начинающим специалистам в своей команде начать осваивать подход к работе с заказчиками именно с этой книги.

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

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

Как организовывать наем, взращивать таланты и при этом осознанно развивать культуру компании.

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

При этом хорошая кадровая работа отнимает немало времени — и в длительной перспективе, и непосредственно в рабочем процеcсе.

А сколько же именно? В книге HBR «Первые 90 дней» (ее краткое изложение здесь) приводится диаграмма, наглядно демонстрирующая, что новому сотруднику может потребоваться примерно 3 месяца, чтобы он начал приносить пользу, а еще через 3 месяца он станет безубыточным и начнет окупать вложенные средства.

Всем привет! Я Саша Ворожищев, руководитель мобильной разработки в AGIMA. В интернете сотни статей о том, как важно не выматывать себя на работе, но всё без толку. Согласно недавнему исследованию Хабр Карьеры, более 90% российских IT-специалистов сталкивались с выгоранием. При этом более 40% доводят себя до поздних стадий, когда эмоциональное истощение уже перерастает в депрессию.

В этой ситуации будет полезным напомнить, что любой руководитель может влиять на состояние команды. И это важно не только с точки зрения человеколюбия, но и с точки зрения бизнеса. В конце концов энергичный сотрудник, который любит свою работу, принесет компании больше счастья, чем выгоревший и усталый. Поэтому давайте разберем, как мотивировать команду соблюдать Work-life balance.

Все определения профессионализма, которые можно нагуглить, сводятся к тезису «профессионал — это человек, который делает свою работу хорошо». Но что, в свою очередь, значит делать работу хорошо? Если сотрудник четко и аккуратно выполняет все правила, соблюдает заветы корпоративной культуры, но клиенты недовольны, то это «хорошая работа»? «А если он наплевал на все регламенты, сделал, как нельзя делать, переругался со всеми коллегами, но результат в итоге достигнут, то это „хорошая работа“?

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

Полгода я тратил свободное от учёбы и работы время на свой проект, который не принес мне ничего, кроме опыта.

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

Технологические компании со всего мира ищут квалифицированных и эффективных инженеров, которые бы облегчили общение с машиной и составление инструкций. Екатерина Саяпина, Product Owner личного кабинета платформы МТС Exolve, созданной компанией МТТ (входит в экосистему МТС), разбирается, как попасть в эту волну, какие вакансии представлены на рынке и чему стоит научиться, если вы хотите стать prompt-инженером.