Оценка результатов и принятие решений
Оценка результатов апробации новых процессов должна показать - достигнуты ли поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций, апробированных на пилотном проекте, либо "овчинка выделки не стоит".
Среди ключевых вопросов в области оценки результатов можно выделить следующие [14.3].
Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов?
Собираетесь ли вы менять что-либо в следующих пилотных проектах?
Как прошло общее внедрение новых технологических процессов?
Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов?
Смогли ли участники понять и эффективно применить новые процессы?
Собираетесь ли вы менять что-либо при проведении следующего внедрения?
При оценивании результативности достижения поставленных целей следует различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект "кривой обучения" (learning curve) [14.3]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое "лощиной отчаяния" - в - это часть необходимого вклада, который ваша организация вносит в совершенствование процессов.
Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды.
15. Лекция: Требования в управлении проектом
Чтобы определить сметную стоимость и продолжительность работ по проекту автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а также сформировать архитектурную основу, крайне желательно создать прототипы. Поэтому в этой лекции будут рассмотрены различные способы планирования проектов
Чтобы определить сметную стоимость и продолжительность работ по проекту автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а также сформировать архитектурную основу, крайне желательно создать прототипы. И это - как минимум. Иными словами, для того, чтобы создать АИС, сначала нужно проанализировать возможность создания.
Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например:
Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение?
Кто оплатит работы по анализу требований? (очевидно, Заказчик)
Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований?
Разумный Заказчик сможет найти выход из этого непростого положения, например:
подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается);
взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий
разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата - путь гибких (agile) методологий.