Контрольна робота з проектного менеджменту.

Назва проекту: 1L Бухгалтерія.

Сутність проекту: проект являє собою розробку незалежної від вибору операційної системи платформи для створення систем ведення господарської діяльності підприємств малого і середнього бізнесу, що перевершує по показниках вартості впровадження, володіння і технічних характеристик аналогічні платформи нинішніх лідерів ринку (на 2003 рік - 1С Бухгалтерія).

Концепція проекту.

Реалізація поставлених цілей проекту досягається шляхом:

• Розгляду проекту в 3-х перспективах: короткостроковій (6 місяців), середньостроковій (16 місяців) і довгостроковій (36 місяців).

• Формування дуже чітких етапів розвитку проекту, у рамках кожного терміну.

• Консолідації основних ресурсів проекту на затверджених командою цілях і задачах проекту.

• Вибір користувачів, як основної цільової аудиторії проекту і забезпечення їх інструментами плавного і безболісного переходу на нове програмне забезпечення.

Терміни реалізації проекту.

Перспектива	Дата початку	Кількість місяців	Дата закінчення
Короткострокова	01.01.2004	6	01.06.2004
Середньострокова	01.01.2004	16	01.04.2005
Довгострокова	01.01.2004	36	01.01.2007

Діаграма Ганта

Проект передбачається реалізовувати за допомогою мережі Інтернет. В мережі буде розміщено сайт проекту за допомогою якого буде сформовано команду проекту. Спілкування членів команди буде проводитись за допомого електронної пошти та ICQ.

Кожен член команди 1L повинний розуміти важливість єдності думки в колективі, єдності команди в шляху до поставленої мети, а також важливість і унікальність свої (як і будь-якої іншої) думки під час обговорення питань, пов'язаних із проектом.

Одним із ключових факторів успіху вважаємо розуміння наступних помилок, що допускаються аналогічними проектами по створенню вільних систем для ведення господарської діяльності:

• Орієнтація на кінцевих споживачів таких систем. Їм у більшості випадків байдуже, у якій системі працювати, головне - вирішувати виробничі задачі.

• Наявність власної, більшості програмістів незнайомої і, що саме головне, незвичайної мови програмування для таких систем. Як наслідок, ніхто не хоче переходити на ці системи.

• Відсутність публічної пропаганди своєї діяльності і переваг своїх систем. Як наслідок, відсутність інтересу і довіри (саме головне) до таких систем.

Короткострокова перспектива проекту.

Випуск прототипу програмного забезпечення з мінімально-необхідною функціональністю і мінімально-необхідною стабільністю.

Цілі проекту.

• Створення програмного забезпечення, що по технічних характеристиках не уступає, а в ідеалі переважаючої аналоги (тут і далі в документі мається на увазі 1С).

• Створення програмного забезпечення, що по економічних характеристиках не уступає, а в ідеалі переважає аналоги.

• Формування стійкого інтересу до проекту з боку співтовариства розроблювачів програмного забезпечення, з метою залучення для участі в проекті програмістів, менеджерів проектів, проектувальників, фахівців з юзабилити і тестерів для успішної реалізації проекту 1L.

• Систематична робота з пресою і незалежними інформаційними ресурсами, з метою:

• Інформування користувачів про можливості програмного забезпечення.

• Створення і підтримка іміджу проекту, необхідного для прийняття користувачами рішення про використання програмного забезпечення.

• Формування у свідомості користувачів стійкого асоціативного зв'язку - "вільна Платформа - 1L".

• Формування відкладеного попиту.

• Виявлення інтересів користувачів.

• Максимальне спрощення процедури "входження" програмного забезпечення на ринок.

• Розробка і впровадження системи контролю якості, з метою досягнення необхідних для успіху проекту технічних і економічних характеристик програмного забезпечення.

Структура команди.

Для створення ефективної структури розглянемо проект із позиції бізнесів-процесів з метою визначення функціональних обов'язків і з позиції ієрархії з метою визначення зон відповідальності учасників проекту.

У цілому процес реалізації проекту представлений у виді ітеративного процесу: "визначення цілей -> постановка задачі -> вироблення рішення -> аналіз ситуації -> визначення цілей".

Бізнес-процеси.

