Що менеджери проекту повинні знати про хмару

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

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

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

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

Очистити, як бруд? Я так думав! Я назвав головного експерта з хмари та генерального директора Cloudwards.net, Mauricio Prinzlau, щоб пояснити більше про те, що менеджери проекту повинні знати про хмару та про те, як він змінює робочу область. Давайте передамо йому…

Навчальна середовище попередніх хмар

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

Звучить знайомо? Якщо ви працювали менеджером проекту більше ніж п'ять-шість років, то воно буде.

Основні обов'язки менеджера проекту в епоху Pre-Cloud

До того, як обчислювальна техніка обчислювалася, основні обов'язки середнього менеджера проектів у проекті програмного забезпечення виглядали так: Робота з технічним архітектором та дизайнерами для потреб дизайну та архітектури. Оцініть, сплануйте, контролюйте, керуйте, відстежуйте та координуйте завдання аналізу, проектування, кодування та тестування між відповідними групами. Координація з діловими користувачами для тестування прийому користувачів і зовнішніх команд для тестування системи в міру необхідності. Тримайте повну відповідальність за доставку, взаємодіючи з внутрішніми командами, де це необхідно

Що це виглядає сьогодні

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

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

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

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

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

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

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

Процес налагодження проблеми також спрощується, оскільки це відбувається на віддаленому сайті. Це спрощує роль керівника проекту.

Як хмара змінює робочу область

Існує декілька способів, за яких хмара змінює робочу область.

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

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

По-третє, в епоху перед облаками вам знадобилося б внутрішнє ІТ-персоналу значних розмірів, щоб підтримувати роботу ваших додатків. Як менеджер проектів, ви б включили ці служби підтримки як одну з ключових ролей в команді проекту, тому що планування передачі є важливим.

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

З іншого боку, вам знадобиться більше технічних архітекторів і бізнес-аналітиків у вашій команді проекту (і в бізнесі в цілому), ніж раніше. Ці експерти зможуть координувати з персоналом постачальника ефективні вимоги.

Які навички вимагають від менеджерів проектів хмарні обчислення?

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

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

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

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

3. Переговори постачальника та контракту:Хоча керівники проектів завжди повинні були мати навички ведення переговорів щодо контракту, перехід до хмари вимагає від менеджерів найчастіше залучати навички постачальників і переговори.

Існує ще один аспект додаткових накладних витрат, оскільки розробка навіть невеликого додатка потребує роботи з виробником для того, щоб вирішити проблеми.

Будучи менеджером проекту у хмарі, це прекрасна можливість для навчання і фантастичний спосіб розширити свої навички!