Технические советы по управлению проектами ERP
8 Technical ERP Project Management Tips
1. Слишком раннее расширение границ проекта.
Почти всегда в ходе уточнения бизнес-требований выясняется полезность той или иной бизнес-функции, не включенной на этапе первичного сбора бизнес-требований и поэтому не включенное в техническое задание. Также представляется, что включить это бизнес-требование не составляет труда, тем более, что функциональность ERP позволяет реализовать дополнительное бизнес-требование. И, желая быть "хорошими" в глазах Заказчика, вы делаете это.
Но... вы оценили время на разработку, но не оценили потребное время на тестирование, включая (и в особенности) интеграционное тестирование. И тем самым заложили фундамент для срыва и бюджета, и сроков проекта.
2. Будьте реалистичны по отношению к графику проекта.
Классический треугольник управления проектами:
Но время, это фактор, который не всегда поддается уменьшению за счет других факторов и дополнительные ресурсы не всегда позволяют уменьшить время. Поэтому по отношению к этому фактору, - фактору времени, - следует быть наиболее реалистичным.
3. Выделите время для регрессионного тестирования
Создать график проектирования и разработки программного обеспечения довольно просто: вы можете оценить сложность реализации каждой функции и на основании этого вы можете приблизительно определить, - сколько часов и дней тестирования потребуется для реализации каждой функции.
В последнее время наблюдается тенденция автоматизации регрессионного тестирования с использованием предопределенных тестовых сценариев. Хотя эта автоматизация может сэкономить ваше время при проведении регрессионного тестирования, все же важно включить время в план проекта для создания тестовых сценариев, с тем чтобы иметь возможность автоматизации регрессионного тестирования.
4. Используйте шаблоны для документов проектирования и разработки.
Это также экономит время авторам документов, а также будет служить хорошим напоминанием о обязательных элементах, которые должны быть отражены в документации.
5. Используйте инструменты DevOps для отслеживания статуса результатов
Еженедельным, а иногда и ежедневным требованием для руководителей проектов ERP является отчет о состоянии проекта. Поскольку руководители проектов не могут присутствовать на всех семинарах и совещаниях, данные для этих отчетов предоставляются другими членами проектной группы.
Запрашивание ежедневных или еженедельных обновлений у каждого члена вашей команды отнимает много времени у всех вовлеченных сторон - бизнес-аналитики и консультанты ERP должны каждый день выделять время для написания отчета, а затем вы, как руководитель проекта, должны объединить все эти отдельные отчеты.
Однако, если ваш проект использует инструмент DevOps, вы можете просто извлечь необходимые данные по требованию, чтобы добавить их в отчет. Это избавляет вашу команду проекта от необходимости выполнять двойную работу, поскольку они уже будут выполнять и обновлять свои задачи в DevOps.
6. Создайте план ввода в эксплуатацию.
План ввода в эксплуатацию - это список действий, необходимых для подготовки производственной среды для использования конечным пользователем. Примеры задач - загрузка логинов пользователей, запуск пакетных заданий, подключение компонентов оборудования, запуск служб интеграции.
7. Не забудьте о том, что команда должна переодически иметь возможность для отдыха и развлечений. Это тоже стоит учесть в графике проекта.
8 Technical ERP Project Management Tips
1. Слишком раннее расширение границ проекта.
Почти всегда в ходе уточнения бизнес-требований выясняется полезность той или иной бизнес-функции, не включенной на этапе первичного сбора бизнес-требований и поэтому не включенное в техническое задание. Также представляется, что включить это бизнес-требование не составляет труда, тем более, что функциональность ERP позволяет реализовать дополнительное бизнес-требование. И, желая быть "хорошими" в глазах Заказчика, вы делаете это.
Но... вы оценили время на разработку, но не оценили потребное время на тестирование, включая (и в особенности) интеграционное тестирование. И тем самым заложили фундамент для срыва и бюджета, и сроков проекта.
2. Будьте реалистичны по отношению к графику проекта.
Классический треугольник управления проектами:
- объем,
- время
- и стоимость.
Но время, это фактор, который не всегда поддается уменьшению за счет других факторов и дополнительные ресурсы не всегда позволяют уменьшить время. Поэтому по отношению к этому фактору, - фактору времени, - следует быть наиболее реалистичным.
3. Выделите время для регрессионного тестирования
Создать график проектирования и разработки программного обеспечения довольно просто: вы можете оценить сложность реализации каждой функции и на основании этого вы можете приблизительно определить, - сколько часов и дней тестирования потребуется для реализации каждой функции.
Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20—50 %) влечёт появление новой. Поэтому весь процесс идёт по принципу «два шага вперёд, шаг назад».
Почему не удается устранять ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной, или документация очень хорошей, отдалённые последствия этого исправления останутся незамеченными. Во-вторых, ошибки обычно исправляет не автор программы, а зачастую младший программист или стажёр.
Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически, после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое возвратное (регрессионное) тестирование действительно должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит.
Ф. Брукс Мифический человеко-месяц или как создаются программные системыПри оценки времени реализации проекта почти всегда забывают о регрессионном тестировании. Регрессионное тестирование - это повторное тестирование всех ранее пройденных тестовых сценариев, выполняемое для того, чтобы убедиться, что новая разработка или доработка не повлияла на результаты. Регрессионное тестирование иногда может занять больше времени, чем тестирование самой новой функции.
В последнее время наблюдается тенденция автоматизации регрессионного тестирования с использованием предопределенных тестовых сценариев. Хотя эта автоматизация может сэкономить ваше время при проведении регрессионного тестирования, все же важно включить время в план проекта для создания тестовых сценариев, с тем чтобы иметь возможность автоматизации регрессионного тестирования.
4. Используйте шаблоны для документов проектирования и разработки.
Это также экономит время авторам документов, а также будет служить хорошим напоминанием о обязательных элементах, которые должны быть отражены в документации.
5. Используйте инструменты DevOps для отслеживания статуса результатов
Еженедельным, а иногда и ежедневным требованием для руководителей проектов ERP является отчет о состоянии проекта. Поскольку руководители проектов не могут присутствовать на всех семинарах и совещаниях, данные для этих отчетов предоставляются другими членами проектной группы.
Запрашивание ежедневных или еженедельных обновлений у каждого члена вашей команды отнимает много времени у всех вовлеченных сторон - бизнес-аналитики и консультанты ERP должны каждый день выделять время для написания отчета, а затем вы, как руководитель проекта, должны объединить все эти отдельные отчеты.
Однако, если ваш проект использует инструмент DevOps, вы можете просто извлечь необходимые данные по требованию, чтобы добавить их в отчет. Это избавляет вашу команду проекта от необходимости выполнять двойную работу, поскольку они уже будут выполнять и обновлять свои задачи в DevOps.
6. Создайте план ввода в эксплуатацию.
План ввода в эксплуатацию - это список действий, необходимых для подготовки производственной среды для использования конечным пользователем. Примеры задач - загрузка логинов пользователей, запуск пакетных заданий, подключение компонентов оборудования, запуск служб интеграции.
7. Не забудьте о том, что команда должна переодически иметь возможность для отдыха и развлечений. Это тоже стоит учесть в графике проекта.
Комментариев нет:
Отправить комментарий