Проект действительно был не самым простым, хотя б потому, что это крупнейшее внедрение дискретного производства на Oracle WIP. И обучение — это было не самой сложной частью.
Идея использовать лонгриды и lms мне нравится. В следующих раз используем.
Да, Вы правы, я допустил использование манипуляции, неосознанно впрочем.
Как и в проекте, когда в начале проекта, заказчик не до конца понимая все последствия, подписывает документ с требованиями, налицо манипуляция со стороны подрядчика. Обратная ситуация столько же часто встречается, когда заказчик не раскрывает все сложности или детали в ТЗ, которые всплывают позже.
Вопрос не в том, что нравится мне. Каждый метод хорош в своих условиях. В тех условиях, в которых работаем мы, итерационный подход зарекомендовал себя лучше.
Все верно. Важно то, что все эти комбинации технологий действительно меняют производство — ускоряют цикл от проектирования до выпуска, делают продукты более специализированными для конкретного заказчика, собирать больше данных от оборудования, лучше планировать и повышать его полезную загрузку.
Я бы сделал это все на страничках в конфлюенс, которые легко дополнять по мере выхода нового функционала. Можно или копировать текст, или включать в виде текста другую страницу, что позволяет разделить ответственность за подготовку. Наверху всегда будет лежать самая последняя версия документации. Мы на проекте все инструкции пользователей реализовали в конфлюенс, а потом перевели туда и все функциональные дизайны.
В конфлюенс есть возможность архивировать всю базу целиком. А потом восстанавливать ее как другое пространство. Таким образом у вас будет несколько версий. Может быть я не совсем понимаю, зачем это делать, но ничего другого в голову не приходит.
Это правда, дополнительных покупок может быть много. Из интересных плагинов я бы еще упомянул BigPicture и Structure. Они дают хорошую видимость и структуру задач JIRA.
Но по сравнению с проектами SAP или Oracle, которых мы продаем нашим Заказчикам, стоимость всего этого добра исчезающе мала, а повышение эффективности работы команды полностью окупает затраты.
Приведу конкретный пример. На одном проекте SAP, где я возглавлял группу РМО, кроме меня было еще 3 человека, и мы собирали данные из многочисленных реестров Excel и готовили отчеты. На другом проекте, не менее масштабном, я был РП и львиную долю информации брал из JIRA. Группы РМО у меня просто не было. Минус 4 человека.
Вероятно, вы действительно не понимаете. Возможно причина в том, что вы идете по заголовкам.
Если Вы считаете, что любые правила удушающие, то вам будет сложно принять, что в большом проекте нет других вариантов, кроме как работать по правилам. В противном случае никакого проекта не состоится. Другое дело, что можно эти правила сделать легкими для следования — разумными и не очень накладными для исполнения. Об этом я как раз и пишу, имея опыт их применения в разных вариантах, на разных проектах.
Возможно, этот опыт не релевантен вашей ситуации, поэтому Ваши суждения могут быть также не вполне уместными.
История прекрасная! Какие ресурсы вам нужны на это дело? С какой целью — обучиться и приобрести начальные навыки? Так это очень недорого стоит. Помочь? На сайте dantipov.tilda.ws есть мои кординаты
Согласен. Часто с самыми большими рисками сложно что-то поделать. И мы закрываем на них глаза. Поэтому на своем сайте я поставил, в качестве заглавной картинки к статье, идущий навстречу поезд.
В статье написано, что процедуры редко работают, потому что это не так просто, как кажется, и требует усилий, а результаты не очевидны. Я даю рецепты, как это сделать проще и результативней.
Дожидаться, когда все остальное будет хорошо, нельзя. Управление рисками — это неотъемлемая часть работы РП, делает он это явно или нет. Я за то, чтобы сделать эту работу явной, структурированной и аудироемой.
Риск-менеджмент — это не серебряная пуля, которая решит все проблемы, так же как и все остальные процедуры. Все работает только в комплексе. Уберешь одну подпорку, конструкция упадет.
Дискуссии на тему, включить ли возможности в понятие риска, ведутся снова и снова.
На практике в реестре рисков ни разу не видел возможностей. Из-за разницы вы интересах, часто возможности одних — это потери других, поэтому возможности не афишируются.
В любом случае, я не спорю о терминах. И да, моя статья посвящена работе с угрозами.
Денис, я ставил перед собой задачу — помочь руководителю проекта, который уже знает что-то о рисках, а может быть даже получил сертификат PMI, приземлить тему и использовать эти знания на практике. Теоретические и нормативные материалы найти не проблема. Спасибо, что указали стандарты, по названиям каждый может поискать в интернете.
Мне нравится определение риска, в сравнении с проблемой: «Если вы чувствуете неприятный запах, то это риск. Если наступили — то это уже проблема».
Буду благодарен, если немного подробнее напишите, каким образом используете SWOT анализ при идентификации риска.
Трудно оценить %. Первая оценка делается быстро. В списке Excel надо указать сложность задачи (подумать) и ее тип, трудоемкость подставиться автоматически. Но это первое приближение. Потом, когда аналитик и разработчик начинают детально разбирать задачу, они заново оценивают плановую трудоемкость, которая идет на утверждение заказчику. Поскольку оплата была по плановой трудоемкости, то иногда начинались переговоры, которые требовали обоснования и дискуссии. Анализ, сколько мы потратили на это время, никто не проводил.
Нет, такие метрики мы не считали. Я был РП программы проектов, и до такого уровня я физически не мог опуститься. А руководители разработки, видимо, не считали нужным.
Я буду очень рад, если возникнет дискуссия. Всегда интересно узнать другое мнение и подвергнуть свой опыт сомнению. Чтобы в следующий раз сделать лучше.
Но надо понимать, что каждое решение принимается в определенных обстоятельствах, и на тот момент оно было лучшим из всех, которые я видел.
Идея использовать лонгриды и lms мне нравится. В следующих раз используем.
Как и в проекте, когда в начале проекта, заказчик не до конца понимая все последствия, подписывает документ с требованиями, налицо манипуляция со стороны подрядчика. Обратная ситуация столько же часто встречается, когда заказчик не раскрывает все сложности или детали в ТЗ, которые всплывают позже.
Вопрос не в том, что нравится мне. Каждый метод хорош в своих условиях. В тех условиях, в которых работаем мы, итерационный подход зарекомендовал себя лучше.
Но по сравнению с проектами SAP или Oracle, которых мы продаем нашим Заказчикам, стоимость всего этого добра исчезающе мала, а повышение эффективности работы команды полностью окупает затраты.
Приведу конкретный пример. На одном проекте SAP, где я возглавлял группу РМО, кроме меня было еще 3 человека, и мы собирали данные из многочисленных реестров Excel и готовили отчеты. На другом проекте, не менее масштабном, я был РП и львиную долю информации брал из JIRA. Группы РМО у меня просто не было. Минус 4 человека.
Если Вы считаете, что любые правила удушающие, то вам будет сложно принять, что в большом проекте нет других вариантов, кроме как работать по правилам. В противном случае никакого проекта не состоится. Другое дело, что можно эти правила сделать легкими для следования — разумными и не очень накладными для исполнения. Об этом я как раз и пишу, имея опыт их применения в разных вариантах, на разных проектах.
Возможно, этот опыт не релевантен вашей ситуации, поэтому Ваши суждения могут быть также не вполне уместными.
Дожидаться, когда все остальное будет хорошо, нельзя. Управление рисками — это неотъемлемая часть работы РП, делает он это явно или нет. Я за то, чтобы сделать эту работу явной, структурированной и аудироемой.
Риск-менеджмент — это не серебряная пуля, которая решит все проблемы, так же как и все остальные процедуры. Все работает только в комплексе. Уберешь одну подпорку, конструкция упадет.
На практике в реестре рисков ни разу не видел возможностей. Из-за разницы вы интересах, часто возможности одних — это потери других, поэтому возможности не афишируются.
В любом случае, я не спорю о терминах. И да, моя статья посвящена работе с угрозами.
Мне нравится определение риска, в сравнении с проблемой: «Если вы чувствуете неприятный запах, то это риск. Если наступили — то это уже проблема».
Буду благодарен, если немного подробнее напишите, каким образом используете SWOT анализ при идентификации риска.
Но надо понимать, что каждое решение принимается в определенных обстоятельствах, и на тот момент оно было лучшим из всех, которые я видел.