home.social

#управление_проектами_и_командой — Public Fediverse posts

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

fetched live
  1. Как управлять инвестиционным проектом: 8 шагов до результата

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

    habr.com/ru/companies/directum

    #управление_проектами #система_управления_проектами #методология #управление_проектами_и_командой #исуп #инвестиционные_проекты

  2. Рецензия на книгу «Изучаем системное мышление» — книга о том, как перестать лечить симптомы в ИТ-проектах

    Недавно в блоге издательства БХВ вышла статья , что в ИТ-литературе надо больше внимания уделять темам построения команд, управления людьми и разработкой продуктов (продакт‑ и тайм-менеджменту). На наш взгляд, это хорошее начинание, ведь книги по «чистому ИТ» очень быстро устаревают, а вот про ведение бизнес-процессов и личностный рост специалистов — тема почти вечная. Книга Дианы Монталион «Изучаем системное мышление» — перевод Learning Systems Thinking, вышедшей в O’Reilly, как раз в этой струе.

    habr.com/ru/companies/ssp-soft

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

  3. Депеши, карточки и паранойя: мой опыт скрещивания Waterfall и Agile в проекте для РЖД. Часть вторая

    Добро пожаловать обратно, друзья. Если вы читали первую часть , то знаете, как мы выстраивали периметр, прикрывали тылы и готовились к штурму. Теперь переходим к самому интересному – к продукту. К тому самому «цифровому космолету» , который должен был перевернуть рынок пассажирских перевозок. Но как это часто бывает в больших проектах, эпичный концепт столкнулся с не менее эпичной реальностью. Легаси-инфраструктура с которой мы столкнулись и на которой нам предстояло строить этот самый «космолет», в реале оказалась сложнее и неповоротливей, чем мы могли себе представить. Распределённая архитектура, множество стыковочных узлов, кривые сторонние сервисы, языковые и культурные барьеры внутри команд, а главное – жёсткие рамки Waterfall . Всё это требовало не просто инженерной смекалки, а умения балансировать между интересами разных игроков, не теряя фокуса на конечном пользователе. В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами , которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации. Если вы не читали первую часть – рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall . Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации - добро пожаловать прямо сюда. Читать мою историю можно в любом порядке. Приготовьтесь, отправляемся. Следующая станция – «прод».

    habr.com/ru/articles/1076876/

    #системная_архитектура #управление_проектами_и_командой #agile #waterfall #ржд #легаси #интеграция #проектирование_систем #enterprise #архитектура

  4. Что проще: спроектировать мост или внедрить таск-трекер? Делюсь личным опытом

    Мы успели проверить оба варианта и провести через таск-трекер 45 объектов. Рассказываю наши лайфхаки, как разложить сложный инженерный процесс по доскам, не утонуть в задачах и сделать систему, которой команда действительно будет пользоваться.

    habr.com/ru/companies/yougile/

    #управление_проектами #управление_командой #управление_продуктом #тасктрекер #планировщик_задач #система_управления_проектами #система_управления_задачами #канбандоска #строительство #управление_проектами_и_командой

  5. Эволюция подготовки производственных кадров: от советских разрядов к современным грейдовым системам

    Эта статья запланирована как часть цикла исследований о развитии систем подготовки кадров — от советской модели профессиональных разрядов до современных корпоративных грейдов.

    habr.com/ru/articles/1069882/

    #грейды #управление_проектами_и_командой #карьера_в_it #образование #производство #профессиональное_образование #управление_персоналом #машиностроение #промышленность #развитие_сотрудников

  6. Единые цели — разные бэклоги: практический подход к синхронизации команд

    Что делать, если: всю продуктовую разработку разместили в одном Jira-проекте, рассчитывая на «единообразие любой ценой»; у бэклога и процессов нет явного владельца; команды работают над крупным омниканальным продуктом со сквозными интеграциями и зависимостями; релизы взаимозависимы, классический Scrum не подходит, а переход на Waterfall никто не хочет даже обсуждать; методология приоритизации целей существует, но применяется только эпизодически; приоритеты обсуждаются раз в квартал, а затем команды самостоятельно ищут ресурсы для кросс-командных доработок. В статье я расскажу, что происходит, когда множество продуктовых и сервисных команд ведут бэклоги в одном Jira-проекте, и как выстроить сквозную приоритизацию с минимальными изменениями существующей системы.

    habr.com/ru/articles/1066454/

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

  7. AI против Agile: что изменилось за последние два года

    Почему Scrum не исчез, но многие привычные процессы уже никогда не будут прежними. Искусственный интеллект не отменил Agile, но заметно изменил привычные процессы внутри продуктовых команд. Многие задачи, которые еще недавно занимали часы, сегодня выполняются за минуты: подготовка к Scrum-встречам, написание User Stories, планирование спринта, ведение протоколов, анализ результатов и работа с документацией. В этой статье я расскажу, как AI трансформировал мою повседневную работу Product Manager, какие Agile-практики изменились сильнее всего и почему роль человека в команде стала не менее, а даже более важной. Статья основана на личном опыте использования AI в разработке цифровых продуктов и будет полезна Product Manager, Project Manager, Scrum Master и всем, кто работает в Agile-командах.

    habr.com/ru/articles/1065764/

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

  8. Чтение на выходные: «Теория каст и ролей» Алекса Крола

    Сегодня в рубрике — книга про скрытую механику человеческих групп. Что-то похожее написано в книге «Лидер и племя», где Дэвид Логан и его соавторы исследовали пять уровней племенной культуры — от «жизнь отстой» до «мы великие». Здесь — почти о том же, только через касты и роли. И сценарии — примеры жизненных траекторий, в которых можно увидеть себя: «успешный бизнесмен», «успешный творец», «активный предприниматель», «талантливый неудачник», «жалкий трудяга».

    habr.com/ru/companies/onlinepa

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

  9. Как SAFe помог нам сократить сроки реализации фич с полугода до двух месяцев

    Когда компания растет, а команд становится больше, синхронизация становится не просто полезной, а критически важной. В Directum мы привыкли регулярно пересматривать процессы и искать точки роста для оптимизации. Одной из таких оказался процесс управления задачами: фокус на стратегии размывался, загрузка распределялась неравномерно, а квартальное планирование часто превращалось в согласование конфликтов. Мы не стали мириться. И нашли способ, который позволил нам синхронизировать работу команд, сократить сроки реализации фич с полугода до двух месяцев и выровнять нагрузку без увеличения штата.

    habr.com/ru/companies/directum

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

  10. Чему Product Lead может научиться у князей Древней Руси: шесть уроков управления командами и системами

    Всем привет! Меня зовут Даша Белал. Я руководитель кластера «Планирования и управления товародвижением» в СМ Лаб. За годы работы руководителем я прошла десятки курсов по менеджменту, прочитала множество книг по управлению и лидерству, изучала разные подходы к организации команд и процессов. Но в какой‑то момент я поймала себя на мысли, что многие материалы начинают повторяться. Меняются примеры, появляются новые термины, но сами управленческие принципы остаются примерно одинаковыми. И в поисках вдохновения и новых знаний однажды я решила вместо очередной книги по управлению прочесть что‑то из российской истории — и с удивлением обнаружила: исторические сюжеты дают ценные уроки менеджмента. История Древней Руси оказалась не только рассказом о князьях, войнах и политике. За знакомыми со школы событиями скрывались вполне современные управленческие кейсы: адаптация нового руководителя, оценка рисков, масштабирование системы, работа с кризисами, развитие партнёрских отношений и построение устойчивых процессов. В этой статье я хочу поделиться шестью уроками управления, которые можно извлечь из истории Древней Руси и применять в работе с командами, продуктами и информационными системами уже сегодня. Урок первый. Адаптивность. Чему нас может научить Рюрик История Руси начинается с приглашения руководителя со стороны. Согласно летописи, славянские племена столкнулись с внутренними конфликтами и нестабильностью. Для решения проблемы было принято решение привлечь руководителя со стороны. Давайте представим как могло бы выглядеть на современном языке описание вакансии: «Требуется опытный лидер для запуска проекта „Русь“. Обязанности: выстроить систему управления, обеспечить безопасность периметра, наладить логистику и торговлю. Опыт в масштабировании сообществ обязателен».

    habr.com/ru/companies/sportmas

    #управление_проектами_и_командой #лидерство #кластерная_модель #история #организация_команд #smlab

  11. [Перевод] Как стать лучшим AI-Builder, или Топ худших ошибок с AI и как их преодолеть

    Все поинты ниже применяются при общении, промптинге и ежедневной работе с AI - и во многом они пересекаются с тем, как общаются люди между собой. «Нельзя ошибаться» → Ошибаться это нормально. Спрашивайте проанализировать и исправить их, создавайте культуру инструментов и регрессионного тестирования, чтобы отлавливать и разбирать ошибки (то есть занимайтесь развитием engineering stewardship). Угрозы / Неэтичная лексика → Относитесь к общению с AI так же, как к общению с любым человеком. Поощряйте сотрудничество, креативность, ответственность и чувство собственности (ownership). Делегируйте и …

    habr.com/ru/articles/1063720/

    #этика #этика_ии #aiагенты #работа_с_ии #внедрение_ии #управление_ии #управление_процессами #управление_командой #управление_проектами_и_командой

  12. Кладбище ИИ-стартапов 2023–2026: кто стал бизнесом, а кто был симптомом пузыря

    Привет, Хабр! Начнем с истории, которая идеально открывает тему. В мае 2025-го подала на банкротство Builder.ai — лондонский стартап с оценкой в 1,5 миллиарда долларов и деньгами от Microsoft, SoftBank, Insight Partners и суверенного фонда Катара. Продавала она ассистента «Наташу», который якобы собирал приложения по текстовому описанию, «как заказать пиццу». По лентам мгновенно разлетелась версия: никакого ИИ не было, всё писали 700 инженеров в Индии, притворяясь нейросетью.

    habr.com/ru/companies/mvideo/a

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

  13. Как мы в MONS управляли 300+ людьми на ЕГЭ через чаты — и почему решили сделать свой продукт

    ЕГЭ обычно сдают выпускники, но в мае 2025 его сдавали и мы, командой из 300+ человек, разбросанных по 177 школам Санкт-Петербурга, от центра до Кронштадта. Задача была одна — не дать упасть системе видеонаблюдения. Именно тогда мы поняли, что следующий подобный проект должен быть устроен иначе.

    habr.com/ru/companies/korus_co

    #информационная_система #егэ #управление_проектами #itпроекты #itпродукты #управление_командой #управление_проектами_и_командой #itкомпании

  14. 5 ошибок менеджера, внедряющего ИИ

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

    habr.com/ru/articles/1059980/

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

  15. Почему команды сопротивляются AI — и что с этим делать

    AI уже вошёл в работу IT- команд. Доступы выдали, обучение провели, демо показали, и как будто активность в инструментах растёт. А Lead Time (время от взятия обязательств до прода), Throughput (сколько работы команда делает) меняются гораздо медленнее. Иногда не меняются вообще. Сопротивление AI в такой ситуации полезно читать как диагностику системы. Оно показывает место, где команда ещё не договорилась: про цель, инструмент, ответственность, безопасность или поток работы.

    habr.com/ru/articles/1059726/

    #AI #agentic_engineering #рабочие_договоренности #управление_командой #изменения #управление_проектами_и_командой #sdlc #aiразработка #aiинструменты

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

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

    habr.com/ru/articles/1057962/

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

  17. Депеши, карточки и паранойя: мой опыт скрещивания Waterfall и Agile в проекте для РЖД. Часть первая

    Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы. Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы. Этот материал – не стандартный кейс формата «мы запилили продукт, хвала нам». Это двухтомный производственный триллер о том, как построить цифровой космолет внутри панциря Левиафана. Как обеспечить безопасность команды, выстроить железобетонную стену по периметру и не поехать при этом «кукухой». Когда ты помещаешь живую инновацию в жернова госкорпорации, ты либо становишься жертвой системы, либо учишься управлять гравитацией. Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов , которые спасали наши задницы от бесконечных правок. Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами . Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

    habr.com/ru/articles/1057106/

    #системная_архитектура #управление_проектами_и_командой #agile #waterfall #ржд #легаси #интеграция #проектирование_по #enterprise #архитектура

  18. Закон Брукса: почему нанять ещё людей — худшее решение, когда проект горит

    В 1975 году Фредерик Брукс выпустил книгу «Мифический человеко-месяц». Она появилась не потому, что он решил написать очередной учебник по менеджменту. До этого Брукс руководил разработкой операционной системы OS/360 в IBM - одного из самых масштабных программных проектов своего времени. Когда всё закончилось, ему было что рассказать. Главная мысль книги звучала странно. Если проект начинает отставать от графика, добавление новых людей не ускорит его. Скорее наоборот - задержит ещё сильнее. Прошло больше пятидесяти лет, а эту идею до сих пор называют законом Брукса.

    habr.com/ru/articles/1055366/

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

  19. MBA на минималках «Инструмент улучшения кросс функционального взаимодействие в команде»

    Могу точно сказать, что почти весь бизнес теряет до 50% своей эффективности из-за того, что разные отделы/департамента тупо не могут найти общий язык, а часто и откровенно враждуют друг с другом. Вот мой топ 3 отделов/департаментов, которые не любят особенно актуально:

    habr.com/ru/articles/1054898/

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

  20. Что общего между Technical Project Manager и многодетной мамой?

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

    habr.com/ru/companies/svoi_ru/

    #project_management #pm #семья #управление_командой #управление_проектами_и_командой #agile #pmbok #life_management #дети #финтех

  21. Старикам тут не место

    IT — дело молодых? Десять лет назад я в это свято верил и готовился почистить штат от сотрудников, которым шёл пятый, а то и восьмой десяток. То, что случилось вместо увольнений, изменило моё отношение к возрасту в профессии — и сегодня, в эпоху нейросетей, звучит особенно остро.

    habr.com/ru/articles/1051888/

    #тимлид #управление_персоналом #управление_проектами_и_командой #карьера_в_it #возраст_в_ит #наставничество #мотивация_сотрудников #legacyсистемы #переобучение

  22. МВА на минималках «Модель Айсберг для определения типа сотрудников в команде»

    Есть много типологий сотрудников, но мне очень нравится модель Айсберг, потому что в ней только два критерия и главное она помогает понять руководителю не только как работает сотрудник, но и увидеть свои ошибки в управлении. Итак, модель Айсберг включает два критерия: 1. сколько обещает сотрудник сделать; 2. сколько реально сотрудник делает. и по соотношению этих двух показателей можно легко определить, кто есть кто в вашей команде и что необходимо изменить вам как руководителю в своей деятельности. 1.тип сотрудника. "Много обещает/Мало делает." Деструктивный тип личности. Red flag. Что делаем с таким сотрудником: Выясняем почему нет результата, даём возможность исправить модель поведения. Если ничего не меняется - увольняем. Обычно команда бывает очень рада избавиться от такого коллеги, так как они за него/неё всё делали. 2.тип сотрудника "Сколько обещает/столько и делает" Адекватный человек. Тут может быть вопрос в мотивации сотрудника. Что делаем с таким сотрудником: Выясняем всё ли его устраивает в работе, хотел бы он делать что-то иное, изменить уровень задач и или свою позицию в команде. Если говорит, что всё ок, то не трогаем. Если хочет большего развития, предлагаем варианты какие могут быть в команде для него. 3.тип сотрудника "Мало обещает/много делает" Это золотой фонд команды, талантливый сотрудник. Но это может быть звоночек для руководителя, почему сотрудник не сообщает о своей деятельности, может он предлагал варианты улучшения, но его не слушали и он решил, что проще ничего не говорить, а просто делать.

    habr.com/ru/articles/1051428/

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

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

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

    habr.com/ru/articles/1042844/

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

  24. Continuous Architecture в финтехе. Наш опыт

    Меня зовут Пелых Виталий, я корпоративный архитектор в «БКС Финтех». Разберу тему, которая звучит просто, но в крупных организациях регулярно «выстреливает» в неожиданных местах: как позиционировать архитектуру так, чтобы она помогала бизнесу и командам, а не превращалась в формальность или «бутылочное горлышко». Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery. Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.

    habr.com/ru/companies/bcs_comp

    #корпоративная_архитектура #финтех #гибкость #управление_проектами_и_командой

  25. Почему роль Delivery Manager не работает в большинстве компаний

    Всем привет, меня зовут Алина, я работала в роли Delivery Manager и прожила ее изнутри, поэтому хорошо понимаю, почему в большинстве компаний роль есть, а эффекта от роли нет. Сейчас объясню. Для меня Delivery Manager отвечает не за отдельную задачу или проект, а за устойчивость delivery в целом: условно, за конвейер, через который любой проект или фича проходят предсказуемо. В первую очередь это роль, которая работает на уровне системы: — видит зависимости между командами и в команде, — понимает технические ограничения, — управляет рисками и загрузкой команд, — влияет на решения, которые сказываются на сроке и качестве. Он не пишет код, но влияет на условия, в которых работает вся система разработки. Но это в теории. А в реальности чаще всего есть некая «бумага», на которой прописано, что существует роль, отвечающая за delivery. При этом зона ответственности размыта, особенно там, где есть пересечение ролей Team Lead, SM, PO,PM, метрик нет, а влияние на результат ограничено. Потому и эффекта нет, зато есть срывы сроков и перегруженные команды, а эскалации не снижаются.

    habr.com/ru/companies/alfa/art

    #delivery_manager #itmanagement #управление_проектами_и_командой #agile #engineering_management #управление_процессами_в_it #delivery #sdlc #разработка_по

  26. Clean Agile: что стоит знать об Agile каждому руководителю проекта

    Многие знают Agile по ежедневным стендапам, спринтам и доскам в Jira. Но мало кто задумывается, почему Agile вообще появился. Если вам интересен ответ на этот вопрос, очень рекомендую книгу Роберта Мартина «Clean Agile. Back to Basics». Для меня это одна из лучших книг об Agile, которую стоит прочитать каждому Project Manager. Для многих специалистов в IT имя автора не нуждается в представлении. Именно Роберт Мартин, известный также как Uncle Bob, был одним из авторов Agile Manifesto, опубликованного в 2001 году и навсегда изменившего подход к разработке программного обеспечения. Книга получилась интересной не только для разработчиков, но и для руководителей проектов. Это не очередной учебник по Scrum или набор модных практик. Скорее, это попытка вернуться к истокам Agile и объяснить, зачем он вообще появился. Мартин начинает с простой мысли: современный мир полностью зависит от программного обеспечения. Софт управляет практически всеми аспектами нашей жизни. Программное обеспечение стало кровеносной системой современной цивилизации. Без него привычный нам мир просто не смог бы существовать. Поэтому неудивительно, что люди, создающие программное обеспечение, постоянно ищут способы делать это быстрее, качественнее и эффективнее. Большая часть книги посвящена истории возникновения Agile. Автор подробно рассказывает, какие проблемы существовали в индустрии до появления Agile-подходов и почему традиционные методы управления проектами перестали справляться с задачами быстро меняющегося мира разработки.

    habr.com/ru/articles/1041590/

    #управление_проектами #управление_командой #управление_проектами_и_командой #управление_проектом #управление_продуктом #agile #project_management #project_manager #product_management #product_development

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

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

    habr.com/ru/companies/yougile/

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

  28. [Перевод] Эрик Рис, автор Lean Startup: Почему хорошие компании становятся плохими после IPO

    Эрик Рис написал книгу Lean Startup пятнадцать лет назад — она стала библией для поколения основателей и ее до сих пор можно найти на столе у большинства продуктовых менеджеров. "Lean Startup" учил строить успешную компанию. Новая книга Эрика "Incorruptible \\ Неподкупные: Почему хорошие компании становятся плохими и как великие компании остаются великими" учит защищать то, что вы построили.

    habr.com/ru/articles/1038758/

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

Share on Mastodon

Enter the server where you have an account.