Хотел бы поделиться одной историей, которая недавно произошла в моей компании. Подумал опубликовав её, смог бы как-то помочь руководителям проектов предвидеть и избежать не желаемых проблем.
История такова:
Решил один человек из сферы финансов (назовем его заказчиком) открыть свой собственный бизнес и обратился в нашу компанию (назовем её просто компанией) для разработки программного обеспечения.
Выполнение проекта требовало разработать несколько стандартных модулей внутренней системы и один финансово-денежный модуль, который полностью зависел от WEB API сервисов абсолютно другой большой компании (назовем её третьим лицом).
Третье лицо на основе договора с заказчиком, предоставляла последнему услуги, в виде доступа на собственные WEB API сервисы, со своей документацией и саппортом.
Люди мы деловые и профессионалы своего дела, умеем разрабатывать ПО и работать с WEB API сервисами на 5+, так что первая половина проекта прошла без сучка без задоринки. Все счастливы, что вот-вот сможем хвастаться ещё одним успехом и заказчик тоже доволен.
Но не тут то было, проблемы настигли нас с началом интеграции сервиса:
В первую очередь о проблемах и неисправностях мы начали докладывать заказчику, но он, мол, «не 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 часа». Доказательством каждого пунктика из файла, служили письма электронной почты, которые получали все три стороны.
После ровно одной недели с учётами в конце дня, проблемы с сервисами вдруг резко уменьшились и нам стали эффективно отвечать на все заданные вопросы — в общем лёд тронулся.
Мы же по секрету узнали, что состоялась встреча заказчика с третьим лицом, которая длилась очень долго и за закрытыми дверьми. О чём там говорили, так и осталось за этими дверьми, но факт в том, что ещё неделю спустя мы запустили проект и достигли статуса «Счастливый Заказчик».
История такова:
Решил один человек из сферы финансов (назовем его заказчиком) открыть свой собственный бизнес и обратился в нашу компанию (назовем её просто компанией) для разработки программного обеспечения.
Выполнение проекта требовало разработать несколько стандартных модулей внутренней системы и один финансово-денежный модуль, который полностью зависел от 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 часа». Доказательством каждого пунктика из файла, служили письма электронной почты, которые получали все три стороны.
После ровно одной недели с учётами в конце дня, проблемы с сервисами вдруг резко уменьшились и нам стали эффективно отвечать на все заданные вопросы — в общем лёд тронулся.
Мы же по секрету узнали, что состоялась встреча заказчика с третьим лицом, которая длилась очень долго и за закрытыми дверьми. О чём там говорили, так и осталось за этими дверьми, но факт в том, что ещё неделю спустя мы запустили проект и достигли статуса «Счастливый Заказчик».
prishelec
Я вас понимаю. В период от начала этого года и до апреля, пришлось столкнуться с тремя сервисами у который в API. Были ошибки.
1. Была одна ошибка, не знаю или исправили. Они нам предложили использовать другие методы – заказчика все устроило. На этом и разошлись
2. Сервис виртуальной АТС. Вел с ними переписку две недели. И уже на последнем отчаянии им предоставил расширенный лог HTTP запроса к их API, и о ЧУДО – они нашли баг.
3. Этот сервис переплюнул всех остальных в раз ДВАДЦАТЬ. Сервис сильно известный, но не называю его (не будем их обижать). Багов полно. Описание к примеру в документации есть, а на самом деле методы не реализованы. Или такой вариант из общения с саппортом:
— нам нужен дополнительный токен для такого вот метода. У вас написано, что нужно за этим токеном обращаться в саппорт.
— зачем вам этот метод, вы можете использовать альтернативный и подстроить его под себя
— ну я хочу этот именно метод, он мне как раз подходит и мне не нужно ничего подстраивать
— нет. Вот у нас есть метод другой, используйте его.
Итог общения: толку ноль.
В итоге я понял, что нужно заранее обсуждать любые API сервисы на предмет возможных нюансов в работе. Пусть клиенты сами с ними общаются :).