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

в 15:54, , рубрики: коммуникация, управление проектами

Хотел бы поделиться одной историей, которая недавно произошла в моей компании. Подумал опубликовав её, смог бы как-то помочь руководителям проектов предвидеть и избежать не желаемых проблем.

История такова:

Решил один человек из сферы финансов (назовем его заказчиком) открыть свой собственный бизнес и обратился в нашу компанию (назовем её просто компанией) для разработки программного обеспечения.

Выполнение проекта требовало разработать несколько стандартных модулей внутренней системы и один финансово-денежный модуль, который полностью зависел от 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 часа». Доказательством каждого пунктика из файла, служили письма электронной почты, которые получали все три стороны.

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

Автор: MichaelSamteladze

Источник

Поделиться новостью

* - обязательные к заполнению поля