У рамках цього процесу, виділимо наступний набір бізнесів-процесів (у першому наближенні):

Аналіз положення внутрішнього і зовнішнього середовища проекту (А)

Реалізація проекту (Р)

Просування проекту (П)

Очевидно, що процеси взаємодіють між собою, як у прямому, так і в зворотному порядку (рис.1)

Рис.1. Схема взаємодії бізнесів-процесів проекту.

Визначимо функції процесів. У функції А входить:

• аналіз

• проектування

• постановка цілей і задач

• контроль якості (тестування)

У функції Р входить:

• постановка задач (робіт)

• контроль робіт

• контроль якості

• документування

У функції П входить:

• залучення розроблювачів у команду проекту

• інформування користувачів про можливості програмного забезпечення

• виявлення інтересів користувачів і розроблювачів

• дистрибуція

Вихідні і вхідні потоки процесів:

• (А2Р) проектна документація (ТЗ)

• (А2Р) календарне планування

• (А2Р) результати тестування

• (А2П) інформація про стан проекту

• (А2П) результати тестування

• (Р2А) звіт про хід виконання робіт

• (Р2А) результати впровадження системи контролю якості

• (Р2П) підготовка до дистрибуції

• (Р2П) документація

• (Р2П) вакансії

• (П2А) результати дистрибуції

• (П2А) відгуки користувачів

• (П2А) результати PR

• (П2Р) відгуки користувачів

• (П2Р) закриття вакансій

Ієрархічна структура проекту.

Рис.2. Процес реалізації проекту.

Рис.3. Організаційна модель проекту.

Стрілками зазначені структурні зв'язки, а не процеси комунікацій.

У зв'язку з прийнятою моделлю розробки проекту (Open-Sources), організаційна схема є, у деякому роді, умовної, тому що кожен учасник проекту має право внести свою лепту на будь-якій ділянці робіт, у благо всього проекту.

У зв'язку зі зростаючою навантаженням на того чи іншого Ведучого групи, він має право створювати Підгрупи і призначати в них відповідальних (Ведучих) за ті чи інші роботи, делегувати їм частина функцій, повноважень і відповідальності.

Функціональні обов'язки.

Обов'язки Координатора:

• аналіз можливостей Ведучих груп;

• призначення Ведучих груп;

• затвердження технічної документації підготовлюваної групами проекту;

• загальне (глобальне) календарне планування;

• рішення спірних питань між Ведучими груп;

• організація проекту;

• постановка глобальних цілей і задач проекту;

• складання проектів модернізації, розвитку, а так само просування проекту разом з координаторами напрямків;

• інформування команди про загальний стан проекту;

• розробка і впровадження системи контролю якості (СКЯ).

Обов'язки Ведучого групи розробки:

• аналіз можливостей учасників проекту/групи;

• підготовка технічної документації для групи;

• постановка задач для членів групи;

• календарне планування робіт групи;

• розробка (разом з координатором) і впровадження СК’;

• організація і контроль процесу підготовки дистрибутивів;

• організація і контроль процесу документування;

• інформування Координатора про стан робіт (у рамках групи);

Обов'язки Ведучого групи тестування:

• розробка технічної документації (для користувачів);

• розробка (разом з координатором) і впровадження СКЯ;

• оцінка функціональних можливостей програми, у тому числі вироблення критеріїв оцінки;

• рекомендації з поліпшення функціональних можливостей;

• інформування команди про знайдені помилки;

• оцінка документації й інформування команди про знайдені невідповідності чи необхідні поліпшення;

Обов'язки Ведучого групи підтримки і просування:

• залучення розроблювачів у команду проекту;

• підготовка прес-релізів і інших публічних матеріалів;

• підготовка і проведення PR-кампаній;

• аналіз відгуків користувачів і інформування команди про результати;

• інформування користувачів про можливості програми;

• загальне просування програми;

Обов'язки Учасника проекту

• докладне документування коду (програмістам);

• інформування Ведучого групи про можливу затримку в роботі;

• загальне залучення розроблювачів у команду проекту;

• інформування колег про знайдені помилки;

• інформування команди про можливі способи і шляхи просування проекту;

Процес прийняття рішень у команді проекту .

Кожен член команди має право висловлювати свою думку з приводу стану проекту, його шляхів розвитку і т.д.

