"Чи є пілот на борту?": офіційний документ

Увага! : Цю статтю перекладено за допомогою служби машинного перекладу; див. застереження. Версію цієї статті англійською мовою див. тут для отримання довідки.

"Якщо на борту є пілот, нехай натисне кнопку виклику", – це те, що пасажир, скоріше за все, не хоче почути під час польоту. Нещодавно мені довелося перечитати цю дивну новину про реальний інцидент, який трапився в грудні 2013 року. Після того, як під час польоту з Де-Мойна, Айова, пілоту терміново знадобилася медична допомога, другий пілот поцікавився наявністю пілота серед пасажирів. Капітан Марк Гонгол, пілот бомбардувальника B1 з ВВС США, прийшов на допомогу. Літак із пасажирами та членами екіпажу на борту безпечно приземлився.

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

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

Доказ правильності концепції

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

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

Зазвичай така відповідь викликає тишу та зніяковіння.

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

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

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

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

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

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

  1. Мати справу з реальним, уже наявним клієнтом.

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

  2. Дайте нам змогу вас переконати.

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

  3. Ви можете пройти відповідне навчання.

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

Де перебуває пілот, коли він вам потрібен?

Отже, що ви думаєте з приводу пілотного проекту? Так краще, чи не так? Можливо. Якщо вас попросили реалізувати пілотне розгортання системи керування корпоративними табелями чи проектами, ви маєте почати з визначення цілей. Якщо єдина мета – доказ правильності концепції, тоді це зовсім не пілотна програма.

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

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

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

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

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

Підведення підсумків

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

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

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

  3. Нарешті, обов’язково складіть план проекту та керуйте ним як і будь-яким іншим проектом у вашому реєстру.

Про автора

Кріс Вандерслуїс (Chris Vandersluis) – президент і засновник компанії HMS Software, сертифікованого партнера корпорації Майкрософт, яка базується в Монреалі (Канада). Він отримав ступінь бакалавра економіки в університеті Макгілла та понад 30 років працює в галузі автоматизації систем керування проектами. Багаторічний член Інституту керування проектами (PMI), він сприяв створенню відділень Microsoft Project Users Group (MPUG) у Монреалі, Торонто та Квебеку. Видання, для яких Кріс писав статті: Fortune, Heavy Construction News, Computing Canada magazine, PMI’s PMNetwork і Project Times. Він викладає дисципліну "Перспективне керування проектами" (Advanced Project Management) в університеті Макгілла та часто виступає з промовами під час заходів асоціації керівників проектів у Північній Америці та в усьому світі. HMS Software – розробник TimeControl, проектно-орієнтованої системи обліку часу. Компанія має статус Microsoft Project Solution Partner з 1995 року.

Звернутися до Кріса Вандерслуїса можна за цією адресою електронної пошти: chris.vandersluis@hms.ca

Якщо ви бажаєте прочитати більше статей про керування проектами для підприємств за авторством Кріса Вандерслуїса, див. блоґ EPM Guidance (http://www.epmguidance.com/?page_id=39).

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

Отримуйте нові функції раніше за інших
Приєднайтеся до оцінювачів Office

Ця інформація корисна?

Дякуємо за ваш відгук!

Дякуємо за відгук! Схоже, вам може стати в нагоді допомога одного з наших спеціалістів служби підтримки Office, з яким ми вас можемо з’єднати.

×