home.social

#менеджмент_проектов — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #менеджмент_проектов, aggregated by home.social.

fetched live
  1. Методика оценки ИИ зрелости

    Я подготовил и предлагаю к обсуждению методику экспресс‑аудита ИИ‑зрелости промышленного предприятия. Методика представлена в excel (её можно получить по запросу в мой адрес): вы ставите оценки и указываете доказательства — файл считает остальное. Каждый из 30 вопросов оценивается по двум измерениям — техническому (Т) и организационному (О). Итоговый уровень определяется по правилу узкого горлышка как минимум из технического (Т) и организационного (О) уровня, подтверждённого 20 гейтами, и ограничения по кибербезопасности ИИ‑контура. Результат аудита — уровень зрелости, разрыв между измерениями, узкое место, степень преодоления пяти барьеров масштабирования, контрольный срок закрытия гейтов и план на 12 месяцев.

    habr.com/ru/articles/1091518/

    #ии #методика #методики_управления_проектами #методология #методологии_управления #менеджмент #производство #менеджмент_проектов #менеджмент_в_it #эффективность

  2. Хватит пилить слонов под видом MVP

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

    habr.com/ru/articles/1085134/

    #mvp #менеджмент #менеджмент_проектов #менеджер #менеджмент_в_it #команда

  3. Хватит считать токены: почему KPI в эпоху ИИ превратились в фикцию

    Каждые несколько лет индустрия придумывает новую единицу продуктивности. Строки кода. Коммиты. Пул-реквесты. Теперь - токены. Схема одна: берём то, что легко посчитать, вешаем на дашборд и начинаем по этому оценивать людей. Счётчик крутится - значит, работа кипит. Отстающие подсвечиваются красным, лидеры - зелёным, и никто не задаёт неудобный вопрос: а что из этого дошло до пользователя? В 2026-м на эту роль назначили токены. Метрика удобная: она всегда под рукой, её видно в реальном времени, и её очень легко накрутить - достаточно оставить агента работать на ночь. Проблема в том, что она измеряет активность, а не результат. Ровно так же, как когда-то строки кода.

    habr.com/ru/articles/1082736/

    #kpi #метрики #управление_разработкой #продуктивность #продуктивность_разработчиков #технический_долг #качество_кода #менеджмент #менеджмент_проектов #управление_проектами

  4. Когда senior'а оценивают по коммунальным навыкам — это диагноз компетентности руководителя

    Я нечасто работаю с IT компаниями, но 6 моих IT компаний-клиентов, да и общая информация об IT позволила мне сложить впечатление, что люди в IT отличаются от других. В IT больше Синих людей по классификации Клера Грейвса, то есть людей склонных к более аналитической деятельности и восприятию мира через факты, но не через эмоции. При этом у них есть свои особенности с коммуникациями; они лучше общаются письменно и не готовы общаться с незнакомыми людьми не по делу. Для меня это было очевидно, да и для многих тоже, именно поэтому я так удивился, когда тут на linkedin прочитал пост о том, что senior'а чуть не уволили из компании так как у него были проблемы с внешней коммуникацией. Его даже назвали senior со звездочкой, типа с проблемой. И у меня тут возникает два вопроса. Первый вопрос: кто эти руководители в IT, которые оценивают senior по коммукативным навыкам выше его профессиональных навыков, что готовы были уволить такого сотрудника, который в условиях, когда его не гнобили за плохое общение, показал выдающиеся результаты, потому что ему наконец-то дали возможность работать. И второй вопрос. Какой смысл развивать в сотруднике то, что у него не является принципиально важным для работы, в ущерб развития наиболее перспективных качеств, где он реально может быть эффективным. Стратегия Голубого океана как раз заключается в развитии сильных качеств, при этом про слабые качества просто знают и учитывают, без попытки их изменить. Стратегия Голубого океана отлично работает для бизнеса, почему не использовать её идею и для людей. #it #бизнес

    habr.com/ru/articles/1071792/

    #менеджмент #менеджмент_персонала #менеджмент_проектов #управление_командой #управление_людьми

  5. Как запустить двусторонний маркетплейс для подработок, когда на нём ещё никого нет

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

    habr.com/ru/articles/1062412/

    #платформа #маркетплейс #трудная_сторона #холодный_старт #временная_занятость #платформенная_экономика #hr #анализ_рынков #менеджмент_продукта #менеджмент_проектов

  6. Отзыв на книгу «Не усложняй! Управление проектами по методу P3.express»

    Делюсь впечатлениями о недавно вышедшей книге «Не усложняй! Управление проектами по методу P3.express» за авторством @daIlenkov и @lera_ilenkova Это небольшая (~250 страниц) книга по управлению проектами на основе минималистичной системы P3.express, написанная лёгким и доступным языком. Отлично подойдёт для новичков. В сети уже немало отзывов, которые можно свести примерно к этой формуле. Я хочу взглянуть на неё чуть глубже. Это книга-матрёшка. Первый уровень действительно такой, каким его описывают в большинстве отзывов, — хорошо написанная книга, которую можно смело рекомендовать новичкам. На самом деле это ценное качество, потому что в интернете довольно часто спрашивают, что почитать/посмотреть/поучить новичкам по теме управления проектами. Отсылать сразу к PMBOK — и непродуктивно, и негуманно. Что там ещё рекомендуют из года в год? «Дедлайн» Тома ДеМарко? На самом деле отличная книга, люблю её, но сам же признаю, что жанр бизнес-романа имеет свои недостатки и подходит не всем. А надеяться на качественный онбординг на новой работе/роли не приходится — у руководителей проектов это устроено гораздо грустнее, чем у каких-нибудь айтишников. К тому же на эту первую работу ещё надо как-то умудриться попасть, и довольно часто это оказывается переходом на новую роль внутри компании. Но это идеальный случай, а ведь частенько бывает так, что какой-либо проект поручают не выделенному руководителю проектов, а опытному специалисту или руководителю подразделения — в довесок к основным обязанностям. Если до этого они не сталкивались с дисциплиной проектного управления и не имеют внутри организации поддержки от проектного офиса (или чего-то подобного), то приходится устраивать забег по граблям. Книга поэтапно показывает будни менеджера проектов — что вообще он делает и что от него ожидается. Так что если у вас нет возможности заранее ознакомиться с должностной инструкцией, положением о проектном управлении, регламентами проектных работ (а это мало где есть или есть, но частенько не работает), вы сможете понять, что от вас требуется и каких ошибок стоит избегать.

    habr.com/ru/articles/1062078/

    #управление_проектами #p3express #книга #книга_на_русском #менеджмент_проектов #методология

  7. MBA на минималках «Конфликты в команде, как фактор развития бизнеса»

    Конфликты - это то, что обычно очень бояться люди, и бизнес тут совсем не исключение. Именно поэтому, в каждой команде и в каждой компании есть множество скрытых конфликтов, которые не решаются годами, а тихо мешают работать и взаимодействовать сотрудникам друг с другом, лишая бизнес эффективности, и отправляя жизнь людей. Я с этим отчётливо столкнулся на модульном обучение руководителей, когда второй модуль был про деятельность разных отделов в достижении общей цели и про то, что мешает этому. Про отличный инструмент, который показывает как разные отделы работают для общей цели, я расскажу на следующей неделе, а сегодня мне хочется рассказать о том, как озвученные претензии руководителей разных отделов, не убили бизнес, а наоборот впервые сняли недовольство руководителей друг другом. Да, именно так и было, каждый руководитель отдела сказал, что ему не нравится в работе других отделов, что ему мешает работать. Естественно, это часто приходится на совещаниях, но тут в формате обучения, где есть внешний модератор, где все как бы не в рабочей среде, эти слова не переросли в обычную ссору и обиду, а просто дали возможность выпустить напряжение, которое мешало общаться и работать нормально. Потому, что смысл был не в том, чтобы кого-то унизить, а в том, чтобы найти решение подавленным конфликтам, найти решение для бизнеса. И тут важно использовать Алгоритм работы с конфликтом, в котором есть важные моменты:

    habr.com/ru/articles/1057962/

    #управление_людьми #управление_командой #управление_проектами #управление_проектами_и_командой #управление_персоналом #управление_продуктом #менеджмент #менеджмент_проектов #менеджмент_персонала #конфликты

  8. Гант маминой подруги: 7 вещей, которые должна уметь хорошая диаграмма

    Открыть список задач → переключиться на диаграмму Ганта → открыть карточку задачи → перейти в профиль исполнителя → вернуться обратно на вкладку с диаграммой. Повторить десятки раз. Время уходит не на решение задач, а на переключение между вкладками и попытки понять, что вообще сейчас происходит. Рассказываем не про плохого Ганта — а про полезные функции нормальной диаграммы. Читайте статью, чтобы узнать, как делать максимум с помощью проектного инструмента и перестать топтаться на одном месте.

    habr.com/ru/companies/itarena/

    #диаграмма_ганта #гантт #гант #менеджмент_проектов #менеджмент_продукта #jira #lowcode #исуп_управление_проектами #project_management #исуп_для_ит_команды

  9. Театр надёжности: почему половина ваших процессов существует, чтобы выглядеть, а не работать

    После большого падения собрали постмортем. Красивый: таймлайн поминутно, five whys, список action items, ответственные напротив каждого пункта, всё разослали по всем спискам рассылки. Команда поскорбела, поучилась на ошибках, разошлась с чувством выполненного долга. Через полгода — то же падение. По той же причине. Открываем тот постмортем. А там — те же action items. Все до единого. Не сделан ни один. Зато оформлен был аккуратно: и таблички, и цвета, и owner проставлен. Первая реакция на эту историю — «ну бардак, ну разгильдяи, не довели до конца». Реакция понятная и неправильная. Потому что если присмотреться, постмортем не провалился. Он отлично сработал. Просто работа у него была не та, что написана на упаковке. Я вхожу в чужие инженерные команды со стороны — посмотреть, что у них происходит на самом деле, и навести порядок. И почти в каждой натыкаюсь на одно и то же: значительная часть процессов в компании существует не чтобы что-то делать, а чтобы что-то изображать. Это не патология отдельной конторы. Это закономерность, у неё есть механика, и её стоит уметь видеть — особенно если ты за эти процессы отвечаешь.

    habr.com/ru/articles/1050986/

    #менеджмент_проектов #управление_разработкой #управление_командой #devops

  10. Книги для руководителей в эпоху перемен: пять историй о том, как не сойти с ума от цифр и не разлюбить людей

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

    habr.com/ru/companies/onlinepa

    #чтение_книг #чтение #чтение_на_выходные #бизнесмодели #менеджмент #менеджмент_персонала #менеджмент_проектов #управление_командой #карьера

  11. Проверка спроса до запуска продукта: как мы проводим фейкдор‑тесты

    До того как начать инвестировать в разработку продукта, команде стоит проверить, есть ли реальный спрос на продукт и насколько убедительно для клиента звучит ценностное предложение. Для этого на ранних этапах мы используем разные методы валидации гипотез: от анализа рынка и качественных интервью до количественных исследований, fake door тестов, concierge‑подхода и MVP. В этой статье покажу место fake door среди других методов валидации и разберу, как мы адаптируем этот метод в Точка Банке.

    habr.com/ru/companies/tochka/a

    #fakedoor #исследование_пользователей #эксперименты #гипотезы #продукт #менеджмент_проектов

  12. Кодекс самурая для продакта: как я училась выживать в хаосе и отпускать гиперконтроль

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

    habr.com/ru/articles/1042844/

    #управление_проектами #управление_проектами_и_командой #управление_продуктом #управление_временем #менеджмент_проектов #менеджмент_продукта #менеджмент_в_it

  13. Синхронизируем проекты Codex и Claude Code между несколькими устройствами через GitHub (для неинженерных проектов!)

    У меня MacBook Air M4, ПК под Ubuntu 24.04, консальные Claude Code и Codex (каждый хорош немного под свои задачи, как по мне). Я люблю Ubuntu, но вот в поездках Mac прям незаменим — с ним удобно работать, батарея живет достаточно долго, даже в самолете можно комфортно что-то тыкать тачпадом. При этом яблочную экосистему я не люблю, Ubuntu мне ближе и приятнее в использовании. Важный момент: я не программист, так что большая часть моих проектов — это всякая маркетинговая, менеджерская и редакторская штукенция. Поэтому у меня нет под это всё каких-то IDE и т.п. Конечно, разработчики и другие инженеры обычно работают с кодом, а потому просто коммият всё напрямую в гитхаб. Но к делу. У меня постоянно запущено по 6-10 окон Claude и Codex в терминале и я заколебался проекты синхронизировать через Избранное телеграма — зипами. Плюс хочется, чтобы проекты нормально работали и в той, и в другой нейронке. То есть мне понадобилась какая-то система синхнонизации проектов между разными устройствами и разными нейронками. Сегодня наконец собрался с силами и доделал такую — выложил ее под Apache 2.0 на гитхабе, можно пользоваться, форкать, дорабатывать и выражать своё «фи» в ишшьюсах и комментариях. Наверянка уже кто-то что-то такое себе делал и я просто изобретаю велосипед. Но что ж теперь поделать, я его уже переизобрел. В статье расскажу, как делал, что делал, где и что пришлось дотюнивать. Скажу честно, мне эту часть с инструкцией писать было лень и она написана уже GPT, так что простите. Немного пробегусь по стилистике, конечно, но в целом текст править почти не буду.

    habr.com/ru/articles/1041750/

    #claude_code #codex #cli #менеджмент_проектов #система_управления_задачами #система_управления_контентом #нейросети

  14. Чтение на выходные: «Жесткий менеджмент: Заставьте людей работать на результат» Дэна Кеннеди

    Дэн Кеннеди — тот самый автор, чьи книги всегда имеют в названии приписку No B.S. (Без соплей). Его стиль узнаваем с первых страниц: никаких теорий про команду-семью, никакого «сотрудники — наше главное достояние». Только железные рецепты, проверенные на деле, и полное отсутствие желания кому-либо понравиться.

    habr.com/ru/companies/onlinepa

    #менеджмент #менеджмент_проектов #менеджмент_персонала #менеджмент_продукта #менеджмент_в_it #менеджмент_работа_с_людьми #чтение #чтение_на_выходные

  15. Как мы ускорили согласования на двух заводах в 24 раза

    АО «ЗЭТА» заменило Trello и Slack на российский сервис, ускорило согласования с 3 дней до 1 часа и уже 5 лет работает без перебоев. Команда из 150 человек внедрила систему своими силами всего за 1,5 недели. В статье — опыт компании и советы по настройке новых сервисов.

    habr.com/ru/companies/yougile/

    #управление_людьми #управление_командой #управление_проектами #управление #управление_проектами_и_командой #завод #управление_персоналом #управление_проектом #управление_продуктом #менеджмент_проектов

  16. Проектный холст: как менеджеру подбирать «краски» управления под разные команды

    Всем привет! Я Мила, работаю в Positive Technologies администратором проектов экспертного центра безопасности (PT ESC). Занимаюсь организацией процессов, контролем сроков, налаживанием коммуникаций между командами и подрядчиками в кибербезе. По совместительству являюсь профессиональным художником-традиционалистом (акрил, холст, кисти). Да, во мне прекрасно уживаются две эти сущности. Работа менеджера проекта с командой — это не просто контроль и постановка задач, а настоящее искусство. Как художник подбирает краски и техники для создания шедевра, так и проджект должен выбирать стиль общения, подходящий для разных сотрудников и ситуаций.

    habr.com/ru/companies/pt/artic

    #управление_людьми #роли_в_команде #менеджмент_проектов #живопись #искусство

  17. Как управлять hardware-проектами: что должен уметь менеджер, когда ошибки стоят дорого

    Управление hardware-проектами редко похоже на классический IT-менеджмент. Здесь нельзя бесконечно двигать сроки, спокойно менять требования по ходу и рассчитывать, что ошибку получится быстро исправить в следующем релизе. В этой сфере слишком многое завязано на жесткие этапы, взаимозависимость команд и высокую цену любой поздней правки. Меня зовут Дарья Капустина, я — старший менеджер проектов в департаменте беспроводных технологий связи YADRO. В статье расскажу, как я пришла в управление hardware-проектами и чем такая работа отличается от привычного проджект-менеджмента в software.

    habr.com/ru/companies/yadro/ar

    #менеджмент_проектов #hardware #hardwareпродукт #управление_проектами #project_management #project_manager

  18. ИИ не разгружает сотрудников. Он просто повышает планку ожиданий

    Если вы используете GPT в работе, вы уже могли поймать странный эффект: задачи стали делаться быстрее, но свободнее не стало. Более того — иногда кажется, что стало тяжелее. Раньше ты писал отчёт два часа. Теперь собираешь его за двадцать минут. Но вместо того чтобы получить обратно эти полтора часа, ты начинаешь делать отчёт глубже: добавляешь аналитику, проверяешь гипотезы, готовишь несколько сценариев, аккуратнее формулируешь выводы. И в какой-то момент возникает неприятный вопрос: если ИИ действительно экономит мне время, почему я не чувствую себя менее загруженной?

    habr.com/ru/articles/1036784/

    #ИИ #оптимизация #менеджмент #менеджмент_проектов

  19. Subject Matter Expert. Чёрная Метка Для Разработчика

    Это не совсем привычная для меня статья, но я давно хотел поделиться одним своим наблюдением. В ней не будет никаких вещей, связанных непосредственно с разработкой на Java или Kotlin, не будет кода. Я просто решил поделиться опытом. Я надеюсь, читать эту статью Вы будете вечером, в спокойный, выходной день. Ну что же, поехали. Я предполагаю, что Spring АйО читают в основном Java или Kotlin разработчики. В том или ином виде, Java / Kotlin разработчики часто пишут какие-то Enterprise решения. Одной из отличительных особенностей enterprise является сложная доменная область. Если Вы хотя бы какое-то время писали Enterprise бекенд, то я думаю, для Вас это не новость.

    habr.com/ru/companies/spring_a

    #менеджмент #менеджмент_проектов #enterprise #java #разработка #backend #менеджмент_персонала

  20. Почему одному проекту иногда сложнее выжить, чем шести

    Это четвёртая часть серии. В первой я разбирал механику прокрастинации умных людей. Во второй — личную историю про интроверта-продавца, у которого в собственном деле отказала внешняя конструкция. В третьей — как я потратил полтора миллиона на команду без релизов, а потом начал собирать продукты сам с Cursor. Эта часть про странную вещь, которую я заметил на третьем месяце бота Founder Mode. Один проект может быть тяжелее, чем шесть. Это звучит неправильно. Почти все советы для фаундеров говорят обратное: выбери одну вещь, сфокусируйся, не распыляйся. В большинстве случаев это хороший совет. Особенно если человек бежит в новые проекты, чтобы не делать неприятное в старом. Но у меня случилось иначе. Когда проектов стало несколько, я не развалился. Наоборот, впервые за несколько лет у меня включился режим, в котором я умею работать. Я вспомнил, как это — быть менеджером проектов. Один проект Первые два месяца Founder Mode был устроен просто. Один главный проект. Один приоритет недели. Вечером — фиксация: было ли движение по главному или я занимался чем-то, что только выглядело как работа. Проектом был FoodTech. Не абстрактный "стартап", а конкретная заявка на грант, конкретный пакет документов, конкретные шаги. Два месяца маленького движения дали результат: заявка была подана. Для меня это было важно не из-за гранта. Важно было то, что впервые за долгое время собственный проект не растворился в бесконечной подготовке. До этого мой обычный цикл выглядел так: 1. Начать проект. 2. Много думать.

    habr.com/ru/articles/1031840/

    #солофаундер #фокус_vs_распыление #портфель_проектов #менеджмент_проектов #еженедельное_планирование #вечерняя_сверка #иллюзия_занятости #внутренний_критик #specdriven_разработка #Cursor

  21. Глава из книги «Не усложняй! Управление проектами по методу P3.express»

    В издательстве Бомбора впервые на русском языке вышла книга о методе управления проектами P3.express. Как один из авторов публикую главу из книги в открытом доступе.

    habr.com/ru/articles/1029608/

    #управление_проектами #управление_командой #менеджмент_проектов #p3express #книга

  22. Win-win или почему важно работать с подрядчиком как с партнером. Неочевидные плюсы и правила

    Цифровые продукты не развиваются в отрыве от среды. И пока проект находится в разработке, меняются приоритеты бизнеса, ситуация на рынке, а исполнитель продолжает работать по уже устаревшему ТЗ. В итоге проект сдан в срок, но результат не решает актуальные задачи бизнеса. Но возможен и другой подход к работе, когда подрядчик и заказчик действуют как партнёры. Он предполагает не только совместную работу над решениями, но и общую ответственность за лучший результат. В таком формате появляются договорённости и требования к обеим сторонам, но именно это позволяет двигаться к результату, а не просто закрывать список задач. В статье операционный директор CleverPumpkin Владислава Ларкина рассказывает, как компания выстраивает отношения со своими клиентами, чтобы знакомство переросло в долгосрочное партнёрство. И какие процессы помогают команде брать на себя больше ответственности, а бизнесу получать предсказуемый результат.

    habr.com/ru/companies/cleverpu

    #лояльность_клиентов #менеджмент_проектов #проектная_культура #аутсорсинг #проектная_команда #партнерские_отношения

  23. ПРОЕКТЫ В СПОРТЕ И БИЗНЕСЕ: ПЯТЬ УРОКОВ, О КОТОРЫХ ВАМ НЕ РАССКАЖУТ НА MBA

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

    habr.com/ru/articles/1028660/

    #спорт #бизнес #менеджмент_проектов #управление_проектами

  24. Мысли вслух: Как AI-агенты скукоживают процесс разработки

    Рассуждаем на тему того, что AI-агенты радикально скукожили привычный нам цикл разработки. ИИ-инфлюенсеры утверждают, что скрам больше не нужен, тестировщики не нужны, всё сделает агент. Реальность интереснее: этапы сжимаются по-разному в зависимости от контекста. В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.

    habr.com/ru/articles/1015004/

    #scrum #ai #cursor #sdlc #менеджмент #менеджмент_проектов #frontend #backend #devops

  25. Пошаговые хлопоты: термодинамический рабочий процесс

    В начале почти любого проекта приходится решать, как именно им управлять. Выбор сегодня огромен: от классического PMBOK до Kanban и гибких подходов. Но на практике этот выбор слишком часто определяется не логикой самого проекта, а личными предпочтениями, корпоративной инерцией или очередной управленческой модой. Проблема в том, что методика не бывает нейтральной. Она не просто помогает организовать работу, а накладывает на проект собственную рамку: выделяет одни аспекты, ослабляет другие, открывает одни возможности и закрывает другие. Ошибка в этом выборе может обойтись дороже, чем кажется, — особенно в тот момент, когда реальные очертания проекта ещё только проявляются. Практика термодинамической сегментации предлагает другой ход. Она позволяет не выбирать одну универсальную схему управления заранее, а обоснованно собирать архитектуру управления под конкретный проект — с учётом его структуры, состава команды и характера накопления неопределённости. 7 шагов управления проектом...

    habr.com/ru/articles/1016574/

    #управление_проектами #менеджмент_проектов #pmbok #agile #scrum #kanban #prince2 #организация_процессов

  26. CEO навайбкодил прототип. Почему после этого команда не обязана работать вдвое быстрее

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

    habr.com/ru/articles/1016360/

    #AI #менеджмент_проектов #менеджмент_в_it #ииагенты

  27. Когда фреймворки бессильны: четыре задачи без готовых ответов

    Привет, Хабр! В работе легко скатиться в автопилот: привычные подходы, проверенные аргументы и готовые решения. Вопрос в том, что делать, когда они перестают работать. В проекте

    habr.com/ru/companies/croc/art

    #управление_проектами #технический_менеджмент #искусственный_интеллект #решение_кейсов #soft_skills #развитие_бизнеса #кейсы #менеджмент_проектов #креатив #нестандартные_решения

  28. Попытка внедрить изменения снизу: мысленный эксперимент, который слишком похож на реальность

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

    habr.com/ru/articles/1012676/

    #менеджмент_проектов #разработка #разработка_электроники #управление_проектами #управление_проектами_и_командой

  29. Простые хлопоты: когда проекту действительно нужно управление

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

    habr.com/ru/articles/1012074/

    #управление_проектами #управление_рисками #agile #scrum #организация_работы #организация_процессов #менеджмент_проектов

Share on Mastodon

Enter the server where you have an account.