Книги по разным темам Pages:     | 1 |   ...   | 23 | 24 | 25 | 26 | 27 |   ...   | 33 |

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

7.4. Персонал проекта по разработке программного обеспечения 7.4.1. Управление персоналом проекта Главным ресурсом, необходимым для производства программного обеспечения, являются люди. В первую очередь, конечно, важны технические навыки участников проекта. Однако эти навыки необходимо применять в нужное время и в нужном месте, что предполагает комбинацию работы в команде и лидерства. В соответствии с Законом Брукса, сформулированным Бруксом (Brooks) в его знаменитой книге Мифический человеко-месяц, привлечение большего числа людей в погибающий программный проект не помогает, а может даже и навредить. Однако при грамотном управлении персоналом такие дополнительные человеко-месяцы, появляющиеся в ходе проекта, могут оказаться очень полезными.

Фредерик Брукс - профессор вычислительной техники в школе бизнеса Кенан университета штата Северная Каролина в Чэпел Хилл. Он известен, прежде всего, как "отец IBM System/360". Помимо этого, Брукс занимался разработкой в IBM архитектуры компьютеров Stretch и Harvest. В 1985 году Фредерик Брукс, Боб Эванс и Эрик Блох были награждены Национальной медалью в области технологии за проектирование разработки операционной системы Operating System/360. Доктор Брукс был членом национального и военного комитетов по науке, основал в Чэпел Хилл факультет вычислительной техники и возглавлял его с по 1984 годы. В настоящее время он занимается преподаванием и исследованиями в области архитектуры компьютеров, молекулярной графики и виртуальных сред.

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

Менеджер сам в этом заинтересован, так как недовольные сотрудники работают непродуктивно. Одной из самых трудных задач менеджера является выполнение работы при условии получения коллективом удовлетворения от проделанной работы. Например, руководство компании может поставить условие, что работа должна быть выполнена на старом языке программирования для совместимости версий, хотя разработчикам было бы интереснее опробовать новый язык программирования. Менеджер должен сделать так, чтобы техническое творчество исполнителей имело нужное направление. Диктатура в управлении может вызвать негодование коллектива и привести к потере мотивации, а излишнее попустительство может привести к потере времени и напрасно проделанной работе. Решением проблемы является лидерство, выяснение истинных желаний и потребностей людей, активное их распределение и объединение в попытке достижения успеха. Лидеры проекта должны варьировать степень своей ответственности в управлении, основываясь на величине проекта. В больших проектах их обязанности состоят в основном в управлении. В малых же проектах лидеры могут обеспечивать как общее управление, так и личное участие непосредственно в разработке.

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

7.4.2. Развитие команды проекта Оптимальный размер команды Как правило, количество сотрудников, с которыми приходится регулярно общаться каждому из команды исполнителей проекта, составляет от трех до восьми человек. В принципе программистразработчик может работать почти без регулярного индивидуального общения с кем бы то ни было. Однако такая изоляция обычно приводит к непониманию разработчиком предъявляемых к нему требований и, как следствие, к относительно низкому уровню эффективности. С другой стороны, если участник проекта работает в слишком большой команде, то из-за постоянного общения с каждым из коллег у него не останется времени на выполнение своих основных обязанностей по проекту. Это снова приводит к относительно низкому уровню эффективности. В частности, регулярное общение означает разговор с кем-либо в течение примерно двух часов в неделю. Таким образом, если сотрудник регулярно общается с десятью своими коллегами, то половина его рабочего времени (20 из 41 часа в неделю) проходит в разговорах.

Менеджеры проектов, планирующие проекты с большими командами, должны это учитывать.

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

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

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

Развитие команды и развитие персонала Каждый проект, кроме достижения основной своей цели, должен использоваться менеджером для развития команды. А именно, в процессе выполнения проекта:

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

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

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

Смысловые связи между рассмотренными понятиями менеджмента удобно представить в виде карты памяти 7.6. Карта памяти по теме 7.7. Список использованной и дополнительной литературы 1. Неларин Корнелиус. HR менеджмент. Поиск, подбор, тренинг, адаптация, мотивация, дисциплина, этика, Издательство: Баланс Бизнес Букс, 2005.

2. Н. Г. Агеева, О. Н. Дмитриев, Э. С. Минаев. Менеджмент для инженера. Часть 1. Основы менеджмента. Серия: Бизнес для инженера, Издательства: Высшая школа, Доброе слово, 2002 г.

