
- •Питання на модульний контроль №1 з дисципліни “Менеджмент проектів пз”
- •3. Spider Project (Спайдер Проджект) — пакет з управління проектами, спроектований та розроблений російським розробником компанією «Спайдер Проджект» Технічні характеристики Spider Project
- •1.1. Технические характеристики
- •1.Рис.1. Ресурсный критический путь
- •Васильков
- •Суть прямого проходу при плануванні проекту.
- •Суть зворотного проходу при плануванні проекту.
- •Ролі в колективі розробників.
- •Життєвий цикл програмного продукту.
- •Уточнення замовлення на проект.
- •Функції менеджменту.
- •Наведіть схеми організації менеджменту проектів.
- •Функції, які виконуються розробниками програмного проекту.
- •Рольові кластери моделі проектної групи msf.
- •Принципи, які визначають регламент суміщення ролей.
- •Суміщення ролей.
- •Ключові ролі колективу розробників.
- •Ситуації, в яких діє менеджер при відборі кадрів.
- •Вирішення задач визначення кадрових ресурсів проекту.
- •Цілі розробки проірамного забезпечення.
- •Поняття діяльності в менеджменті програмних проектів.
- •Задачі менеджменту програмних проектів.
- •Модель Гантера.
- •Моделі життєвого циклу програмного забезпечення.
- •Класична ітераційна модель.
- •Каскадна модель.
- •Модель фази - функції.
- •Об'єктио-орієнтовані моделі життєвого циклу.
- •Передпроектна діяльність менеджера і початок фази дослідження.
- •Підтримка репутації компанії і менеджера.
- •Підготовка і початок проекту.
- •Загальна характеристика підготовчих робіт.
- •Визначення технічних ресурсів.
- •Визначення кадрових ресурсів.
- •Стратегії розподілу часу.
- •Календарні плани.
- •Мережеве планування.
- •Визначення фінансових ресурсів.
- •Фінансові потреби проекту.
- •Розподіл фінансових ресурсів.
- •Оцінка ймовірних прибутків від реалізації проекту.
- •Концепції розвитку проекту.
- •Загальні принципи і положення.
- •Спеціальні принципи і положення.
- •Переваги розподілу принципів.
- •Планування релізів.
- •Управління якістю проекту.
- •Додаткова інформація про підхід до розробки.
- •Тестування.
- •Вимірювання.
- •Зв'язки проекту.
- •Планування повторного використання програмних компонентів.
- •Самоорганізація діяльності менеджера.
- •Початок проекту.
- •Перехід від попереднього аналізу до першої ітерації.
- •Організація колективної роботи.
- •Схеми з розподілом відповідальності.
- •Схеми з розподілом відповідальності, орієнтовані на зменшення ризику проекту.
- •Деперсоніфікована схема.
- •Змішані схеми і планування організації колективної роботи.
- •Локальні взаємодії в колективі і ухвалення рішень.
- •Принципи контактних заходів.
- •Непланові взаємини в колективі.
- •Перша ітерація: метод "Спочатку в глибину".
- •Мотивація особливого підходу до виконання першої ітерації.
- •Етап і: початкове моделювання.
- •Етап II: моделювання рівня об'єктно-орієнтованого конструювання.
- •Головатий
- •Етап III: швидке програмування.
- •Етап IV : ітеративне нарощування можливостей.
- •Етап VI: програмування і зборка першої ітерації.
- •Етап VII: оцінка ітерації.
- •Людкевич
- •Особливості планування і управління.
- •Взаємини із замовником, листування.
- •Приймання робочих продуктів.
- •Управління проектом після виконання першої ітерації.
- •Аналіз вимог.
Визначення кадрових ресурсів.
В ході апріорного розподілу ресурсів менеджерові корисно визначити можливі
кандидатури на ключові ролі колективу розробників з урахуванням можливості
персоналіями поєднувати ролі або займати їх частково (протягом робочого дня або протягом певного календарного періоду розвитку проекту).
До ключових ролей відносяться
• архітектор проекту,
• проектувальники підсистем,
• керівники команд розробки підсистем,
• фахівець з призначеного для користувача інтерфейсу і
• експерт предметної області
Кандидати на ключові ролі - основа колективу. Заповнення інших вакансій визначається,
коли така основа є, частенько навіть в ході розвитку проекту і в міру необхідності. Оскільки перші учасники проекту відповідають тільки за фазу дослідження, для початку проекту мінімально необхідними персоналіями є ті, хто виконуватиме ролі архітектора і експерта предметної області. Але це не означає, що відкладання питання про інші персоналії - правильне рішення. Саме до початку проекту потрібно визначити у загальних рисах, з ким надалі належить мати справу менеджерові.
Перше питання розподілу ресурсів де підбирати фахівців на проект. Варіантів відповіді на нього небагато.
По-перше, менеджер може заздалегідь знати можливих кандидатів (добре себе працівників, що зарекомендували, фірми, з якими менеджер вже мав справу, або знає по чужих попередніх роботах). Це найкомфортніший варіант для менеджера, який цілком може використовувати особисті, іноді лише інтуїтивні уявлення про персоналії для вибору кандидатів. Слідує, проте, застерегти про те, що ні в якому разі не можна підміняти знання про людину як про працівника відомостями особистого характеру (приятельські стосунки, комунікабельність та ін.).
По-друге, менеджер може підбирати кандидатів з числа працівників фірми, але з якими він ще не мав справи. В цьому випадку йому не обійтися без вивчення послужного списку працівника, співбесід і інших методах отримання відомостей про людину.
Третій, завершальний варіант - це прийняти на роботу нового співробітника. Ситуація майже така ж, як у попередньому випадку, але дещо гірше про працівника фірми досить просто отримати об'єктивну інформацію, тоді як наймаючи нову людину, доводиться задовольнятися відомостями з формальних документів і результатами співбесід.
Підбір кандидатур на ключові ролі в проекті повинен закінчитися досягши контрольної точки 1 життєвого циклу проекту Ресурси розподілені. До цього моменту необхідно скласти графік залучення співробітників до проекту з вказівкою початку робіт і оцінки їх тривалості. Зрозуміло, що в ході наступної розробки цей графік коригуватиметься, але початкові установки важливі як для керівництва, так і для співробітників, що притягаються. Конкретні персоналії в графіці встановлюються для ключових ролей, але оцінка кадрової потреби має бути виконана заздалегідь і по інших ролях.
Складаючи графік в ході передпроектної діяльності, менеджер не повинен припускати, що
усі займані вакансії жорстко фіксовані (працівник може отримати вигіднішу пропозицію, захворіти та ін.). Вже з цієї причини доцільно, формуючи графік залучення співробітників до проекту, заздалегідь включати в нього усіх можливих кандидатів на ролі. Це дозволить вибирати, а згодом навіть міняти персоналії ролей.
Слід зазначити, що, притягаючи працівників на ключові ролі, менеджер дуже часто
потрапляє в ситуацію, сприятливу для проекту, коли кандидат, що притягається, вказує на інші можливі кандидатури. Було б безрозсудно ігнорувати подібні пропозиції. Єдине обмеження, яке варто встановлювати в таких випадках, - це вимога надати резюме. Втім, це вимога взагалі для кожного працівника незалежно від того, на яку роль він запрошується.
Склад відомостей резюме тут не обговорюється, але у зв'язку з підготовкою менеджера на
початок проекту слід сказати, що з резюме має бути прямо або побічно доступна інформація
• про рівень кваліфікації працівника як претендента на ту або іншу роль;
• про умови роботи, які можна запропонувати працівникові, залучаючи його до проекту
(зайнятість повна або часткова, вимоги до заробітної плати та ін.).
Якщо цієї інформації отримати не вдається, то перед тим, як зробити конкретну
пропозицію, менеджерові треба провести співбесіди, на підставі яких він коригує свої апріорні оцінки. Виставляння апріорних оцінок може бути зроблене на підставі послужного списку працівника, опитування тих, з ким він працював і так далі. Важливо підкреслити, що відомості з резюме, а також збирані при опитуваннях і шляхом співбесід найчастіше не носять абсолютний характер, а тому при визначенні кадрових ресурсів проекту менеджер повинен провести нормування наявних даних. Зручно виражати оцінки в бальній системі.