Передпроектне обстеження – бути чи не бути?
Обстеження — що це?
На попередніх переговорах про впровадження будь-якого програмного продукту потенційний виконавець, розповідаючи про те, як він збирається досягти поставленої мети, згадує як перший етап необхідних робіт — обстеження (проектне обстеження, передпроектне обстеження, експрес обстеження — імен не порахувати). З одного боку зрозуміло, що за допомогою нього виконавець хоче краще розібратися в проблемі, з іншого боку вартість цього етапу може сягати третини вартості всього проекту, що потенційному замовнику може здатися надмірним.
Спробуємо розібратися в тому, наскільки цей етап необхідний, і які реальні завдання він ставить перед собою.
Для повноти картини перерахуємо всі етапи робіт, які рекомендуються методологією впровадження програмного забезпечення (ПЗ):
- Обстеження,
- Адаптація ПЗ,
- Наповнення бази даних початковими даними,
- Навчання користувачів,
- Дослідна експлуатація,
- Введення в промислову експлуатацію.
Звертаю вашу увагу на те, що п.п. 2‒4 можуть йти паралельно та/або слідувати в довільному порядку.
У термінах PMBOK® перелічені пункти називаються «Змістом проекту» (природно, автор тут не претендує на точне відображення зведення знань PMBOK® і допускає деякі вільності мови, які для цілей цієї статті вважає цілком виправданими).
Перш ніж переходити до нашої основної мети, а саме обговорення Обстеження як такого, для повноти картини, коротко розглянемо перелічені вище етапи.
Адаптація ПЗ.
Як правило, програма, що впроваджується, є тиражним універсальним рішенням, тобто розробляли її не для вас, а створювали для вашої сфери діяльності або області обліку. Звідси у програмі є весь чи майже весь необхідний вам функціонал, але він у деяких випадках недостатній чи, навпаки, надмірний. Власне процес адаптації і покликаний заточити ПО під руку замовника.
Наповнення бази даних…
Щоб користувачі могли почати працювати, необхідно ввести базові дані (наприклад, списки складів та товарів; заборгованість клієнтів та постачальникам; там, де потрібно, вибрати вид обліку тощо). Зазвичай цей етап включають і налаштування прав користувачів до даних, але іноді така робота виноситься в окремий етап параметричних налаштувань.
Навчання користувачів.
Якщо людина має з чимось працювати, то дуже бажано, щоб вона мала необхідні навички, інакше вона не працюватиме, або працюватиме, але дуже погано. Мета даного етапу — дати користувачам необхідні знання, вміння та навички для роботи у новій програмі.
Дослідна експлуатація.
На цьому етапі необхідно перевірити функціонування нової автоматизованої системи в умовах «близьких до бойових». Введення у промислову експлуатацію.
Завершальний етап проекту,
результат — програмне забезпечення впроваджено і всі поставлені проблеми вирішено.
Але повернемось до першого етапу впровадження — обстеження. Спочатку визначимося з цілями обстеження. Почнемо із змісту договорів на реалізацію проектів. Вони зазвичай пишуть, що виконавець з одного боку зобов’язується надати послугу, а замовник з іншого боку її оплатити. А яку послугу? Де описано, що має зробити виконавець і що, власне, має оплачувати замовник? Простіше кажучи, потрібна формалізація змісту послуг. Документ, що містить таку формалізацію, що є частиною договору та критерієм, за яким здійснюватимуться приймально-здатні роботи, та буде матеріальним результатом обстеження
Це потребує двох договорів — одного на обстеження, а іншого на реалізацію проекту. З цих причин виконавець вкрай неохоче йде на підписання єдиного договору — зобов’язання за результатами проекту чітко не визначено і не зрозуміло — під чим підписуватися.
Однак головне завдання обстеження полягає в іншому. Згадаймо, що мета будь-якого проекту — вирішення будь-якої проблеми замовника (інакше не зрозуміло, навіщо замовник затіяв дорогі процедури). Але річ у тому, що виконавець не вирішує проблему, а робить якийсь комплекс робіт спрямований на вирішення цієї проблеми. Якщо роботи були сплановані правильно і виконані з прийнятною якістю, то проблема буде вирішена, інакше як пощастить. Простіше кажучи, виконавець хоче отримати гроші за виконані роботи та не виконувати безкоштовні роботи. Замовник готовий платити за вирішення проблеми і не хоче породження нових проблем. Очевидно, якийсь конфлікт інтересів. Вирішується він спільною роботою виконавця та замовника. Результатом цієї роботи буде спільно вироблений шлях досягнення цілі. Сам результат фіксується в документі, який зазвичай називають «Звітом про обстеження», який надалі буде підставою для проведення проектних робіт. Саме на етапі обстеження абстрактна мета («Автоматизуйте мені облік» або «Впровадьте CRM») перетворюється на комплекс чітких завдань.
До речі, комплекс деталізованих завдань можна оцінити з величезною точністю. Справа в тому, що на перших зустрічах виконавець не знає — скільки коштує проект, він передбачає його вартість з деякою точністю (зазвичай спираючись на свій досвід вирішення подібних проблем). Але вартість для конкретного замовника він не знає. У комерційних пропозиціях, як правило, чітко прописують вартість обстеження, а суми з реалізації, хоч і показують, але попереджають, що вони можуть бути змінені після обстеження. При цьому похибка може становити плюс/мінус 10% до 30% від початкових оцінок.
Скажу кілька слів про Звіт про обстеження. Він складається із двох частин:
- Загальна частина. Вона містить загальні дані щодо проекту: цілі, завдання, обмеження, поточний стан автоматизації, список відповідальних осіб тощо. Іншими словами, інформацію про проблеми, що стоять, і про підходи до їх вирішення. Також там міститься опис середовища проекту: кількість користувачів, віддалені підрозділи, взаємодія з існуючим у замовника ПЗ тощо. Але, що найважливіше, має бути описано концепцію автоматизованої системи. Де вона «живе», як вона взаємодіє із зовнішнім середовищем, вказати інформаційні потоки тощо.
- Перелік робіт. Є ієрархічною структурою робіт. Виходить вона в такий спосіб: береться етап, який розбивається завдання, завдання розбиваються на подзадачи, …., а кожної підзадачі пропонується рішення як однієї чи кількох робіт.
Наведемо приклади можливих робіт:
Кодування - виконавець вносить зміни до коду програмного продукту. Зазвичай це пов’язано з особливістю процесів замовника, які повністю не лягають на функціонал типової програми. Для якісного кодування потрібно описати бізнес-процес замовника (не повністю, а з погляду задач автоматизації) та зміни, які побачать користувачі. Як виконавець досягне необхідних змін у даному контексті не важливо — власне, його, в тому числі, для цього й найняли.
Налаштування прав доступу та інтерфейсів. Відзначу тут одну особливість — опис тут орієнтований на користувача, тобто текст повинен бути зрозумілий людям, які не знають внутрішню архітектуру ПЗ.
Навчання. Тут все просто, вказується, кого вчимо (бажано поіменно) і чого (з деталізацією на теми). Важливо, що виконавець неспроможна гарантувати факт навчання. Якими б прекрасними не були б викладачі виконавця, вони не можуть дати гарантії навчання, особливо якщо студент захворів і не з’явився на заняття або звільнився до закінчення проекту. Тому роботи з навчання полягають у відпрацьованих зі студентами годинниках. І хоча це не стосується цілей обстеження, варто відзначити, що замовнику вже на цьому етапі варто продумати систему мотивації, для отримання найбільшого ефекту від навчання.
Перенесення даних. Під перенесенням даних зазвичай мається на увазі створення інструментарію для перенесення даних. Немає сенсу переносити зараз стан складів (припустимо з електронних таблиць), якщо проект буде запущений в промислову експлуатацію тільки через місяць. Тому потрібен інструмент, який «по одній кнопці» допоможе перенести необхідні дані, коли це знадобиться. Для цілей перенесення даних у «Звіті про обстеження» необхідно вказати, звідки, які, куди і яким чином переносяться дані.
Встановлення ПЗ. У цій частині звіту вказуються параметри комп’ютерів, параметри локальної мережі, додаткове програмне забезпечення, рівень необхідних для встановлення прав і т.д.
Роботи зі створення документації (Опис автоматизованої системи, інструкції користувачів і т.д.). Тут передусім необхідно зрозуміти призначення документації. Бажано вказати в якому вигляді вона має бути надана. Погодьтеся, є різниця між файлом надісланим електронною поштою та паперовим тиражем у кілька сотень екземплярів.
План-графік робіт. Залежно кількості робіт може бути представлений у вигляді простий таблиці чи мережевий діаграми. У плані-графіці зазначаються дати початку та закінчення робіт, учасники проекту та відповідальні особи за виконання та приймання робіт.
Перелічимо ще низку цілей, які досягаються обстеженням.
До них можна віднести вирішення проблеми: «а чи вірно виконавець розуміє замовника, чи вони говорять однією мовою?». Виконавець із замовником можуть використовувати одні й самі терміни, але у різних значеннях. Особливо це проявляється у виробничих областях, де термін специфікація може означати будь-що. Саме тому іноді відбувається подорожчання або здешевлення проекту Замовник хотів автоматизувати бюджетування, але в процесі обстеження може з’ясуватися, що під бюджетуванням він розумів, не тільки довгострокове фінансове планування, а й казначейство (короткострокове планування руху коштів) — це збільшить вартість проекту, а фактично змінить проект. Можуть бути і зворотні випадки, коли виконавець припускав будь-які роботи, але в процесі обстеження з’ясувалося, що вони не потрібні.
Як відбувається обстеження?
Основний метод проведення обстеження — інтерв’ю. Після чого відбувається документування отриманої інформації та узгодження документів.
Цей процес може повторюватися кілька разів. Коли інформація зібрана та оброблена, результат оформляється у вигляді «Звіту про обстеження», потім затверджується.
Як бути із нюансами?
Якщо взяти проект будівництва будинку, то, як би ми не спускалися вниз по кресленнях, ми завжди зустрічатимемо докладний опис виробів, всі матеріали матимуть ГОСТ, скрізь будуть інструкції, аж до описів умов проведення робіт. В IT-сфері в масі своєї документації не розроблено або закрито. Фактично «Звіт про обстеження» є єдиним документом, який описує всі проектні роботи (іноді його розбивають на частини та дають їм різні назви). Виникає питання: А наскільки він має бути докладним? Очевидна відповідь: Він повинен бути дуже докладним, і не допускати подвійних тлумачень! Але…
Візьмемо просте завдання додавання нового реквізиту до екранної форми документа. Реалізація цього завдання справа однієї хвилини. Тепер спробуйте її докладно описати, не забудьте намалювати, як виглядатиме нова екранна форма, а також погодьте отриманий опис із зацікавленою особою. Ситуація у прикладі свідомо перебільшена, але з нього видно, що якщо ми спробуємо створити дуже докладну документацію, на неї піде основна вартість проекту. Вихід у компромісі і цей компроміс виконавцю та замовнику слід досягати разом.
На закінчення зазначу, що в частині підготовки документації не все так погано. Незважаючи на те, що в цілому стандартизованої документації немає (вірніше в деяких компаній документація може бути розроблена, але в своїй масі вона носить закритий характер і не є загальним стандартом для галузі) — існують методички з навчання, стандарти з написання коду, описи побудови інтерфейсів і т.д. Все це у сумі дозволяє створювати робочу проектну документацію.
Левін С.В., керівник проектів компанії «Інтком Альянс»
Опубліковано на Audit-it.ru