3. Гусарова Н.Ф. Общая психология / Уч. пособие. СПб: СПбГИТМО (ТУ), 2001.

4. Гусарова Н.Ф. Координация в технологических процессах со слабо формализуемыми критериями. Монография. СПб:

СПБГИТМО(ТУ), 2001.

5. Баранов С. Н. Управление программным проектом. Лекции по спецкурсу "Технология программирования". - СПб: СанктПетербургский государственный электротехнический университет, рукопись, 1998.

6. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - СПб.: Символ-Плюс, 1999.

Тема 8. Управление временем проекта 8.1. Введение Управление временем проекта - это, прежде всего, определение временных рамок каждой из задач проекта, или, иными словами, создание, оптимизация и отслеживание календарных планов.

Изучив учебный материал данной темы, Вы:

Х узнаете или пополните свои знания о видах календарных планов и об их возможных представлениях;

Х научитесь читать, составлять и анализировать календарные планы в форме диаграмм Гантта и сетевых диаграмм;

Х познакомитесь с методом анализа критического пути при планировании проекта.

В рамках темы рассматриваются следующие учебные вопросы:

Х Календарный план проекта.

Х Сетевое представление проекта.

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

Иногда укрупненный календарный план согласуется с заказачиком и включается в качестве приложения в договор (так делают, например, если оплата по договору предусмотрена в несколько этапов).

Из сказанного очевидно следует, что создание календарного плана проходит в несколько шагов:

сначала формируется структура декомпозиции работ (СДР) проекта, т.е. представление проекта в виде иерархического дерева этапов и задач (работ), затем для каждой задачи проекта выставляются сроки в соответствии с возможностями команды разработчиков.

Структура декомпозиции работ (СДР) (work breakdown structure (WBS)) - это иерархическая структура, используемая для организации задач в отчетах по календарному плану и при отслеживании затрат.

Этап (фаза, phase) - это группа связанных задач, завершение которых означает выполнение важной части проекта.

Задача (работа, task) - действия, имеющие начало и конец. Планы проектов состоят из задач.

Далее мы более подробно опишем алгоритм создания календарного плана.

8.2.1. Создание списка задач и структуры декомпозиции работ Недооценка важности структуры декомпозиции работ (СДР) - одна из наиболее серьезных ошибок, допускаемых при планировании проекта. СДР представляет собой иерархический список этапов и задач проекта. Это основа календарного плана проекта. Следует уделить должное внимание составлению СДР - в дальнейшем это сэкономит время, которое пришлось бы потратить на доработку и исправление ошибок.

Построение СДР начинается с составления списка основных компонентов проекта (суммарных задач) и их последующего разбиения на менее крупные компоненты (задачи). Следует продолжать структурировать каждый компонент, пока не будет достигнут уровень детализации, адекватный требованиям плана. Какой уровень детализации считается достаточным Это зависит от следующих факторов:

! Задачи какого уровня предстоит отслеживать и включать в отчеты о состоянии Члены группы проекта должны будут предоставлять руководителю проекта сведения о состоянии задач, а тот должен будет составлять отчеты о состоянии этих задач. Если весь объем работ разбит на однодневные задачи, а проект рассчитан на несколько месяцев, то руководителю и рабочей группе придется потратить слишком много времени на ввод и отслеживание состояния.

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

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

Приведем пример законченной СДР с показанными номерами ее уровней.

Рис. 1. СДР (WBS) проекта.

8.2.2. Оценка длительности задач и трудозатрат Для определения времени, которое предполагается затратить на выполнение задач, вводятся значения трудозатрат или длительности.

Трудозатраты - это объем работ или число человеко-часов, необходимое для завершения задачи.

Длительность - это фактическое время, которое пройдет до завершения задачи.

Так, если задача требует 16 часов работы, выполняемой одним человеком, ее длительность составит два дня (при 8-часовом рабочем дне). Если работу будут выполнять два человека, длительность уменьшится до одного дня. Однако объем работ останется прежним.

Если используется оценка на основе трудозатрат, длительность каждой задачи определяется назначениями ресурсов. Такой подход называется планированием с фиксированным объемом работ.

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

Pages:     | 1 |   ...   | 23 | 24 | 25 | 26 | 27 |   ...   | 33 |    Книги по разным темам