Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорум

Почему проекты терпят крах и как сделать их успешными

Давайте начнем со статистики. Согласно Standish Group, в 1995 году всего лишь 16% проектов по разработке программного обеспечения были успешными, 53% встретили препятствия (такие как перерасход бюджета, увеличение затрат и дефекты в продукте) и 31% проектов были отменены. Более того, говорилось, что в среднем время разработки было продлено и составляло 222% по отношению к запланированному, при этом бюджет составлял 189%, а сам продукт содержал всего 61% требуемой функциональности.  К сожалению, как свидетельствуют  данные, за всё это время мало что изменилось.

В индустрии информационных технологий неудача стала нормой. Так что же мы можем сделать по этому поводу? Для начала, мы можем уделить внимание некоторым ключевым причинам краха проекта по разработке ПО.

Нехватка времени

Зачастую дата срока окончания проекта определяется до начала и позже не обсуждается. В результате все делается в спешке, предполагая, что чем раньше начнется создание кода проекта, тем быстрее он будет завершен.

В большинстве случаев это неверный подход. Время стоит уделить созданию хорошего дизайна - без хорошего дизайна проект будет проходить определенные изменения по ходу разработки. При этом тратится очень много времени и денег.

Решение: уделите время созданию хорошего плана. Избегайте желания сразу же начать работу над кодом и уделите больше времени на разработку дизайна - от этого проект  только выиграет, так как будет выполнен в лучшем виде.  Когда вы представите клиенту то, что удовлетворит его ожидания и при этом будет работать  как положено - это  лишь упрочит и подымет вашу репутацию.

Недостаток средств / маленький бюджет

Множество проектов следуют политике занижения цен или установки невероятно низких цен, не обоснованных какими-либо требованиями. При этом все процессы заметно замедляются - ресурсы доступны через некоторое время, используются обходные пути и страдает качество.

Решение: будьте реалистом - удостоверьтесь в том, что бюджет установлен на основании реальных требований. Избегайте установки бюджета на основании самых низких цен одного поставщика - работайте с теми поставщиками, которые обосновали и доказали вам свою ценовую политику и работают в сроки.

Недопонимание

Фраза "никогда не предполагай" как раз подходит в случае с проектами по разработке ПО. Понимание и хороший уровень общения с клиентами, пользователями и особенно с командой разработчиков жизненно важны для успеха проекта. Все ли вас понимают? Точно ли знают разработчики, что от них требуется, или вам только кажется, что они знают? Хорошо ли они общаются друг с другом, с пользователями и с другими отделами?

Решение: определите потенциальные проблемы общения сейчас. Они могут привести к путанице и осложнениям в дальнейшем. Никогда не предполагайте, что все всё понимают. Уделите время тому, чтобы создать такую среду, которая поможет вам завершить проект вовремя, согласно бюджету и удовлетворив ожидания клиента.

Прогресс проекта не рассматривается

По мере прогресса проекта многое может измениться, и данные изменения могут иметь значительное влияние. Важно следить за прогрессом постоянно, таким образом, эти препятствия могут быть преодолены заранее, и участники проекта будут оповещены о возможных задержках и изменениях в разрабатываемом продукте.

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

Неадекватное\неполноценное тестирование

тестирование откладывается до конца цикла разработки и этому не уделяется должное внимание. Зачастую результатом будет полный неисправностей продукт и недовольные клиенты.

Решение: проводите тестирование во время разработки, тестируя каждый модуль или компонент во время разработки. Тогда вам останется только провести тестирование интеграции в конце цикла разработки.

Тестирование производится в среде разработки

Удивляет, что многие организации тестируют продукт в среде его разработки. Это чревато высоким риском утечки информации и преждевременного выпуска товара.

Решение: разработайте процесс проверки качества и выпуска новых продуктов. Специально для тестирования создайте такую среду, которая будет независима от среды разработки.

Недостаток контроля над гарантией качества

В погоне за предоставлением товара в сроки зачастую страдает проверка качества. Изменения в коде не документируются, дизайн содержит критические ошибки, а реализация не полна. Это все приведит к различным доработкам, потере времени и, следовательно, к недовольству клиентов.

Решение: уделите время на проверку качества и документации ПО до того, как оно будет передано в использование.

Несоответствие стандартам отрасли

Соответствие стандартам отрасли может доказать лишь эффективность вашего проекта, обеспечивая доступность, портативность, легкость в использовании, стойкость к ошибкам и снижению количества проблем - как сейчас, так и в будущем. Такие органы власти, как Международная организация по стандартизации (ISO) и Консорциум по разработке и распространению стандартов и протоколов для WWW-системы (W3C) разработали открытые стандарты, при использовании которых продукт станет более качественным.

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

данному списку и напомнить себе о том, что следует выполнить некоторые шаги, обеспечивающие успех. Вы будете удивлены, когда увидите разницу в результатах.

Duncan Haughey, PMP


Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.