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

Рекомендации для руководителей IT-проектов: как не попасть в ад и выйти сухим из воды

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось , и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?». Панацеи тут нет. Но давайте разберемся. В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :) Это все, конечно, шутки. Но на деле есть те, кто тушит пожары с утра до ночи, и те, кто делает так, чтобы пожары просто не возникали. Вторых меньше, но именно они спят спокойно, не вздрагивая от каждого уведомления. Я побывала в обеих ипостасях. В этой статье собрала выжимку из граблей, на которые я наступала, и перил, за которые успевала схватиться. 1. Начинайте с конца Звучит странно, но работает безотказно. Прежде чем писать первую строчку кода или рисовать первый экран в Figma, важно ответить себе на вопрос: «Как мы поймём, что проект успешно завершён?». Не в общих чертах («заказчик доволен»), а конкретно: — Какую проблему мы решаем? — Какие метрики должны быть достигнуты? — Какие критерии приёмки у каждого этапа? — Что будет считаться провалом? Когда вы чётко знаете точку, к которой хотите прийти, к ней гораздо легче прокладывать маршрут. Если чёткой конечной точки нет, то это забег без финиша. 2. Требования — это святое Самая частая причина провалов — размытые, меняющиеся или отсутствующие требования. Заказчик говорит: «Ну вы же профессионалы, сами придумайте». Команда придумывает. Заказчик отвечает: «Я не это имел в виду».

https://habr.com/ru/companies/rgs_it/articles/1023340/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #требования_к_проекту #управление_командой

Рекомендации для руководителей IT-проектов: как не попасть в ад и выйти сухим из воды

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось , и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?». Панацеи тут нет. Но давайте разберемся. В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :) Это все, конечно, шутки. Но на деле есть те, кто тушит пожары с утра до ночи, и те, кто делает так, чтобы пожары просто не возникали. Вторых меньше, но именно они спят спокойно, не вздрагивая от каждого уведомления. Я побывала в обеих ипостасях. В этой статье собрала выжимку из граблей, на которые я наступала, и перил, за которые успевала схватиться. 1. Начинайте с конца Звучит странно, но работает безотказно. Прежде чем писать первую строчку кода или рисовать первый экран в Figma, важно ответить себе на вопрос: «Как мы поймём, что проект успешно завершён?». Не в общих чертах («заказчик доволен»), а конкретно: — Какую проблему мы решаем? — Какие метрики должны быть достигнуты? — Какие критерии приёмки у каждого этапа? — Что будет считаться провалом? Когда вы чётко знаете точку, к которой хотите прийти, к ней гораздо легче прокладывать маршрут. Если чёткой конечной точки нет, то это забег без финиша. 2. Требования — это святое Самая частая причина провалов — размытые, меняющиеся или отсутствующие требования. Заказчик говорит: «Ну вы же профессионалы, сами придумайте». Команда придумывает. Заказчик отвечает: «Я не это имел в виду».

https://habr.com/ru/companies/rgs_it/articles/1023340/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #требования_к_проекту #управление_командой

Рекомендации для руководителей IT-проектов: как не попасть в ад и выйти сухим из воды

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось , и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?». Панацеи тут нет. Но давайте разберемся. В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :) Это все, конечно, шутки. Но на деле есть те, кто тушит пожары с утра до ночи, и те, кто делает так, чтобы пожары просто не возникали. Вторых меньше, но именно они спят спокойно, не вздрагивая от каждого уведомления. Я побывала в обеих ипостасях. В этой статье собрала выжимку из граблей, на которые я наступала, и перил, за которые успевала схватиться. 1. Начинайте с конца Звучит странно, но работает безотказно. Прежде чем писать первую строчку кода или рисовать первый экран в Figma, важно ответить себе на вопрос: «Как мы поймём, что проект успешно завершён?». Не в общих чертах («заказчик доволен»), а конкретно: — Какую проблему мы решаем? — Какие метрики должны быть достигнуты? — Какие критерии приёмки у каждого этапа? — Что будет считаться провалом? Когда вы чётко знаете точку, к которой хотите прийти, к ней гораздо легче прокладывать маршрут. Если чёткой конечной точки нет, то это забег без финиша. 2. Требования — это святое Самая частая причина провалов — размытые, меняющиеся или отсутствующие требования. Заказчик говорит: «Ну вы же профессионалы, сами придумайте». Команда придумывает. Заказчик отвечает: «Я не это имел в виду».

https://habr.com/ru/companies/rgs_it/articles/1023340/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #требования_к_проекту #управление_командой