Внесення пропозицій відбувається шляхом винесення питання на обговорення розроблювачів проекту.

У випадку якщо хто-небудь не відповів на винесений для обговорення питання, цей означає, що він цілком згодний із пропозицією, що надійшла.

У випадку виникнення ситуації "думки розділилися" питання передається Координатору для винесення остаточного рішення.

Питання глобальних Цілей і Задач проекту, архітектури програмного забезпечення, мов реалізації, є вирішеними тільки після затвердження Координатором проекту.

Ресурси, необхідні для здійснення проекту.

Потреба грошових ресурсів на реалізацію проекту.

№ п/п	Найменування статті витрат*	Сума, грн.
1	Плата провайдеру за хостінг.	1080
2	Витрати на Інтернет.	2800
3	Рекламні витрати.	10000
4	Організаційні витрати.	4500
5	Адміністративні витрати.	2000
6	Інші витрати.	1500
7	Всього витрат.	21880

*Всі витрати із розрахунку на весь термін реалізації проекту (36 міс.)

Потреба грошових ресурсів на реалізацію проекту (1 етап).

№ п/п	Найменування статті витрат	Сума, грн.
1	Плата провайдеру за хостінг.	180
2	Витрати на Інтернет.	1120
3	Рекламні витрати.	1000
4	Організаційні витрати.	2250
5	Адміністративні витрати.	800
6	Інші витрати.	600
7	Всього витрат.	5950

Потреба грошових ресурсів на реалізацію проекту (2 етап).

№ п/п	Найменування статті витрат	Сума, грн.
1	Плата провайдеру за хостінг.	300
2	Витрати на Інтернет.	840
3	Рекламні витрати.	3000
4	Організаційні витрати.	1350
5	Адміністративні витрати.	600
6	Інші витрати.	450
7	Всього витрат.	6540

Потреба грошових ресурсів на реалізацію проекту (3 етап).

№ п/п	Найменування статті витрат	Сума, грн.
1	Плата провайдеру за хостінг.	600
2	Витрати на Інтернет.	840
3	Рекламні витрати.	6000
4	Організаційні витрати.	900
5	Адміністративні витрати.	600
6	Інші витрати.	450
7	Всього витрат.	9390

Управління проектними ризиками.

Можливі ризики та шляхи їх подолання.

№ п/п	Можливі ризики	Шляхи подолання
1	Не можливість створення команди фахівців.	Даний ризик є одним із мінімальних, так як на теренах колишнього СРСР є дуже велика кількість кваліфікованих програмістів, а об’єднати їх за допомогою Інтернету не складає труда. Ідея створення такого програмного продукту вже давно обговорюється серед програмістів.
2	Не можливість створення дійсно якісного програмного продукту, що не поступається аналогам.	Цей ризик відпадає при вирішенні першого ризику.
3	Труднощі із впровадженням програмного забезпечення.	Цей ризик є одним із основних, так як користувачі, в силу звички, надають перевагу вже відомим програмним продуктам і поява нового програмного продукту може залишитись просто не поміченою. Але перевага нашого продукту полягає в тому, що він, на відміну від загальновідомих, є безкоштовним. Як відомо, основна маса програмного забезпечення, що використовується в Україні є піратськими, а отже користувачі нею позбавлені технічної підтримки, то наш продукт є безкоштовним і по ньому надається технічна підтримка.
4	Труднощі із вирішенням ресурсної бази проекту.	Ресурсна база проекту формується за рахунок власних заощаджень учасників проекту, а прибуток, отриманий завдяки комерціалізації проекту буде платою його учасникам. Так як програмне забезпечення є безкоштовним, то доход передбачається отримувати за рахунок реклами на сайті проекту, через який має проводитись дистрибуція програми та технічна підтримка, це є світовою практикою, і доходи отримувані таким чином є досить високі щоб покрити витрати проекту і отримати бажану норму прибутку.
5	Психологічні проблеми всередині команди.	Так як безпосереднього контакту між учасниками проекту не передбачається (контакти в основному за допомогою мережі Інтернет), то вплив даного виду ризику незначний.
6	Труднощі, пов’язані із популяризацією продукту.	Рекламний бюджет проекту достатній для широкої популяризації продукту в мережі Інтернет.