Граблі, на які ви не хотіли б настати в своєму проекті

Добрий день, мене звати Сергій і я керівник продуктового напрямку в компанії «ДоксВижн». За час роботи у сфері автоматизації електронного документообігу мені довелося брати участь у десятках проектів впровадження, причому в різних ролях (від інженера до керівника проектного офісу), з різних сторін (замовник, представник компанії-впроваджувача, вендор) і з різними системами (Docsvision і Directum). Своїм проектним досвідом я хочу поділитися з вами.

Знаючи процес і набивши купу шишок, я даю в статті кілька рекомендацій, які дозволять підійти до проекту впровадження СЕД (як і будь-ІТ-системи) підготовленими і більш гладко його реалізувати. Мій колега вже давав поради ІТ-фахівцям замовника, відповідальним за впровадження. Я гляну на питання під іншим кутом і поділюся низкою нюансів, які варто врахувати саме компанії-інтегратору. Особливо, якщо вам належить перший проект впровадження. Сподіваюся, стаття буде корисна, хоча на багато «граблі» все одно потрібно іноді наставати самостійно, і ідеальних рецептів в проектній практиці не існує.


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

«А мені обіцяли...»
Одна з поширених великих помилок на етапі обговорення проекту з клієнтом, до укладення договору (особливо часто зустрічається у великих інтеграторів) — відсутність Керівника майбутнього проекту. Без нього з'являються якісь домовленості (про яких він дізнається, добре якщо не в кінці проекту), різне трактування завдань і цілей проекту і т. п. Коли це спливає, замовник починає бити кулаками по столу і говорити, що йому обіцяли… Ніяких обіцянок може насправді і не бути, але якщо керівник проекту при обговоренні був відсутній, то зрозуміти, чи були ці домовленості чи ні – він вже не зможе.
У мене було кілька таких випадків. Один раз у великій компанії N, де я робив, по суті, пілотний проект на готовому коробковому рішенні, ІТ-директор раптом вирішив, що поставимо ми «коробку», але робити на ній будемо великий кастомный проект, тому що саме про це «домовлялися». Те, що ціна на кастомний розробку в рази більше – його не бентежило. У цьому і подібних випадках, якщо не вдавалося переконати замовника своїми силами (а часто так виходило), я просто влаштовував очну ставку, приводячи того, хто «домовлявся». Головне – не давати слабину, і до останнього відстоювати свою позицію.
Команда молодості нашої
Ще одне важливе питання – формування команди проекту. Не стільки в плані підбору людей (це теж важливо, але тут не про це), скільки для представлення команди замовнику і знайомства з його командою. Як правило, цілком достатньо уявити команди заочно. Повинен з'явитися документ, що описує, хто і чим займається з обох сторін. Загальна рекомендація: не соромтеся робити і підписувати різного роду папірці з відповідальними представниками замовника, в якийсь момент це може дуже сильно допомогти.

План – це предмет простий...
Ще «на березі» важливо домовитися про склад робіт. Звичайно, мова не про детальні вимоги до системи, а про верхнеуровневом списку проектних робіт. В одному з проектів я зіткнувся приблизно з таким календарним планом:



У досвідченого людини, швидше за все, він викличе тільки питання. Якщо не відразу, то потім, і ви почнете пояснювати, чому трудомісткість робіт 200 годин, в той час, як в команді проекту 1 людина, чому ви не будете проводити якусь зустріч з користувачами системи і т. п.
Нікому ці роботи не потрібні, вартість проекту вже відома, тут ця інформація лише наводить на думки… План робіт на цьому етапі повинен відображати максимально детальний склад робіт (верхнеуровневый список) і основні етапи проекту з прив'язкою до дат, наприклад, так:



Швидше. Вище. Сильніше
Ще перед початком проекту потрібно чітко обговорити і зафіксувати цілі та завдання, це може вплинути на всю подальшу роботу. Наприклад, прискорити процес узгодження договорів і зробити цей процес прозорим — це зовсім різні цілі, а якщо мета просто «автоматизувати», то тут можуть розумітися 100500 таких, як ці дві. Неправильно зрозумівши очікування замовника, ви можете серйозно промахнутися з оцінкою всього проекту і, у кінцевому рахунку, він стане збитковим… добре ще, якщо при цьому замовник залишиться задоволений. Обов'язково деталізуйте занадто загальні цілі, докопуєтеся до суті.