Рекомендации для руководителей IT-проектов: как не попасть в ад и выйти сухим из воды

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось , и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?». Панацеи тут нет. Но давайте разберемся. В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :) Это все, конечно, шутки. Но на деле есть те, кто тушит пожары с утра до ночи, и те, кто делает так, чтобы пожары просто не возникали. Вторых меньше, но именно они спят спокойно, не вздрагивая от каждого уведомления. Я побывала в обеих ипостасях. В этой статье собрала выжимку из граблей, на которые я наступала, и перил, за которые успевала схватиться. 1. Начинайте с конца Звучит странно, но работает безотказно. Прежде чем писать первую строчку кода или рисовать первый экран в Figma, важно ответить себе на вопрос: «Как мы поймём, что проект успешно завершён?». Не в общих чертах («заказчик доволен»), а конкретно: — Какую проблему мы решаем? — Какие метрики должны быть достигнуты? — Какие критерии приёмки у каждого этапа? — Что будет считаться провалом? Когда вы чётко знаете точку, к которой хотите прийти, к ней гораздо легче прокладывать маршрут. Если чёткой конечной точки нет, то это забег без финиша. 2. Требования — это святое Самая частая причина провалов — размытые, меняющиеся или отсутствующие требования. Заказчик говорит: «Ну вы же профессионалы, сами придумайте». Команда придумывает. Заказчик отвечает: «Я не это имел в виду».

https://habr.com/ru/companies/rgs_it/articles/1023340/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #требования_к_проекту #управление_командой

Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось

Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов. Живой пример Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную , и занимался этим не один-два человека, а аж целый отдел . Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

https://habr.com/ru/companies/rgs_it/articles/1005566/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #причины_провала_проекта #требования_к_проекту

Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось

Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов. Живой пример Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную , и занимался этим не один-два человека, а аж целый отдел . Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

https://habr.com/ru/companies/rgs_it/articles/1005566/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #причины_провала_проекта #требования_к_проекту

Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось

Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов. Живой пример Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную , и занимался этим не один-два человека, а аж целый отдел . Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

https://habr.com/ru/companies/rgs_it/articles/1005566/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #причины_провала_проекта #требования_к_проекту

Как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось

Есть проекты, которые с первого дня пахнут успехом. А есть те, от которых веет таким могильным холодом, что хочется завернуться в плед, удалить мессенджеры и переехать в деревню без интернета. Проблема в том, что часто мы слишком поздно замечаем запах горелого кода и безнадёжных дедлайнов. Живой пример Однажды мне в руки «по наследству» от предыдущего руководителя достался проект по автоматизации взаимодействия с подрядчиками. Задача важная: подрядчиков более 50, привлекаемых сотрудников — несколько тысяч, за всеми нужен учёт и контроль, который на тот момент осуществлялся полностью вручную , и занимался этим не один-два человека, а аж целый отдел . Неудивительно, что внутренний аудит это не устраивало, и нам было велено «срочно все автоматизировать». Генеральный директор поставил свою визу и отметил в календаре дату, когда ему нужен результат — через год.

https://habr.com/ru/companies/rgs_it/articles/1005566/

#итпроект #itпроект #управление_проектами #проектный_менеджмент #руководитель_проекта #провал_проекта #причины_провала_проекта #требования_к_проекту

Только эта система управления проектами спасает бизнес во время кризиса

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

https://habr.com/ru/articles/1004048/

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

Как я за месяц вошла в IT без технического образования: разбор шагов, ошибок и стратегии

Когда я рассказываю знакомым, что перешла в IT без технического образования за короткий срок, реакция обычно одна: «Как ты это сделала?» Ответ не в магии, не в чуде, не в удаче. А в том, как я перестроила своё мышление и перестала действовать по инерции. 10 лет я работала переводчиком и преподавателем английского. Это были годы практики, навыков коммуникации и управления группами людей, выступлений на отраслевых конференциях. Я даже делала свои образовательные продукты. Оказавшись перед выбором, я поняла - то, что у меня есть сейчас, перестаёт меня устраивать. Хочется задач, которые заставляют думать, которые масштабнее, которые приносят не только деньги, но и чувство движения вперёд. Да и сфера переводов сейчас, к сожалению, перестала быть перспективной ввиду геополитических причин и развития ИИ. Сразу скажу: я не пришла в IT как новичок наугад. Я начала с вопросов, и первый из них был простой: какая именно роль может подойти мне, учитывая мои сильные стороны? Я не хотела быть программистом или тестировщиком - это совсем не для меня. Зато я могла опираться на то, что умею: слушать людей, формулировать мысли, чувствовать контекст проектов, управлять задачами. Так я вышла на роли проджект-менеджмента, продакт-менеджмента и бизнес-анализа.

