 |
Специфика управления персоналом
|
|
|
|
Требования к проекту. Планирование проектов.
Проект – это временное усилие предприятия для создания уникального продукта или услуги.
Временное означает что каждый проект имеет точно определенные даты начала и окончания, говоря об уникальности продукта или услуги подразумевается что они имеют заметные отличия от аналогичных продуктов или услуг.
У каждого проекта есть четко определенные начало и окончание, проект заканчивается вместе с достижением всех его целей или наоборот, когда становится ясно, что эти цели не могут быть достигнуты. Временность не означает краткосрочность проекта, многие проекты могут продолжаться несколько лет, в любом случае проект конечен и не может состоять из постоянно продолжающихся действий.
Виды деятельности, входящие в управление проектом.
Виды деятельности, которыми приходится заниматься руководителю проекта или группе управления проектом для обеспечения его успешного выполнения, можно разделить на следующие области:
· Управление содержанием проекта и качеством.
· Управление ресурсами проекта.
· Управление рисками.
· Управление коммуникациями и информационное обеспечение проекта.
· Управление конфигурациями и изменениями.
· Управление проектной средой и технологиями.
· Контроль и мониторинг состояния проекта.
Определение любой процедуры, которое вырабатывается в ходе одной из деятельностей в рамках управления проектом, должно включать определение условий ее запуска, входных документов и материалов, действий, которые необходимо выполнить, указание возможных способов их выполнения, условий окончания и выходных документов. В ходе проекта все установленные процедуры должны выполняться при достижении условий их запуска.
|
|
|
62. Управление содержанием проекта и качеством.
Управление содержанием проекта (project scope) является одним из критически важных для его успеха видов деятельности. Проект с нечетко определенным содержанием обречен на неудачу. Ясное же его определение — как постановка правильного вопроса — дает половину успешного ответа.
Большинство действий, связанных с определением содержания проекта, должно быть проведено уже на этапе подготовки к нему, еще до официального начала, — иначе не будет достаточных данных для принятия решения о запуске проекта.
Начинать определение содержания проекта надо с выяснения его целей. Основная цель должна описываться одной фразой и делать понятным предназначение проекта, очерчивать реальные потребности некоторых лиц и организаций, для удовлетворения которых предназначены его результаты.
Метрики ПО
Программный продукт должен соответствовать определенным стандартам качества. Необходимо точно, т.е. численно, определить эти стандарты. Такие численные данные называются метриками.
Метрика – это численная характеристика процесса разработки.
Примером метрики является «количество ошибок, обнаруженных за месяц работы» при заранее установленном уровне их серьезности.
Как только метрики и допустимые границы будут определены, необходимо удостовериться, что примененный процесс и выполненный проект отвечают установленным границам метрик.
В проектировании программ используют различные количественные характеристики, такие как число строк кода, число классов, количество дефектов, выявленных за месяц, число функций в классе и т.д.
Трактовка метрик определяется контекстом, в котором эти метрики используются.
Например, если две программы с одинаковой функциональностью, одинаково эффективны, надежны и хорошо структурированы, то более предпочтительней та, которая имеет меньшее число строк кода. В другом контексте большее число строк кода может означать большую производительность.
|
|
|
При наличии достаточной статистической базы метрика число строк кода может быть очень полезна, особенно в сочетании с другими характеристиками.
Например, если считать, что метрика надежности приложения остается на требуемом уровне, а увеличение строк кода отражает расширение возможностей приложения, становится понятным, что чем больше строк кода будет написано за час, тем лучше. Обычно ведется учет нескольких различных метрик.
Метрики могут применяться на всех этапах разработки ПО:
· в анализе требований
· в детальном проектировании
· в проверке качества, интеграции и системном тестировании
· в анализе архитектуры
· в оценке удобства и простоты использования
· в сопровождении
Метрики детального проектирования обычно включают в себя подсчет количества модулей, функций, точек входа и выхода. Для объектно-ориентированных приложений по аналогии подсчитывается количество пакетов, классов, методов, параметров, атрибутов и т.д. Более общей, а потому и более сложной является метрика 19 стандарта IEEE – структура проектирования, которая определяет «простоту детального проектирования» программы.
Выборочное использование метрик максимизирует отдачу от материальных вложений в проверку, фокусируя процесс проверки на важных, измеренных результатах.
Метрики, которые необходимо знать практически всегда:
1. Объем выполненной работы, измеренный в физических единицах (например, число строк кода)
Время, затраченное на выполнение работы
3. Степень дефектности ( число дефектов на 1000 строк кода, число дефектов на страницу документации и т.д.)
Управление ресурсами
Под ресурсами понимаются сотрудники и оборудование необходимые для выполнения проектных задач. Например для выполнения задачи «сбор предложений от авторов» в проекте должен быть задействован ответственный секретарь журнала. Каждый сотрудник участвующий в проекте получает определенную роль в соответствии со своей квалификацией требованиями проекта и регламентами действующими в организации.
|
|
|
При составлении списка ресурсов часто используется ролевое планирование, например: сначала определяется, что для исполнения работ требуются три программиста и один менеджер, а затем когда план проекта утвержден подбираются конкретные сотрудники для этих ролей.
Специфика управления персоналом
Проектная команда как правило по его окончании распадается, а ее члены переходят в другие проекты, хорошим примером проекта может быть разработка нового автомобиля.
Разработка осуществляется в ограниченные сроки и продолжается до достижения определенного результата, прототипа нового автомобиля, когда результат достигнут, автомобиль отправляется в производство, а проектная команда т.е. конструкторы, дизайнеры и прочие могут быть вовлечены в новый проект, хотя и не обязательно в том же составе.
Управление рисками
Неопределенности, влияющие на проект, могут грозить ему отрицательными последствиями, вплоть до полного провала, или положительными. Неопределенности первого вида принято называть рисками проекта, а второго — благоприятными возможностями.
И рисками, и благоприятными возможностями нужно уметь управлять. Что означает такое управление? Во-первых, это умение предвидеть такие возможности и риски, во-вторых, это умение оценивать их последствия для проекта, и, в-третьих, это умение выстраивать ход проекта так, чтобы воспользоваться благоприятными возможностями, если они наступят, и противостоять действию рисков, если они реализуются.
Классификация рисков:
1. Риски проекта, влияющие на его ход:
а) Технологические риски;
б) Кадровые риски;
в) Риски требований;
г) Коммерческие риски;
д) Управленческие риски;
е) Производственные риски;
2.Риски продукта, влияющие на результаты проекта:
а) Технические риски;
б) Эксплуатационные риски;
в) Правовые и общественные риски;
3.Бизнес-риски, относящиеся к ведению дел в организациях, связанных с проектом:
a) Контрактные риски;
b) Инвестиционные риски;
c) Сбытовые риски;
d) Конъюнктурные риски;
|
|
|