«А чи був хлопчик?»
На самому початку потрібно точно знати відповідь на питання: «А чи є, що автоматизувати?» Швидше за все, ви дізнаєтеся про це самі, коли вам скажуть: «Ми хочемо запровадити СЕД, а заодно оптимізувати наші внутрішні процеси». Часто чули таке? Поки внутрішні процеси не оптимізовані – вам там робити нічого, якщо, звичайно, першим етапом проекту не є консалтинг. Недарма є розхожий вислів «не можна автоматизувати хаос» — автоматизація йде тільки слідом за оптимізацією. Якщо замовник хоче робити такі речі паралельно, то це має бути тривожним дзвіночком для вас, означає, що потрібно дуже уважно підійти до процесу організації проекту. Зараз, озираючись назад, я вже не став вплутуватися в такий проект, особливо якщо б він був одним з моїх перших.
У мене був один сумний досвід, пов'язаний саме з цим питанням. Справа була у великій компанії Z на старті проекту давалася установка, що потрібно заодно оптимізувати процеси… При цьому всі сильно ускладнювалася відсутністю у замовника особи, що приймає рішення (це до питання про команду проекту і відповідальності/обов'язки її членів). Але докладніше про це — пізніше.

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

Кому все це потрібно...
Часто доводиться стикатися з тим, що більшість користувачів сприймає вашу систему як щось, нав'язане їм незрозуміло для чого. Спочатку я дуже дивувався цьому, адже раніше, впроваджуючи системи бухгалтерського обліку, ніколи з цим не зустрічався (але і не дивно, адже для бухгалтерів система – основний робочий інструмент, без нього вони в принципі не зможуть працювати). Здавалося б, що такого, а в підсумку справа може закінчитися саботажем.
Щоб уникнути подібних проблем, бажано заручитися підтримкою топ-менеджменту, або, як мінімум, початок проекту повинно супроводжуватися випуском наказу по компанії, в якому буде зазначено, що і навіщо впроваджується, хто зобов'язаний брати участь у цьому процесі і за що відповідати.
Здорово, якщо вдасться провести якусь агітаційну роботу, у ході якої правильно донести цілі і задачі проекту до кінцевих користувачів – пояснити їм, що вони отримають в результаті, і навіщо це їм потрібно. Зможете заручитися підтримкою хоча б керівників підрозділів — кількість проблем ви собі зменшіть.
Звичайно, бувають випадки, коли з цього нічого неможливо, тоді все, на що ви можете розраховувати – майстерність менеджера проекту. Як я вже говорив вище – не соромтеся підписувати папірці, будь-яка зміна має бути узгоджено і зафіксовано на папері, у важку хвилину це може врятувати проект.

Починаємо...

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

Про що тут варто подумати?
Провести ввідне навчання на початковій стадії проектування системи. Показати ключовим користувачам, групі проекту (це користувачі, які виступають в якості експертів та формують склад вимог до системи) систему, її основні інтерфейси, можливості, базові сценарії роботи, можливості кастомізації.
Але цього недостатньо.
В одному з проектів я зіткнувся з тим, що підрядник, зробивши це, вирішив, що все тепер прекрасно знають продукт, і далі процес можна сильно спростити. Зокрема, всі технічне завдання представляло з себе опис змін (налаштувань) щодо того, що було продемонстровано. Я не рекомендую так робити, адже проводячи такий захід, ви всього лише (і то це залежить від якості проведення і людей) спробуєте знайти з користувачами спільну мову, щоб розуміти один одного. Це не панацея, не варто помилятися і думати, що через тиждень хтось з них щось згадає.
Більше інтерфейсу для користувачів. Описана в попередньому пункті практика для великих впроваджень може взагалі не досягти своєї мети. Правильним буде просто тісніше спілкуватися з користувачами в процесі: Проводити невеликі демонстрації, показуючи і обговорюючи все наочно і на «картинках», а не на «буквах», застосовувати прототипування (це дозволяють системи з розвиненими інструментами настроювання інтерфейсів, як, наприклад, Docsvision, що дозволяють створити інтерфейс без будь-якого програмування), ну і, звичайно, писати повноцінне технічне завдання.