https://habr.com/ru/articles/1003494/

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

Как я за месяц вошла в IT без технического образования: разбор шагов, ошибок и стратегии

Когда я рассказываю знакомым, что перешла в IT без технического образования за короткий срок, реакция обычно одна: «Как ты это сделала?» Ответ не в магии, не в чуде, не в удаче. А в том, как я перестроила своё мышление и перестала действовать по инерции. 10 лет я работала переводчиком и преподавателем английского. Это были годы практики, навыков коммуникации и управления группами людей, выступлений на отраслевых конференциях. Я даже делала свои образовательные продукты. Оказавшись перед выбором, я поняла - то, что у меня есть сейчас, перестаёт меня устраивать. Хочется задач, которые заставляют думать, которые масштабнее, которые приносят не только деньги, но и чувство движения вперёд. Да и сфера переводов сейчас, к сожалению, перестала быть перспективной ввиду геополитических причин и развития ИИ. Сразу скажу: я не пришла в IT как новичок наугад. Я начала с вопросов, и первый из них был простой: какая именно роль может подойти мне, учитывая мои сильные стороны? Я не хотела быть программистом или тестировщиком - это совсем не для меня. Зато я могла опираться на то, что умею: слушать людей, формулировать мысли, чувствовать контекст проектов, управлять задачами. Так я вышла на роли проджект-менеджмента, продакт-менеджмента и бизнес-анализа.

https://habr.com/ru/articles/1003494/

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

Как я за месяц вошла в IT без технического образования: разбор шагов, ошибок и стратегии

Когда я рассказываю знакомым, что перешла в IT без технического образования за короткий срок, реакция обычно одна: «Как ты это сделала?» Ответ не в магии, не в чуде, не в удаче. А в том, как я перестроила своё мышление и перестала действовать по инерции. 10 лет я работала переводчиком и преподавателем английского. Это были годы практики, навыков коммуникации и управления группами людей, выступлений на отраслевых конференциях. Я даже делала свои образовательные продукты. Оказавшись перед выбором, я поняла - то, что у меня есть сейчас, перестаёт меня устраивать. Хочется задач, которые заставляют думать, которые масштабнее, которые приносят не только деньги, но и чувство движения вперёд. Да и сфера переводов сейчас, к сожалению, перестала быть перспективной ввиду геополитических причин и развития ИИ. Сразу скажу: я не пришла в IT как новичок наугад. Я начала с вопросов, и первый из них был простой: какая именно роль может подойти мне, учитывая мои сильные стороны? Я не хотела быть программистом или тестировщиком - это совсем не для меня. Зато я могла опираться на то, что умею: слушать людей, формулировать мысли, чувствовать контекст проектов, управлять задачами. Так я вышла на роли проджект-менеджмента, продакт-менеджмента и бизнес-анализа.

https://habr.com/ru/articles/1003494/

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

Как я за месяц вошла в IT без технического образования: разбор шагов, ошибок и стратегии

Когда я рассказываю знакомым, что перешла в IT без технического образования за короткий срок, реакция обычно одна: «Как ты это сделала?» Ответ не в магии, не в чуде, не в удаче. А в том, как я перестроила своё мышление и перестала действовать по инерции. 10 лет я работала переводчиком и преподавателем английского. Это были годы практики, навыков коммуникации и управления группами людей, выступлений на отраслевых конференциях. Я даже делала свои образовательные продукты. Оказавшись перед выбором, я поняла - то, что у меня есть сейчас, перестаёт меня устраивать. Хочется задач, которые заставляют думать, которые масштабнее, которые приносят не только деньги, но и чувство движения вперёд. Да и сфера переводов сейчас, к сожалению, перестала быть перспективной ввиду геополитических причин и развития ИИ. Сразу скажу: я не пришла в IT как новичок наугад. Я начала с вопросов, и первый из них был простой: какая именно роль может подойти мне, учитывая мои сильные стороны? Я не хотела быть программистом или тестировщиком - это совсем не для меня. Зато я могла опираться на то, что умею: слушать людей, формулировать мысли, чувствовать контекст проектов, управлять задачами. Так я вышла на роли проджект-менеджмента, продакт-менеджмента и бизнес-анализа.

https://habr.com/ru/articles/1003494/

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

