Если я правильно понял, вы используете инкрементный способ работы на проектом.
Вопросы:
Как вам (команде) удаётся так формализовать результат, чтобы потом без проблем его сдать Заказчику? Обычно строительное проектирование - сложный и длительный процесс (явно больше двух недель :) ). Возможно ли выделить "полуфабрикаты" для спринтов и потом доказать Заказчику, что они сделаны правильно?
Я пользовался SmartSheets. Мне понравилось (Это было на проекте в Mars). Там можно и канбан-доску сделать. Для средних проектов хороший инструмент. Но в моей текущей компании он не применяется. Никто о нём не слышал.
Проектное расписание (план-график) увеличивается в размере и становится крайне неудобным.
Обычно команда не имеет нормального доступа к mpp-файлам (лицензии нужны, а с учётом текущей ситуации их добывать непросто). Так что руководитель проекта сам варится в своём MS Project.
И т.д.
Поэтому я предпочитаю комбинировать два инструмента.
Такое ощущение, что в конце статьи что-то поломалось. Например:
"Если есть все четыре – поздравляю, вы круты, вы способны менять мир вокруг себя. Если нет – вот вам шаги, как сделать вашу компанию чуть лучше и вырасти на этом самим".
Шагов нет, есть только рисунок с улиткой. Где шаги?
Вот регламенты, которые стоит делать в любом случае любой ИТ команде, это подходит и для внутреннего ИТ, поддерживающего и развивающего инфраструктуру своей компании и продуктовых компаний (сильно похоже на предыдущий пункт) и для интеграторов.
Где эти регламенты?
Без конкретики это просто статья-лозунг: "Хорошо работать - это хорошо, а плохо работать - это плохо". Не нужно брать пример с т.н. "коучей".
Согласен с идеей делать два документы: краткий Устав с основными положениями и более детальный план управления проектом (например, набор связанных регламентов управления объёмом, сроками, рисками, качеством и т.д. по PMBoK). Но вот регламент согласования проектных документов я бы сразу прикладывал к контракту, потому что Уставом резинщиков не проймёшь.
Беда в том, что часто менеджера проекта приглашают к моменту его старта или даже позже, когда уже накосячено, а исправлять некогда - "побежали делать проект, чтобы не отстать".
Всё разумно. Права, Устав на проектах никто не учит, но если менеджер проекта старается всё делать в соответствии с правилами Устава, то и остальные втягиваются.
При этом хорошо бы сделать Устав компактным, до 50 страниц. В идеале: 20 - 30 стр. Тогда есть шанс, что его будут читать. Тома от 100 страниц вообще всех отпугивают :)
Как всё знакомо! Но иногда ситуация на старте проекта может меняться. Руководство может разочароваться в будущем продукте, увлечься новыми идеями (как сейчас все ринулись в туманную область AI), по каким-то причинам начнёт экономить бюджет... И все договорённости на старте о поддержке спонсора проекта и ключевых стейкхолдеров, проектном резерве и т.п. сразу испаряются.
Что касается премии, то только в одной компании из многих, в которых я проработал, бонусное письмо применялось и работало безотказно. Ещё в четырёх сработали договорённости и я получил обещанную премию. В остальных случаях всё было либо мутно, либо недостижимо, либо не сильно зависело от твоих усилий.
Но идея правильная. В моменте это работает. Но потом деньги тратятся и забываются, а успешные проекты остаются в резюме :)
Если я правильно понял, вы используете инкрементный способ работы на проектом.
Вопросы:
Как вам (команде) удаётся так формализовать результат, чтобы потом без проблем его сдать Заказчику? Обычно строительное проектирование - сложный и длительный процесс (явно больше двух недель :) ). Возможно ли выделить "полуфабрикаты" для спринтов и потом доказать Заказчику, что они сделаны правильно?
Вовлечён ли Заказчик в планирование спринта?
Ревью - это в том числе и "ретро"?
Проектную зрелость Заказчика понять не просто, в том числе наличие работающей проектной методологии. Обычно я начинаю с таких вопросов:
Есть ли проектная методология?
Можно ли с ней ознакомиться? (чтобы посмотреть качество документации).
Какое программное обеспечение у вашей проектной методологии (если на первый вопрос ответили "да")?
Есть ли у вас "лучшие практики"? Можно ли на них глянуть?
Как Вы считаете, сможем ли мы применить вашу методологию на нашем проекте?
Какая часть методологических требований обязательна, какая опциональна?
Кто у вас поддерживает и развивает методологию проектного управления?
Дальше нужно анализировать полученную информацию.
Не хотите ли поделиться идей? Например, написать статью про свой инструмент.
Я пользовался SmartSheets. Мне понравилось (Это было на проекте в Mars). Там можно и канбан-доску сделать. Для средних проектов хороший инструмент. Но в моей текущей компании он не применяется. Никто о нём не слышал.
Но при этом:
Проектное расписание (план-график) увеличивается в размере и становится крайне неудобным.
Обычно команда не имеет нормального доступа к mpp-файлам (лицензии нужны, а с учётом текущей ситуации их добывать непросто). Так что руководитель проекта сам варится в своём MS Project.
И т.д.
Поэтому я предпочитаю комбинировать два инструмента.
Такое ощущение, что в конце статьи что-то поломалось. Например:
"Если есть все четыре – поздравляю, вы круты, вы способны менять мир вокруг себя. Если нет – вот вам шаги, как сделать вашу компанию чуть лучше и вырасти на этом самим".
Шагов нет, есть только рисунок с улиткой. Где шаги?
Где эти регламенты?
Без конкретики это просто статья-лозунг: "Хорошо работать - это хорошо, а плохо работать - это плохо". Не нужно брать пример с т.н. "коучей".
Согласен с идеей делать два документы: краткий Устав с основными положениями и более детальный план управления проектом (например, набор связанных регламентов управления объёмом, сроками, рисками, качеством и т.д. по PMBoK). Но вот регламент согласования проектных документов я бы сразу прикладывал к контракту, потому что Уставом резинщиков не проймёшь.
Беда в том, что часто менеджера проекта приглашают к моменту его старта или даже позже, когда уже накосячено, а исправлять некогда - "побежали делать проект, чтобы не отстать".
Всё разумно. Права, Устав на проектах никто не учит, но если менеджер проекта старается всё делать в соответствии с правилами Устава, то и остальные втягиваются.
При этом хорошо бы сделать Устав компактным, до 50 страниц. В идеале: 20 - 30 стр. Тогда есть шанс, что его будут читать. Тома от 100 страниц вообще всех отпугивают :)
Как всё знакомо! Но иногда ситуация на старте проекта может меняться. Руководство может разочароваться в будущем продукте, увлечься новыми идеями (как сейчас все ринулись в туманную область AI), по каким-то причинам начнёт экономить бюджет... И все договорённости на старте о поддержке спонсора проекта и ключевых стейкхолдеров, проектном резерве и т.п. сразу испаряются.
Что касается премии, то только в одной компании из многих, в которых я проработал, бонусное письмо применялось и работало безотказно. Ещё в четырёх сработали договорённости и я получил обещанную премию. В остальных случаях всё было либо мутно, либо недостижимо, либо не сильно зависело от твоих усилий.
Но идея правильная. В моменте это работает. Но потом деньги тратятся и забываются, а успешные проекты остаются в резюме :)