Коли за проблему в проекті несе відповідальність третя особа

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


Історія така:

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

Виконання проекту вимагало розробити кілька стандартних модулів внутрішньої системи і один фінансово-грошовий модуль, який повністю залежав від WEB API сервісів абсолютно іншої великої компанії (назвемо її третьою особою).

Третя особа на основі договору із замовником, надавала останньому послуги, у вигляді доступу на власні WEB API сервіси, зі своєю документацією і саппортом.

Люди ми ділові і професіонали своєї справи, вміємо розробляти ПЗ і працювати з WEB API сервісами на 5 +, так що перша половина проекту пройшла без сучка без задірки. Всі щасливі, що ось-ось зможемо хвалитися ще одним успіхом і замовник теж задоволений.

Але не тут то було, проблеми наздогнали нас з початком інтеграції сервісу:

  • Неповна документація
  • Не до кінця доопрацьовані WEB сервіси
  • Заблокований доступ на частину потрібного функціоналу
  • і.т.д.

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

Комунікація з третьою особою теж склалася не кращому чином, бувало що на питання як «що означає error code 234, який повинен бути прописаний в мануалі а його немає», доводилося чекати відповідь майже цілий день, тому що то представник третьої особи зараз не доступний, то йому треба проконсультуватися з відділом, який розробляв частину сервісів від 200 - 250 і т. д.

Вся переписка велася через пошту де всі три сторони завжди сиділи в CC.

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

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

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

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

Варіант 2: став нашим рішенням. Ми почали вести облік: щоразу, коли компанія відправляла мейл третій особі, ми це записували, чекали відповіді, фіксували час при її отриманні і вищипували втрачені хвилини (елементарна арифметика).

Виглядала все це приблизно так:

12:00 - надіслали листа третій особі щодо несправності сервісу «х»;

12:45 - отримали відповідь що зараз представник третьої особи на зустрічі і передзвонить через 2 години.

- Втрачений час 45 хв

14:45 - надіслали листа третій особі, що все ще чекаємо відповіді;

- Загублений час 2 години.

15:30 - третя особа передзвонила і дали нам відповідь з рішенням;

- Втрачений час 45 хв

Наприкінці дня все це красиво оформлялося в pdf файл, зі своїм підсумковим результатом, який явно висловлював за день втрачений час з вини третьої особи і відправлялося замовнику. Особливо червоним відзначалися такі «суттєві» відповіді як «перезвоним через 2 години». Доказом кожного пунктика з файлу, слугували листи електронної пошти, які отримували всі три сторони.

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

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