Почему процессы в продуктовой IT-команде не работают

В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах». Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:

https://habr.com/ru/articles/991958/

#проектный_менеджмент #продуктовый_менеджмент #itкомпании #процессы_управления #процессы_разработки #процессы_в_it #процессы_команд #процессы_в_командах #pmbok

Зачем вам PMBoK, когда есть эта статья?

PMBoK весит 400 страниц и стоит как ползарплаты джуна. Я сейчас расскажу всё то же самое за 10 минут. Без воды, без "процессов интеграционного управления" и без желания покончить с собой на странице 237.

https://habr.com/ru/articles/969040/

#проектный_менеджмент #pmbok #управление_проектами #PMP #pmi

Зашкаливающая бюрократия на стыке проектов двух крупных банков — мой опыт

Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки. Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример ) На этом проекте: На этом проекте: — Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать. — Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас. — Уволился ключевой подписант. — Это был ИТ-директор! Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы. Как я уже говорила, это ад. Но бюрократия всё же нужна. Потому что на больших проектах она означает стандартизацию. Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили. В нашей истории западные модели ушли под санкции, и надо было быстро переключиться на российскую. Времени было, как обычно, до вчера.

https://habr.com/ru/companies/centicore_group/articles/968286/

#бюрократия #банки #llm #интеграция #договоры #проектный_менеджмент #комплаенс #ДКБ #sap

Инструменты для проектного офиса, которые действительно работают

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

https://habr.com/ru/companies/teamly/articles/963190/

#проектный_офис #проектный_менеджмент #проектный_подход #teamly #база_знаний #курсы

Инструменты для проектного офиса, которые действительно работают

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

https://habr.com/ru/companies/teamly/articles/963190/

#проектный_офис #проектный_менеджмент #проектный_подход #teamly #база_знаний #курсы

Инструменты для проектного офиса, которые действительно работают

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

https://habr.com/ru/companies/teamly/articles/963190/

#проектный_офис #проектный_менеджмент #проектный_подход #teamly #база_знаний #курсы

Инструменты для проектного офиса, которые действительно работают

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

https://habr.com/ru/companies/teamly/articles/963190/

#проектный_офис #проектный_менеджмент #проектный_подход #teamly #база_знаний #курсы

Что должен знать менеджер о Web-разработке, чтобы проект состоялся

Привет, я Рома, во время поиска работы я часто сталкивался в вакансиях project и product менеджеров с требованиями «технического бэкграунда» или чего‑то более конкретного, например, составления API запросов. Из своего опыта я слабо понимал откуда берутся данные требования, но запросы в Postman направлять научился. В недавней беседе с коллегой снова поднялся вопрос — нужно ли менеджеру вообще уметь работать с кодом, и вот, я решил копнуть глубже: изучить что хотят работодатели, что реально используют менеджеры и что ценят разработчики. В этой статье поделюсь наблюдениями, опросами и своими выводами. Надеюсь, материал будет интересен не только мне, но и тем, кто занят на стыке управления и технологий.

https://habr.com/ru/articles/954800/

#знания_менеджера #webразработка #навыки_менеджера #проектный_менеджмент

Дисциплина и желание учиться: по каким критериям проджекту в финтехе оценивать разработчиков-джунов

Привет, Хабр! Меня зовут Оля, я ведущий проектный менеджер в ЮMoney. Курирую несколько команд, в которых трудятся разные разработчики, в том числе джуны. В этой статье расскажу, как я выращиваю новичков в своей команде, какие навыки советую им развивать. Про подбор новых проектных менеджеров в отдел тоже поговорим.

https://habr.com/ru/companies/yoomoney/articles/943644/

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

Как сдать на РМР в 2025 году, если ты из России

Привет, Хабр! Я Катя Павлова, работаю в «Петрович-Тех». Последние 8 лет я пытаюсь управлять проектами, а 30 апреля 2025 года получила сертификат РМР. В этой статье поделюсь опытом, как можно сдать на РМР в 2025 году, не продавая душу дьяволу. Ну, почти.

https://habr.com/ru/companies/petrovich-tech/articles/933108/

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

Управление изменениями в проекте с помощью service desk

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

https://habr.com/ru/articles/930628/

#проектный_менеджмент #управление_проектами #servicedesk #jira #itil

Context. Гибридный метод организации проектов и рабочих процессов

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning , включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

https://habr.com/ru/articles/928396/

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

Context. Гибридный метод организации проектов и рабочих процессов

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning , включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

https://habr.com/ru/articles/928396/

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

