Первый этап проекта программного обеспечения включает в себя написание предложения для реализации этого проекта. В предложении описаны цели проекта и способы его реализации. Он включает в себя сметы и планирование.
Обоснуйте, почему проектный контракт должен быть передан конкретной организации или команде. Планирование проекта относится к определению мероприятий, этапов и результатов, произведенных проектом. Поэтому должен быть составлен план, который будет направлять развитие к целям проекта. Оценка стоимости - это связанная деятельность, которая относится к оценке ресурсов, необходимых для выполнения плана проекта.
Надзор за проектом является постоянной деятельностью. Администратор должен знать о ходе реализации проекта и сравнивать фактический прогресс и затраты с запланированными. В дополнение к формальным механизмам, постоянный неформальный надзор предсказывает основные проблемы проекта и выявляет трудности в то время. Например, эти ежедневные неформальные интервью могут вывести проблему из-за сбоя программного обеспечения. Вместо ожидания просроченного отчета по проекту администратор может назначить эксперта для решения проблемы или решить, перенесена ли эта проблема.
Управление программным обеспечением включает планирование, планирование, управление орошением, управление персоналом, оценку стоимости программного обеспечения и управление качеством. Эта статья посвящена управлению рисками и управлению персоналом. Существует множество причин неудачи программных проектов, их можно упомянуть: задержка доставки, ненадежность, превышение расчетной стоимости, плохие характеристики производительности. Много раз сбой был в подходе к управлению.
Управление рисками
Очень важная задача менеджера проекта - предвидеть риски, которые могут повлиять на график проекта или качество разрабатываемого программного обеспечения, и предпринять действия, чтобы избежать этих рисков. Результаты этого анализа риска должны быть задокументированы по всему плану проекта вместе с анализом последствий при возникновении риска. Их выявление и составление планов по минимизации их воздействия на проект называется управлением рисками. Методология Единого процесса разработки предоставляет структуру, которая позволяет характеризовать риск:
- Название риска, Величина, Описание, Воздействие, Индикатор, Стратегия отмены, Стратегия смягчения, План на случай непредвиденных обстоятельств.
Как видите, название риска определено, величина представляет его опасность (серьезный, умеренный или слабый), также есть его описание, его влияние на проект; индикатор, который указывает на это. Существует стратегия отмены, которая стремится уменьшить вероятность возникновения риска; а также стратегия смягчения, которая означает снижение его воздействия; в случае, если последнее неэффективно, существует план действий в чрезвычайных ситуациях.
Проще говоря, риск можно рассматривать как вероятность возникновения неблагоприятных обстоятельств. Риски представляют угрозу для проекта, для разрабатываемого программного обеспечения и для организации. Эти категории риска определены, как показано ниже:
- Риски проекта: влияют на график или ресурсы проекта. Риски продукта: влияют на качество или производительность разрабатываемого программного обеспечения. Деловые риски: влияют на организацию, разрабатывающую программное обеспечение.
Конечно, эта классификация не уникальна, риск может охватывать несколько моментов, отмеченных выше. Примером этого может быть риск: опытный программист отказывается от проекта, это риск для проекта, потому что он может задержать доставку системы; это риск для продукта, потому что заменитель может быть не таким опытным и совершать много ошибок; и для бизнеса, потому что этот опыт не может способствовать будущему бизнесу.
Мониторинг рисков должен быть непрерывным процессом, и при каждом рассмотрении прогресса серьезные риски должны рассматриваться отдельно и обсуждаться аудиторией.
Управление персоналом
Менеджеры проектов обычно должны выбирать людей для работы над их проектом. В идеале, сотрудники с соответствующими навыками и опытом будут доступны для работы над проектом.
Однако во многих случаях администраторы должны создать минимальную идеальную команду для проекта. Причины этого:
- Бюджет проекта не распространяется на наем высокооплачиваемого персонала. Вы должны нанимать менее опытных сотрудников и меньше платить, но лучше использовать их. Персонал с соответствующим опытом не доступен ни внутри, ни за пределами организации. Невозможно нанять новый персонал для проекта. В рамках организации лучшие люди уже были назначены для других проектов. Организация хочет развивать навыки своих сотрудников. Неопытный персонал может быть назначен на проект, чтобы учиться и получать опыт.
Администратор программного обеспечения должен работать с этими ограничениями при подборе персонала проекта. Тем не менее, все эти проблемы, вероятно, возможны, если только у участника проекта нет опыта в типе системы, которая будет разработана. Без этого опыта, многие небольшие ошибки, вероятно, будут сделаны.
Должен быть разработан план развития персонала, который описывает, как будут развиваться навыки и опыт членов проектной команды. Персонал, работающий в организации, занимающейся программным обеспечением, - ваш самый большой актив Он представляет собой интеллектуальный капитал, и администраторы программного обеспечения должны обеспечивать, чтобы организация получала максимально возможную прибыль, инвестируя в людей. Эти люди должны иметь уровень ответственности и должны получать призы в соответствии с их способностями. Менеджеры проектов должны решать технические и нетехнические проблемы, мотивировать людей, планировать и организовывать их работу, следя за тем, чтобы она выполнялась правильно. Плохое управление персоналом является одним из наиболее важных факторов провала проекта.
Одна из важнейших ролей руководителей проектов - мотивировать людей, которые с ними работают. Маслоу (1954) отметил, что мотивация людей заключается в удовлетворении их потребностей и что эти потребности распределяются на нескольких уровнях:
- Физиологические потребности, потребности в безопасности, социальные потребности, оценки потребностей.
Люди, которые работают в организациях по разработке программного обеспечения, обычно не голодны и не испытывают жажду и обычно не чувствуют физической угрозы со стороны своей среды. Поэтому обеспечение удовлетворения социальных потребностей, уважения и самореализации более важно с административной точки зрения. Удовлетворение социальных потребностей означает предоставление людям времени для знакомства с коллегами и предоставления им мест для встреч. Неформальные и простые в использовании каналы связи, такие как электронная почта, очень важны.
Чтобы удовлетворить потребности уважения, вы должны показать людям, что они представляют большую ценность для организации. Общественное признание достижений - простой, но эффективный способ сделать это. Очевидно, что люди также должны чувствовать, что им платят в соответствии с уровнем, который отражают их навыки и опыт.
С другой стороны, чтобы удовлетворить потребности в самореализации, люди должны нести ответственность за свою собственную работу, назначать сложные (но не невыполнимые) задачи и иметь программу обучения, где они могут развивать свои навыки. Людей мотивируют не только личные потребности, но и цели этих больших групп. Быть членом единой группы очень мотивирует многих людей. Людям, которые удовлетворены своей работой, часто нравится работать, потому что они мотивированы людьми, которые работают с ними и работой, которую они делают.
Библиография
- Ян Соммервилль, «Разработка программного обеспечения», 6-е издание. Образование Пирсона, 2002.
- И. Арчер Пупо, «Фазы единого процесса развития».
