Головна

Особливості формування команди

  1. I. Особливості хірургії дитячого віку
  2. I. Особливості експлуатації родовищ
  3. I. Теоретичні основи формування артикуляційної моторики у дітей.
  4. II. 7.5. Розвиток уваги у дітей і шляхи його формування
  5. II. Об'єктивні методи дослідження органів дихання. Особливості загального огляду. Місцевий огляд грудної клітки.
  6. II. Об'єктивні методи дослідження ендокринної системи. Особливості загального огляду.
  7. II. Етап формування первинних вимовних умінь і навичок

Проект і організаційна структура компанії

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

Синонім функціональної структури - ієрархічна структура (Малюнок 7).


 Малюнок 7. Функціональна структура

Функціональна структура має такі особливості:

Функціональна структура передбачає багаторівневу ієрархію. Керівники функціональних підрозділів це начальники управлінь, начальники підпорядкованих їм служб, відділів, лабораторій, секторів, груп. А ще у кожного начальника є заступник і, часом, не один. Приклади: міністерства, відомства, наукові інститути та підприємства радянського періоду.

На іншому краю спектра організаційних структур знаходиться проектна структура (Малюнок 8).


 Малюнок 8. Проектна структура

У чисто проектних організаціях:

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

У розробці ПЗ найбільш поширена найбільш матричний організація. Розрізняють три види матричної організаційної структури: слабка, збалансована і сильна (Малюнок 9 - Малюнок 11). Причому, в компаніях, які займаються продуктової розробкою ПЗ, функціональні підрозділи визначаються у відповідність з лінійкою продуктів. Наприклад, відділ розробки CRM-систем, відділ розробки фінансових систем, відділ розробки додаткових продуктів.

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


 Малюнок 9. Слабка матриця

У слабкій матриці роль і повноваження співробітника, який координує проект, сильно обмежені. Реальне керівництво проектом здійснює один з функціональних керівників. Координатор проекту, його ще часто називають «трекер», допомагає цьому керівнику збирати інформацію про статус виконуваних проектних робіт, враховує витрати, складає звіти.


 Малюнок 10. Збалансована матриця

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

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


 Малюнок 11. сильна матриця

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

Однією з особливостей матричних структур є те, що вони стають «плоскими», зникає багатоступенева ієрархія. Підприємство, як правило, ділиться на функціональні відділи, в яких працюють фахівці різних категорій, безпосередньо підкоряються начальнику відділу. Начальники лабораторій, секторів, груп скасовуються за непотрібністю. У матричних структурах роль начальника функціонального підрозділу в виробничому процесі помітно знижується, в порівнянні з функціональними структурами. У його компетенції залишаються питання стратегічного розвитку функціонального напряму, планування і розвиток кар'єри співробітників, питання матеріально-технічного забезпечення робіт. Слід враховувати, що такий перерозподіл повноважень і відповідальності від функціональних керівників до менеджерів проектів часто служить джерелом конфліктів в компаніях при їх переході від функціональної структури до матричної.

Організація проектної команди

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

Ролі та відповідальності учасників типового проекту розробки ПЗ можна умовно розділити на п'ять груп:

  1. Аналіз. Витяг, документування та супроводження вимог до продукту.
  2. Управління. Визначення та управління виробничими процесами.
  3. Виробництво. Проектування і розробка програмного забезпечення.
  4. Тестування. Тестування ПЗ.
  5. Забезпечення. Виробництво додаткових продуктів і послуг.

Група аналізу включає в себе наступні ролі:

Група управління складається з наступних ролей:

У виробничу групу входять:

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

Група тестування в проекті складається з наступних ролей:

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

Залежно від масштабу проекту одну роль можуть виконувати кілька людей. Наприклад, розробники, тестувальники, технічні письменники. Деякі ролі завжди повинен виконувати тільки одна людина. Наприклад, Керівник проекту, Системний архітектор. Одна людина може виконувати кілька ролей. Можливі такі поєднання ролей:

Вкрай небажано поєднувати такі ролі:

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

Програмісти люблять і вміють програмувати. Нехай вони цим і займаються. Не варто завантажувати програмістів невластивою для них роботою. У кожному проекті розробки програмного продукту багато інших робіт: бізнес-аналіз, проектування ергономіки, графічний дизайн, розробка документації користувача. Ці роботи з програмуванням не мають нічого спільного. Для них потрібні абсолютно інша кваліфікація і інший склад мислення.

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

З професійних програмістів виходять відмінні тестувальники. Краща команда тестування, яку я зустрічав, була в Luxoft. Це були маститі програмісти з одного академічного НДІ з досвідом 20-30 років. Вони не освоювали нові програмістські технології, але виключно ефективно ламали то, що було зроблено на їх основі. Однак, поєднувати одночасно ролі програміста і тестувальника - погана практика. Хороший програміст переконаний, що він пише програми правильно і йому психологічно важко допустити, що десь в його коді може бути помилка. А помилки є завжди!

Організаційна структура проекту обов'язково повинна включати в себе ефективну систему звітності, оцінки ходу виконання проекту і систему прийняття рішень. Можна рекомендувати щотижневі збори по статусу проекту, на яких аналізуються ризики, оцінюються результати, досягнуті на попередньому тижні, і уточнюються завдання на новий період.

У моделі Scrum рекомендуються щоденні наради щодо стану робіт - «Stand Up Meeting», але мені здається, що це може бути застосовано, швидше, для невеликих робочих груп від 3 до 5 розробників. Хоча в критичні періоди проекту, доводилося проводити і щоденні наради.

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



Попередня   1   2   3   4   5   6   7   8   9   10   11   Наступна

Класифікація проектів | Цілі, результати, терміни і вартість проекту. Критерії ступеня досягнення цілей проекту. | структура проекту | Життєвий цикл проекту та його фази. | Навколишнє середовище проекту. Фактори безпосереднього і далекого оточення. | команда проекту | Основні критерії прийнятності та відмови від проекту. | Причини відхилення проекту |

© um.co.ua - учбові матеріали та реферати