Context. Гибридный метод организации проектов и рабочих процессов

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning , включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

https://habr.com/ru/articles/928396/

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

Context. Гибридный метод организации проектов и рабочих процессов

Мир меняется. Мы чувствуем тенденции на себе. Больше информации, больше логики, больше конкуренции, больше комплексности, больше правил, больше автоматизации, больше контекста, больше скорости… У нас был опыт работы с Lean, Kanban, CPM/CCM, Waterfall, PMBOK, Six Sigma, Scrum, Agile, OKR+Product Discovery, GIST Planning , включая их вариации и гибриды. Некоторые – мы ценим и применяем сейчас. И тем не менее, спустя 15 лет в проектном и операционном менеджменте мы по себе знаем о чем все также плачут проджекты, продакты и управленцы. О большей точности, координации, информации, взаимодействии и сроках. Нам понадобилось время по-новому осознать казалось бы простую идею, о которой чуть ниже. Проекты, как и компании в целом – это ресурсы направленные на достижение целей. Время, люди, информация – ресурсы, но сами по себе они не равны достижению целей. Ценность ресурсов – в их связях и взаимодействии. Связь и взаимодействие ресурсов – краеугольный камень в достижении целей. Это и есть идея Cоntext.

https://habr.com/ru/articles/928396/

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

Time&Materials вместо работы в минус: наш путь, шаблоны, цифры — и как сделать также у себя

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

https://habr.com/ru/articles/925266/

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

Как выбрать AI-курс для менеджера: подробный разнос

Обзор без маркетинга, с фокусом на то, что реально нужно менеджеру: практика, широта тем, прикладные знания, релевантность, отсутствие воды и инфоцыганщины. Как-то раз уже делался обзор по всем существующим на рынке курсам по управлению проектами https://vc.ru/hr/218092-top-90-kursov-po-upravleniyu-proektami , пришло время почихвостить рынок с новой, актуальной темой.

https://habr.com/ru/articles/922306/

#генеративный_ии #chatgpt #промптинжиниринг #rag #mcp #n8n #проектный_менеджмент #курсы #claude #ai

Сертификация для проджектов PMP за 4 месяца: как я сдавал, фейлил и снова сдавал

Привет, Хабр! Меня зовут Рома Ковалевский, я program-менеджер из Берлина с 10+ годами опыта. И я потратил 4 месяца, $1340 и кучу нервов, чтобы сдать PMP. По плану должно было быть быстрее и дешевле, но зато теперь могу поделиться этим опытом с тобой, дорогой читатель. В этой статье — честный рассказ, как я шёл к PMP, где споткнулся, сколько стоило, что сработало, а что нет. Чтобы вы могли пройти этот путь без лишних граблей (или хотя бы с запасной каской). Веду собственный телеграм-канал про управление проектам «Менеджер от боженьки» . Там — больше полезных постов и инсайтов о карьере проектного менеджера.

https://habr.com/ru/articles/910702/

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

Ошибки, которые нас учат: как мы делились неудачами и извлекали уроки

Каждый день мы читаем success stories, слышим от коллег и знакомых об их феноменальных успехах, смотрим на их фантастические достижения по проектам. Да мы и сами в одно время вели своеобразный реестр побед команды и хвалились успехами на коммселлах (это одна из регулярных церемоний из Lean-технологий для формирования культуры непрерывного совершенствования команды). И как-то так получилось, что в обществе сформировалось негласное табу на разговоры о неудачах. Безусловно, делиться успехами полезно, но жизнь многогранна и состоит не только из удачных моментов, но и из неудачных тоже. И вот однажды я узнал про мероприятие под названием Fuckup Nights: о нем в статье и пойдет речь.

https://habr.com/ru/companies/icl_group/articles/866042/

#факапы #факап #кейсы #проектный_менеджмент #офисы_itкомпаний

Базовые принципы GTD для начинающего

Привет, меня зовут Юля и я руководитель отдела тестирования. Взаимодействуя по работе с людьми часто вижу, что грамотные в техническом плане специалисты не всегда справляются с непрерывным потоком прилетающих им задач. Когда-то мы с коллегой даже подготовили для нашего отдела небольшую презентацию, посвященную основам тайм-менеджмента. На мой взгляд, не в выборе конкретной методики суть. О различных подходах говорят много. Но если сильно погружаться в детали на начальном этапе, никакая методика так и не приживется. Чтобы подход заработал, как правило, удобно сделать собственную интерпретацию общих правил, направленную на особенности и специфику своей работы. Также важно понимать, что потребуется потратить время на адаптацию к новой активности и к регулярному её применению. Этой статьей я попытаюсь немного снизить порог входа в одну из самых полезных (для меня) методик - Getting Things Done. Предложу свою вариацию, которую легко начать применять уже сегодня. Без дополнительных пояснений система будет понятна только тому, кто ее использует. Но зато позволит быстро разгрузить голову, не вникая в детали, изложенные в довольно объемной книге Дэвида Аллена.

