Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Что может сорвать проект по разработке ПО?

Что может сорвать проект по разработке ПО?

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

Неумение сказать «нет» и попытка «объять необъятное». Нужно знать, когда сказать «Да», а когда «Нет. Это будет реализовано в следующей версии». Нечеткие границы проекта могут погубить его гораздо быстрее, чем кажется. И проблема не просто в дополнительном объеме работ. В план проекта изначально не должно входить добавление новых функций и изменение требований. Несомненно, условия могут меняться, но для того чтобы внести изменения требуется намного больше времени, чем заложено в план. Большие проекты охватывают слишком много областей. Двигаться вперед лучше постепенно – даже в рамках большого проекта. Для этого нужно составить четкий список задач, которыми легко управлять. Часто массовый и срочный переход компании на новые информационные системы заканчивается провалом из-за сложности подобного проекта или из-за того, что конечные пользователи просто не могут адаптироваться к значительным изменениям.

Недостатки взаимодействия. Далеко не все участники проекта принимают участие в совещаниях, потому что либо обсуждаемые вопросы не имеют к ним прямого отношения, либо решения принимаются единолично менеджером проекта. Но в любом случае вся проектная команда должна знать о принятых решениях. Иначе на выходе может получиться продукт, не отвечающий новым требованиям, и его придется переделывать. Также случается, что менеджер проекта обещает заказчику сдать проект в сроки, не согласованные с разработчиком. Это прямая дорога к срыву проекта и к разочарованию, как исполнителя, так и заказчика. Проект вряд ли будет успешным, если разработчику нужно сделать работу в нереально короткие сроки. Иногда менеджер проекта просто не слушает разработчика, когда тот говорит о возникающих проблемах. Но вечно скрывать плохие новости от руководства тоже нельзя. Тем не менее, это довольно распространенная проблема. Это особенно плохо для проектов по разработке ПО, где ошибки стоят очень дорого.

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

Новые технологии программирования и собственные библиотеки. Некоторым разработчикам свойственно использовать новые, непроверенные технологии. В программировании важен баланс нового и старого. Действительно ли новые технологии лучше, получат ли они распространение или в скором времени исчезнут? Выбор правильной технологии – целое искусство, но лучше не использовать бета-версии библиотек, которые появились только вчера. Также многие разработчики не покупают готовые библиотеки, а пишут собственные. У них есть свои преимущества, но также много и недостатков. Необходимо оценить возможность использования уже имеющихся библиотек, прежде чем браться за проектирование, разработку и тестирование собственных.

Бесполезные прототипы. В прототипах нет ничего плохого. Можно написать прототип на другом языке или для другой системы, чему-то научиться и приступить к разработке ПО. Опасность заключается в том, что можно потратить слишком много времени на прототип, который не пригодится при разработке реального продукта. Например, если вы будете разрабатывать продукт в ASP.NET, вы напрасно потратите время на создание прототипа в Ruby on Rails и изучение доступа к базе данных на Rails. Смысл есть в прототипе с минимальной поддержкой серверной части для получения обратной связи от пользователя.

По материалам techrepublic.com

Дополнительные материалы

Комментарии (0)