Технічне завдання: зробити докладні описи «для всіх». В доповнення до вищеописаного є ще одна рекомендація щодо оформлення ТЗ. Річ, звичайно, суто індивідуальна, кожен пише по-своєму, по прийнятих в компанії стандартів і правил, за Гостом і т. п., але важливо не як, а що написано. Оскільки дуже часто цей документ погоджують прості користувачі (діловод, наприклад), то помилкою може стати його написання на технічному мовою. Описані у такому документі налаштування і конфігурації системи, може, і узгодять, але вже точно не розуміючи, що саме було погоджено. Є практика явним чином виділити і описати 2 блоки: перший — опис сценаріїв роботи, тобто хто, що і як буде робити в системі. Другий – вже опис налаштувань.

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

Як обіцяв вище, розповім, що може статися на цьому етапі, якщо замовник одночасно з впровадженням захоче оптимізувати свої внутрішні процеси. Отже, велика компанія X, впроваджуємо СЕД, а заодно переробляємо внутрішні процеси, які зачіпають майже всі підрозділи. Відразу скажу, що цей проект зібрав більшу частину «неправильного», на мій погляд, поведінки підрядника, про який я пишу в цій статті, але вирішальним стало інше. Була сформована робоча група проекту, призначені відповідальні, і навіть випущений наказ по компанії, але в цій робочій групі не вистачало одного – особи, що приймає рішення. Точніше, формально він був, але в силу високої зайнятості далеко не завжди був присутній на нескінченних зустрічах, присвячених вимогам до системи, а це дійсно здавалося нескінченним: ми ялозили одні і ті ж питання по багато разів, на ходу придумувалися способи все спростити, а іноді, навпаки, ускладнити, але як тільки потрібно було щось затвердити, все вмивали руки. Ми намагалися сформулювати стисло, про що домовилися, і узгодити це, але, коли це перетворювалося в технічне завдання або збиралося нараду для обговорення пов'язаних процесів, все знову могло докорінно змінитися.

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

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

Десь на середині шляху...


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

Чесно кажучи, спочатку я сам часто так робив, ну або майже так (ми все-таки робили одну попередню демонстрацію в ході робіт).
Одного разу в крупній компанії Z я зіткнувся з користувачем, який хотів, щоб СЕД сама розписувала за нього доручення і т. п., мало не в магазин за хлібом вона повинна була бігати за його бажанням. В ході проведення інтерв'ю ми пояснювали, про щось домовлялися, що і як буде працювати, але коли він погоджував документ, знову з'являлися питання. Співробітник цей обіймав досить високу посаду і міг чинити сильний вплив на проект.
Дивлячись на те, що відбувається, ІТ-директор цієї компанії дав один простий рада. Це навіть не рада була, він наполягав: потрібно частіше зустрічатися з користувачами, обговорювати, переконуватися в тому, що всі однаково розуміють, проводити демонстрації, користувачі повинні нас знати, щоб якщо когось запитати, хто вам впроваджує СЕД, кожен сказав: «Так бігає тут один. Сергієм кликати.»

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

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

Ми будували, будували...
Нарешті, все узгоджено, налаштоване, здано, пора проводити навчання і запускати систему в дослідну експлуатацію. Тут ви, швидше за все, зіткнетеся з питанням: «на яких даних її проводити – запускати і обробляти реальні документи або тестові? Може бути, реальні, але паралельно вести їх обробку в паперовому вигляді? Єдино правильної відповіді немає, зате є, над чим подумати.

Якщо вибрати тестові документи, користувачі будуть ставитися до них як до чогось необов'язкового, як до чогось, де потрібно натиснути кнопку, лише б відстали. До чого це призведе? Швидше за все, ні до чого доброго, а до того, що про те, що щось не працює або працює не зовсім так, ви дізнаєтеся після запуску у постійну експлуатацію. Наслідки, думаю, зрозумілі.

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

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

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

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.