https://habr.com/ru/articles/841948/

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

Рассказываю про SDLC для менеджеров проекта и нетехнических специалистов

Дорогие читатели, я видела, что на Хабр уже есть статья посвященная SDLC (и не одна), однако, этой статьей я хочу привлечь внимание ИТ-менеджеров, ничего об этом не знающих или знающих поверхностно. Напишу немного по-своему, так как я объясняла джунам, админам проекта и нетехническим специалистам, работающим непосредственно с разработкой программных продуктов. Было, что и на весь проектный офис рассказывала… Да, такое встречается и нередко, что менеджер проекта, именно посвященного разработке ПО, не знает, что такое цикл разработки программного продукта (=SDLC) , не понимает, зачем это знать, как с этим работать и к чему применять. К сожалению, это не только Джуны, мне встречались менеджеры уровнем и повыше, которые работают в командах разработки и не понимают их процессов. « Зачем, от этого же ничего не зависит » – говорили мне они…да ещё как зависит вообще-то. Без этого понимания вы делаете то, не знаю что и команду ведете туда, не знаю куда. Просто вот 1 случай: мой коллега, находимся на одинаковых позициях, взял и запланировал значит проект вот так: аналитика-тестирование-разработка-выкатка в прод . Никого ничего не смущает?) Это не какой-то там мем, это случай из жизни. Ну, что получилось? Тестировщик пришел, а тестировать нечего…ведь даже ничего ещё не разработано, протестировал бизнес-требования и ТЗ и был таков, а в прод выкатили поставку с критическими ошибками, все встало. Был конфузец. В моем понимании, это знание относится к категории базовых . Вот у каждой профессии есть своя база. Большая проблема, что считается, что спокойно можно зайти без этой базы в проектный менеджмент и вести свои проекты. Но, незнание базы, элементарных основных вещей, взаимосвязей, схем работы, методов и методологий, приводит вот к таким смешным ошибкам. В данной статье я расскажу о стадиях SDLC, как это применять в жизни и как можно улучшить свою работу с помощью данного инструмента.

https://habr.com/ru/articles/816561/

#sdlc #жизненный_цикл #разработка_по #pm #кейс #мнение #методологии #джуниор #jira #проектный_менеджмент

Идеальный установочный проектный митинг

Предисловие Цикл рассказов «Господин Старший Консультант» я начал публиковать давно, и ранее это могли прочитать только друзья и коллеги. Это совершенно новый рассказ, третий из опубликованных на Хабре. В отличие от предыдущих, в этот раз он скорее злой, чем смешной. Пролог. Утомленный очередным бессмысленным проектным митингом, Господин Старший Консультант задумчиво смотрел в окно на дождь, у которого не было начала и конца, и размышлял, каким мог бы быть установочный проектный митинг, если бы все участники были честны перед собой, коллегами, заказчиком, и выполняли те нехитрые правила, что существуют для каждого проекта (и более того, описаны в контрактах). Установочный митинг Очень Важного Проекта (ОВП) для Очень Важного Заказчика (ОВЗ) Смеркалось. В переговорной комнате вольготно расположилась проектная команда, чудом собранная ресурсным менеджером из остатков того, что когда-то было элитой инфраструктурного проектирования. Оптимизм давно покинул эти стены, лица хмуры, свет тускл, джинсы протерты и давно не стираны. Зарплаты давно не повышались. Продавец: - Коллеги, у меня пренеприятное известие, мы таки продали в ОВЗ что-то, в чем я сам ни черта не разбираюсь. Контракт склеен из трех других контрактов, местами к несчастью, даже не стерли названия предыдущих заказчиков. Про наполнение контракта я вообще предпочел бы промолчать, так как, склеивая старые документы я особенно не вчитывался. Продали мы это дешево, потому как такое гуано невозможно продать дорого. По изначальному плану проект ОВП должен был начаться два месяца назад, но подписали его только сегодня утром, поэтому, считайте, что мы уже на 2 месяца опаздываем.

https://habr.com/ru/articles/812095/

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